7 p.m.
OK folks, below is the contents of this gist https://gist.github.com/4531575. I may have
missed a number of things, gotten too specific in places or not specific enough in others.
This should hopefully get a good discussion going on how we want to handle paging across
all of the client libraries. Let's keep all comments on the list and not the gist as
much as possible to avoid breaking up the conversation.
Below is a pipe configuration showing the different paging options. Defaults are just
suggestions and are up for discussion as much as the rest of it
var pagedPipe = AeroGear.Pipeline({
name: "pager",
settings: {
paged: {String}, // Default is "headers", can also be
"content", or undefined for no paging
pageConfig: { // Only required if paged is not undefined
// which page, header default is "AG-Paging-Offset", content
default is "paging.offset"
offset: {String},
offsetVal: {Number}, // Default 0 for first page
// items per page, header default is "AG-Paging-Limit", content
default is "paging.limit"
limit: {String},
limitVal: {Number}, // Default 5 items per page
// total number of items, header default is "AG-Paging-Total",
content default is "paging.total"
total: {String},
// link to next page, default in both cases is undefined
next: {String},
// link to previous page, default in both cases is undefined
prev: {String}
}
}
}).pipes.pager;
Getter/Setter methods should be provided for getting and updating the offsetVal and
limitVal defaults
var defaultOffset = pagedPipe.getOffsetVal();
pagedPipe.setOffsetVal( defaultOffset + 1 ); // by default the second page would be
returned
var defaultLimit = pagedPipe.getLimitVal();
pagedPipe.setLimitVal( defaultLimit + 5 ); // by default, 10 items would be returned
per page
## read()
By default, a read() against a paged pipe will return the first page based on the default
offsetVal and limitVal. We could possible add an option that doesn't effect unpaged
pipes but on a paged pipe, it can be used to turn off paging for that read() and get all
data
// Get first page
pagedPipe.read({success callback handles data});
// Get all data from paged pipe
pagedPipe.read({
page: false,
success: handle the data
});
To avoid code duplication, **next**, **prev**, **first** and **last** pages can be
retrieved by passing an option to the read method of a paged pipe since other than some
paging housekeeping, the code would be the same. We can also use that same option as above
that was used to get all data from a paged pipe. One question, when requesting prev from
first page or next from last page, should it throw an error that needs to be handled or
just return and empty data set? I see advantages and disadvantages of both.
// Get next page
pagedPipe.read({
page: "next",
success: handle the data
});
// Get previous page
pagedPipe.read({
page: "prev",
success: handle the data
});
// Get first page
pagedPipe.read({
page: "first",
success: handle the data
});
// Get last page
pagedPipe.read({
page: "last",
success: handle the data
});
8:14 p.m.
On Jan 14, 2013, at 1:00 PM, Kris Borchers <kris(a)redhat.com> wrote:
Looks nice, couple comments inline
OK folks, below is the contents of this gist
https://gist.github.com/4531575. I may have missed a number of things, gotten too specific
in places or not specific enough in others. This should hopefully get a good discussion
going on how we want to handle paging across all of the client libraries. Let's keep
all comments on the list and not the gist as much as possible to avoid breaking up the
conversation.
Below is a pipe configuration showing the different paging options. Defaults are just
suggestions and are up for discussion as much as the rest of it
var pagedPipe = AeroGear.Pipeline({
name: "pager",
settings: {
paged: {String}, // Default is "headers", can also be
"content", or undefined for no paging
pageConfig: { // Only required if paged is not undefined
// which page, header default is "AG-Paging-Offset", content
default is "paging.offset"
offset: {String},
offsetVal: {Number}, // Default 0 for first page
// items per page, header default is "AG-Paging-Limit", content
default is "paging.limit"
limit: {String},
limitVal: {Number}, // Default 5 items per page
// total number of items, header default is "AG-Paging-Total",
content default is "paging.total"
total: {String},
// link to next page, default in both cases is undefined
next: {String},
// link to previous page, default in both cases is undefined
prev: {String}
}
}
}).pipes.pager;
would it be beneficial, or would users be looking for it, if "next" and
"prev" could also be functions.
Getter/Setter methods should be provided for getting and updating the
offsetVal and limitVal defaults
var defaultOffset = pagedPipe.getOffsetVal();
pagedPipe.setOffsetVal( defaultOffset + 1 ); // by default the second page would be
returned
var defaultLimit = pagedPipe.getLimitVal();
pagedPipe.setLimitVal( defaultLimit + 5 ); // by default, 10 items would be returned
per page
## read()
By default, a read() against a paged pipe will return the first page based on the default
offsetVal and limitVal. We could possible add an option that doesn't effect unpaged
pipes but on a paged pipe, it can be used to turn off paging for that read() and get all
data
// Get first page
pagedPipe.read({success callback handles data});
// Get all data from paged pipe
pagedPipe.read({
page: false,
success: handle the data
});
To avoid code duplication, **next**, **prev**, **first** and **last** pages can be
retrieved by passing an option to the read method of a paged pipe since other than some
paging housekeeping, the code would be the same. We can also use that same option as above
that was used to get all data from a paged pipe. One question, when requesting prev from
first page or next from last page, should it throw an error that needs to be handled or
just return and empty data set? I see advantages and disadvantages of both.
Will we know what page they are one before the read. If so, then we can save the request
just to throw the error. This would might be better just for calling prev on the first
page, since the last page could also be growing
// Get next page
pagedPipe.read({
page: "next",
success: handle the data
});
// Get previous page
pagedPipe.read({
page: "prev",
success: handle the data
});
// Get first page
pagedPipe.read({
page: "first",
success: handle the data
});
// Get last page
pagedPipe.read({
page: "last",
success: handle the data
});
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
8:15 p.m.
Looks good.
For iOS I am thinking to actually offer next, prev. etc as methods
-M
On Mon, Jan 14, 2013 at 7:00 PM, Kris Borchers <kris(a)redhat.com> wrote:
OK folks, below is the contents of this gist
https://gist.github.com/4531575. I may have missed a number of things,
gotten too specific in places or not specific enough in others. This should
hopefully get a good discussion going on how we want to handle paging
across all of the client libraries. Let's keep all comments on the list and
not the gist as much as possible to avoid breaking up the conversation.
Below is a pipe configuration showing the different paging options.
Defaults are just suggestions and are up for discussion as much as the rest
of it
var pagedPipe = AeroGear.Pipeline({
name: "pager",
settings: {
paged: {String}, // Default is "headers", can also be
"content", or undefined for no paging
pageConfig: { // Only required if paged is not undefined
// which page, header default is "AG-Paging-Offset",
content default is "paging.offset"
offset: {String},
offsetVal: {Number}, // Default 0 for first page
// items per page, header default is "AG-Paging-Limit",
content default is "paging.limit"
limit: {String},
limitVal: {Number}, // Default 5 items per page
// total number of items, header default is
"AG-Paging-Total", content default is "paging.total"
total: {String},
// link to next page, default in both cases is undefined
next: {String},
// link to previous page, default in both cases is
undefined
prev: {String}
}
}
}).pipes.pager;
Getter/Setter methods should be provided for getting and updating the
offsetVal and limitVal defaults
var defaultOffset = pagedPipe.getOffsetVal();
pagedPipe.setOffsetVal( defaultOffset + 1 ); // by default the second
page would be returned
var defaultLimit = pagedPipe.getLimitVal();
pagedPipe.setLimitVal( defaultLimit + 5 ); // by default, 10 items
would be returned per page
## read()
By default, a read() against a paged pipe will return the first page based
on the default offsetVal and limitVal. We could possible add an option that
doesn't effect unpaged pipes but on a paged pipe, it can be used to turn
off paging for that read() and get all data
// Get first page
pagedPipe.read({success callback handles data});
// Get all data from paged pipe
pagedPipe.read({
page: false,
success: handle the data
});
To avoid code duplication, **next**, **prev**, **first** and **last**
pages can be retrieved by passing an option to the read method of a paged
pipe since other than some paging housekeeping, the code would be the same.
We can also use that same option as above that was used to get all data
from a paged pipe. One question, when requesting prev from first page or
next from last page, should it throw an error that needs to be handled or
just return and empty data set? I see advantages and disadvantages of both.
// Get next page
pagedPipe.read({
page: "next",
success: handle the data
});
// Get previous page
pagedPipe.read({
page: "prev",
success: handle the data
});
// Get first page
pagedPipe.read({
page: "first",
success: handle the data
});
// Get last page
pagedPipe.read({
page: "last",
success: handle the data
});
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
8:17 p.m.
On 01/14/2013 01:00 PM, Kris Borchers wrote:
OK folks, below is the contents of this gist
https://gist.github.com/4531575. I may have missed a number of things,
gotten too specific in places or not specific enough in others. This
should hopefully get a good discussion going on how we want to handle
paging across all of the client libraries. Let's keep all comments on
the list and not the gist as much as possible to avoid breaking up the
conversation.
Below is a pipe configuration showing the different paging options.
Defaults are just suggestions and are up for discussion as much as the
rest of it
var pagedPipe = AeroGear.Pipeline({
name: "pager",
settings: {
paged: {String}, // Default is "headers", can also be
"content", or undefined for no paging
pageConfig: { // Only required if paged is not undefined
// which page, header default is "AG-Paging-Offset",
content default is "paging.offset"
offset: {String},
offsetVal: {Number}, // Default 0 for first page
// items per page, header default is
"AG-Paging-Limit", content default is "paging.limit"
limit: {String},
limitVal: {Number}, // Default 5 items per page
// total number of items, header default is
"AG-Paging-Total", content default is "paging.total"
total: {String},
// link to next page, default in both cases is undefined
next: {String},
// link to previous page, default in both cases is
undefined
prev: {String}
}
}
}).pipes.pager;
Getter/Setter methods should be provided for getting and updating the
offsetVal and limitVal defaults
var defaultOffset = pagedPipe.getOffsetVal();
pagedPipe.setOffsetVal( defaultOffset + 1 ); // by default the
second page would be returned
var defaultLimit = pagedPipe.getLimitVal();
pagedPipe.setLimitVal( defaultLimit + 5 ); // by default, 10 items
would be returned per page
## read()
By default, a read() against a paged pipe will return the first page
based on the default offsetVal and limitVal. We could possible add an
option that doesn't effect unpaged pipes but on a paged pipe, it can
be used to turn off paging for that read() and get all data
// Get first page
pagedPipe.read({success callback handles data});
// Get all data from paged pipe
pagedPipe.read({
page: false,
success: handle the data
});
To avoid code duplication, **next**, **prev**, **first** and **last**
pages can be retrieved by passing an option to the read method of a
paged pipe since other than some paging housekeeping, the code would
be the same. We can also use that same option as above that was used
to get all data from a paged pipe. One question, when requesting prev
from first page or next from last page, should it throw an error that
needs to be handled or just return and empty data set? I see
advantages and disadvantages of both.
// Get next page
pagedPipe.read({
page: "next",
success: handle the data
});
// Get previous page
pagedPipe.read({
page: "prev",
success: handle the data
});
// Get first page
pagedPipe.read({
page: "first",
success: handle the data
});
// Get last page
pagedPipe.read({
page: "last",
success: handle the data
});
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
At first glance I don't
like having the distinction between a "Pipe" and
a "PagedPipe". In Java land PagedPipe will be an interface which
extends Pipe (this is no big deal) and PagedRestAdatper would extend
RestAdapted and implement PagedPipe. This isn't too bad but it makes
reusing paging logic a bit harder. (And also this is at first glance).
The biggest issue I see with a PagedPipe is it means a developer can't
change his paging preferences without creating a new Pipe.
8:21 p.m.
On Mon, Jan 14, 2013 at 8:17 PM, Summers Pittman <supittma(a)redhat.com>wrote:
On 01/14/2013 01:00 PM, Kris Borchers wrote:
OK folks, below is the contents of this gist
https://gist.github.com/4531575. I may have missed a number of things,
gotten too specific in places or not specific enough in others. This should
hopefully get a good discussion going on how we want to handle paging
across all of the client libraries. Let's keep all comments on the list and
not the gist as much as possible to avoid breaking up the conversation.
Below is a pipe configuration showing the different paging options.
Defaults are just suggestions and are up for discussion as much as the rest
of it
var pagedPipe = AeroGear.Pipeline({
name: "pager",
settings: {
paged: {String}, // Default is "headers", can also be
"content", or undefined for no paging
pageConfig: { // Only required if paged is not undefined
// which page, header default is "AG-Paging-Offset",
content default is "paging.offset"
offset: {String},
offsetVal: {Number}, // Default 0 for first page
// items per page, header default is "AG-Paging-Limit",
content default is "paging.limit"
limit: {String},
limitVal: {Number}, // Default 5 items per page
// total number of items, header default is
"AG-Paging-Total", content default is "paging.total"
total: {String},
// link to next page, default in both cases is undefined
next: {String},
// link to previous page, default in both cases is
undefined
prev: {String}
}
}
}).pipes.pager;
Getter/Setter methods should be provided for getting and updating the
offsetVal and limitVal defaults
var defaultOffset = pagedPipe.getOffsetVal();
pagedPipe.setOffsetVal( defaultOffset + 1 ); // by default the second
page would be returned
var defaultLimit = pagedPipe.getLimitVal();
pagedPipe.setLimitVal( defaultLimit + 5 ); // by default, 10 items
would be returned per page
## read()
By default, a read() against a paged pipe will return the first page based
on the default offsetVal and limitVal. We could possible add an option that
doesn't effect unpaged pipes but on a paged pipe, it can be used to turn
off paging for that read() and get all data
// Get first page
pagedPipe.read({success callback handles data});
// Get all data from paged pipe
pagedPipe.read({
page: false,
success: handle the data
});
To avoid code duplication, **next**, **prev**, **first** and **last**
pages can be retrieved by passing an option to the read method of a paged
pipe since other than some paging housekeeping, the code would be the same.
We can also use that same option as above that was used to get all data
from a paged pipe. One question, when requesting prev from first page or
next from last page, should it throw an error that needs to be handled or
just return and empty data set? I see advantages and disadvantages of both.
// Get next page
pagedPipe.read({
page: "next",
success: handle the data
});
// Get previous page
pagedPipe.read({
page: "prev",
success: handle the data
});
// Get first page
pagedPipe.read({
page: "first",
success: handle the data
});
// Get last page
pagedPipe.read({
page: "last",
success: handle the data
});
_______________________________________________
aerogear-dev mailing
listaerogear-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev
At first glance I don't like having the distinction between a "Pipe" and
a "PagedPipe". In Java land PagedPipe will be an interface which extends
Pipe (this is no big deal) and PagedRestAdatper would extend RestAdapted
and implement PagedPipe. This isn't too bad but it makes reusing paging
logic a bit harder. (And also this is at first glance).
haven't thought about typing, but a subclass (in iOS / Java land) sounds
reasonable.
Will post something 2morrow
The biggest issue I see with a PagedPipe is it means a developer can't
change his paging preferences without creating a new Pipe.
oh, I could not update the settings? That's a -1
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
8:27 p.m.
On Jan 14, 2013, at 1:17 PM, Summers Pittman <supittma(a)redhat.com> wrote:
On 01/14/2013 01:00 PM, Kris Borchers wrote:
> OK folks, below is the contents of this gist https://gist.github.com/4531575. I may
have missed a number of things, gotten too specific in places or not specific enough in
others. This should hopefully get a good discussion going on how we want to handle paging
across all of the client libraries. Let's keep all comments on the list and not the
gist as much as possible to avoid breaking up the conversation.
>
> Below is a pipe configuration showing the different paging options. Defaults are just
suggestions and are up for discussion as much as the rest of it
>
> var pagedPipe = AeroGear.Pipeline({
> name: "pager",
> settings: {
> paged: {String}, // Default is "headers", can also be
"content", or undefined for no paging
> pageConfig: { // Only required if paged is not undefined
> // which page, header default is "AG-Paging-Offset",
content default is "paging.offset"
> offset: {String},
> offsetVal: {Number}, // Default 0 for first page
>
> // items per page, header default is "AG-Paging-Limit",
content default is "paging.limit"
> limit: {String},
> limitVal: {Number}, // Default 5 items per page
>
> // total number of items, header default is
"AG-Paging-Total", content default is "paging.total"
> total: {String},
>
> // link to next page, default in both cases is undefined
> next: {String},
>
> // link to previous page, default in both cases is undefined
> prev: {String}
> }
> }
> }).pipes.pager;
>
> Getter/Setter methods should be provided for getting and updating the offsetVal and
limitVal defaults
>
> var defaultOffset = pagedPipe.getOffsetVal();
> pagedPipe.setOffsetVal( defaultOffset + 1 ); // by default the second page would
be returned
>
> var defaultLimit = pagedPipe.getLimitVal();
> pagedPipe.setLimitVal( defaultLimit + 5 ); // by default, 10 items would be
returned per page
>
> ## read()
> By default, a read() against a paged pipe will return the first page based on the
default offsetVal and limitVal. We could possible add an option that doesn't effect
unpaged pipes but on a paged pipe, it can be used to turn off paging for that read() and
get all data
>
> // Get first page
> pagedPipe.read({success callback handles data});
>
> // Get all data from paged pipe
> pagedPipe.read({
> page: false,
> success: handle the data
> });
>
> To avoid code duplication, **next**, **prev**, **first** and **last** pages can be
retrieved by passing an option to the read method of a paged pipe since other than some
paging housekeeping, the code would be the same. We can also use that same option as above
that was used to get all data from a paged pipe. One question, when requesting prev from
first page or next from last page, should it throw an error that needs to be handled or
just return and empty data set? I see advantages and disadvantages of both.
>
> // Get next page
> pagedPipe.read({
> page: "next",
> success: handle the data
> });
>
> // Get previous page
> pagedPipe.read({
> page: "prev",
> success: handle the data
> });
>
> // Get first page
> pagedPipe.read({
> page: "first",
> success: handle the data
> });
>
> // Get last page
> pagedPipe.read({
> page: "last",
> success: handle the data
> });
>
If I add a setter for "paged" that would effectively fix that on the JS side
since offset and limit are already updatable. Does that work for you?
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
At first glance I don't
like having the distinction between a "Pipe" and a "PagedPipe". In
Java land PagedPipe will be an interface which extends Pipe (this is no big deal) and
PagedRestAdatper would extend RestAdapted and implement PagedPipe. This isn't too bad
but it makes reusing paging logic a bit harder. (And also this is at first glance).
The biggest issue I see with a PagedPipe is it means a developer can't change his
paging preferences without creating a new Pipe.
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
8:28 p.m.
On Jan 14, 2013, at 1:14 PM, Lucas Holmquist <lholmqui(a)redhat.com> wrote:
On Jan 14, 2013, at 1:00 PM, Kris Borchers <kris(a)redhat.com> wrote:
Looks nice, couple comments inline
> OK folks, below is the contents of this gist https://gist.github.com/4531575. I may
have missed a number of things, gotten too specific in places or not specific enough in
others. This should hopefully get a good discussion going on how we want to handle paging
across all of the client libraries. Let's keep all comments on the list and not the
gist as much as possible to avoid breaking up the conversation.
>
> Below is a pipe configuration showing the different paging options. Defaults are just
suggestions and are up for discussion as much as the rest of it
>
> var pagedPipe = AeroGear.Pipeline({
> name: "pager",
> settings: {
> paged: {String}, // Default is "headers", can also be
"content", or undefined for no paging
> pageConfig: { // Only required if paged is not undefined
> // which page, header default is "AG-Paging-Offset",
content default is "paging.offset"
> offset: {String},
> offsetVal: {Number}, // Default 0 for first page
>
> // items per page, header default is "AG-Paging-Limit",
content default is "paging.limit"
> limit: {String},
> limitVal: {Number}, // Default 5 items per page
>
> // total number of items, header default is
"AG-Paging-Total", content default is "paging.total"
> total: {String},
>
> // link to next page, default in both cases is undefined
> next: {String},
>
> // link to previous page, default in both cases is undefined
> prev: {String}
> }
> }
> }).pipes.pager;
>
would it be beneficial, or would users be looking for it, if "next" and
"prev" could also be functions.
> Getter/Setter methods should be provided for getting and updating the offsetVal and
limitVal defaults
>
> var defaultOffset = pagedPipe.getOffsetVal();
> pagedPipe.setOffsetVal( defaultOffset + 1 ); // by default the second page would
be returned
>
> var defaultLimit = pagedPipe.getLimitVal();
> pagedPipe.setLimitVal( defaultLimit + 5 ); // by default, 10 items would be
returned per page
>
> ## read()
> By default, a read() against a paged pipe will return the first page based on the
default offsetVal and limitVal. We could possible add an option that doesn't effect
unpaged pipes but on a paged pipe, it can be used to turn off paging for that read() and
get all data
>
> // Get first page
> pagedPipe.read({success callback handles data});
>
> // Get all data from paged pipe
> pagedPipe.read({
> page: false,
> success: handle the data
> });
>
> To avoid code duplication, **next**, **prev**, **first** and **last** pages can be
retrieved by passing an option to the read method of a paged pipe since other than some
paging housekeeping, the code would be the same. We can also use that same option as above
that was used to get all data from a paged pipe. One question, when requesting prev from
first page or next from last page, should it throw an error that needs to be handled or
just return and empty data set? I see advantages and disadvantages of both.
Will we know what page they are one before the read. If so, then we can save the request
just to throw the error. This would might be better just for calling prev on the first
page, since the last page could also be growing
We could do that. We could just create those methods that call read with the specified
options.
>
> // Get next page
> pagedPipe.read({
> page: "next",
> success: handle the data
> });
>
> // Get previous page
> pagedPipe.read({
> page: "prev",
> success: handle the data
> });
>
> // Get first page
> pagedPipe.read({
> page: "first",
> success: handle the data
> });
>
> // Get last page
> pagedPipe.read({
> page: "last",
> success: handle the data
> });
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
8:28 p.m.
On 01/14/2013 02:21 PM, Matthias Wessendorf wrote:
On Mon, Jan 14, 2013 at 8:17 PM, Summers Pittman <supittma(a)redhat.com
<mailto:supittma@redhat.com>> wrote:
On 01/14/2013 01:00 PM, Kris Borchers wrote:
> OK folks, below is the contents of this gist
> https://gist.github.com/4531575. I may have missed a number of
> things, gotten too specific in places or not specific enough in
> others. This should hopefully get a good discussion going on how
> we want to handle paging across all of the client libraries.
> Let's keep all comments on the list and not the gist as much as
> possible to avoid breaking up the conversation.
>
> Below is a pipe configuration showing the different paging
> options. Defaults are just suggestions and are up for discussion
> as much as the rest of it
>
> var pagedPipe = AeroGear.Pipeline({
> name: "pager",
> settings: {
> paged: {String}, // Default is "headers", can also be
> "content", or undefined for no paging
> pageConfig: { // Only required if paged is not undefined
> // which page, header default is
> "AG-Paging-Offset", content default is "paging.offset"
> offset: {String},
> offsetVal: {Number}, // Default 0 for first page
> // items per page, header default is
> "AG-Paging-Limit", content default is "paging.limit"
> limit: {String},
> limitVal: {Number}, // Default 5 items per page
> // total number of items, header default is
> "AG-Paging-Total", content default is "paging.total"
> total: {String},
> // link to next page, default in both cases is
> undefined
> next: {String},
> // link to previous page, default in both cases
> is undefined
> prev: {String}
> }
> }
> }).pipes.pager;
>
> Getter/Setter methods should be provided for getting and updating
> the offsetVal and limitVal defaults
>
> var defaultOffset = pagedPipe.getOffsetVal();
> pagedPipe.setOffsetVal( defaultOffset + 1 ); // by default
> the second page would be returned
> var defaultLimit = pagedPipe.getLimitVal();
> pagedPipe.setLimitVal( defaultLimit + 5 ); // by default, 10
> items would be returned per page
>
> ## read()
> By default, a read() against a paged pipe will return the first
> page based on the default offsetVal and limitVal. We could
> possible add an option that doesn't effect unpaged pipes but on a
> paged pipe, it can be used to turn off paging for that read() and
> get all data
>
> // Get first page
> pagedPipe.read({success callback handles data});
> // Get all data from paged pipe
> pagedPipe.read({
> page: false,
> success: handle the data
> });
> To avoid code duplication, **next**, **prev**, **first** and
> **last** pages can be retrieved by passing an option to the read
> method of a paged pipe since other than some paging housekeeping,
> the code would be the same. We can also use that same option as
> above that was used to get all data from a paged pipe. One
> question, when requesting prev from first page or next from last
> page, should it throw an error that needs to be handled or just
> return and empty data set? I see advantages and disadvantages of
> both.
>
> // Get next page
> pagedPipe.read({
> page: "next",
> success: handle the data
> });
> // Get previous page
> pagedPipe.read({
> page: "prev",
> success: handle the data
> });
> // Get first page
> pagedPipe.read({
> page: "first",
> success: handle the data
> });
> // Get last page
> pagedPipe.read({
> page: "last",
> success: handle the data
> });
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
At first glance I don't like having the distinction between a
"Pipe" and a "PagedPipe". In Java land PagedPipe will be an
interface which extends Pipe (this is no big deal) and
PagedRestAdatper would extend RestAdapted and implement
PagedPipe. This isn't too bad but it makes reusing paging logic a
bit harder. (And also this is at first glance).
haven't thought about typing, but a subclass (in iOS / Java land)
sounds reasonable.
I say it makes reusing the paging logic harder because the thing
which
can page is a subclass of RestAdapter. If we could somehow composite
Paging into rest adapter it would work out better. Composition is a bit
more work to get "right" than inheritance. (I say "right" because if
it
is done wrong the classes end up being too tightly coupled and you might
as well have used inheritance to begin with).
Will post something 2morrow
The biggest issue I see with a PagedPipe is it means a developer
can't change his paging preferences without creating a new Pipe.
oh, I could not update the settings? That's a -1
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
8:29 p.m.
On 01/14/2013 02:27 PM, Kris Borchers wrote:
On Jan 14, 2013, at 1:17 PM, Summers Pittman <supittma(a)redhat.com
<mailto:supittma@redhat.com>> wrote:
> On 01/14/2013 01:00 PM, Kris Borchers wrote:
>> OK folks, below is the contents of this gist
>> https://gist.github.com/4531575. I may have missed a number of
>> things, gotten too specific in places or not specific enough in
>> others. This should hopefully get a good discussion going on how we
>> want to handle paging across all of the client libraries. Let's keep
>> all comments on the list and not the gist as much as possible to
>> avoid breaking up the conversation.
>>
>> Below is a pipe configuration showing the different paging options.
>> Defaults are just suggestions and are up for discussion as much as
>> the rest of it
>>
>> var pagedPipe = AeroGear.Pipeline({
>> name: "pager",
>> settings: {
>> paged: {String}, // Default is "headers", can also be
>> "content", or undefined for no paging
>> pageConfig: { // Only required if paged is not undefined
>> // which page, header default is "AG-Paging-Offset",
>> content default is "paging.offset"
>> offset: {String},
>> offsetVal: {Number}, // Default 0 for first page
>> // items per page, header default is
>> "AG-Paging-Limit", content default is "paging.limit"
>> limit: {String},
>> limitVal: {Number}, // Default 5 items per page
>> // total number of items, header default is
>> "AG-Paging-Total", content default is "paging.total"
>> total: {String},
>> // link to next page, default in both cases is undefined
>> next: {String},
>> // link to previous page, default in both cases is
>> undefined
>> prev: {String}
>> }
>> }
>> }).pipes.pager;
>>
>> Getter/Setter methods should be provided for getting and updating
>> the offsetVal and limitVal defaults
>>
>> var defaultOffset = pagedPipe.getOffsetVal();
>> pagedPipe.setOffsetVal( defaultOffset + 1 ); // by default the
>> second page would be returned
>> var defaultLimit = pagedPipe.getLimitVal();
>> pagedPipe.setLimitVal( defaultLimit + 5 ); // by default, 10
>> items would be returned per page
>>
>> ## read()
>> By default, a read() against a paged pipe will return the first page
>> based on the default offsetVal and limitVal. We could possible add
>> an option that doesn't effect unpaged pipes but on a paged pipe, it
>> can be used to turn off paging for that read() and get all data
>>
>> // Get first page
>> pagedPipe.read({success callback handles data});
>> // Get all data from paged pipe
>> pagedPipe.read({
>> page: false,
>> success: handle the data
>> });
>> To avoid code duplication, **next**, **prev**, **first** and
>> **last** pages can be retrieved by passing an option to the read
>> method of a paged pipe since other than some paging housekeeping,
>> the code would be the same. We can also use that same option as
>> above that was used to get all data from a paged pipe. One question,
>> when requesting prev from first page or next from last page, should
>> it throw an error that needs to be handled or just return and empty
>> data set? I see advantages and disadvantages of both.
>>
>> // Get next page
>> pagedPipe.read({
>> page: "next",
>> success: handle the data
>> });
>> // Get previous page
>> pagedPipe.read({
>> page: "prev",
>> success: handle the data
>> });
>> // Get first page
>> pagedPipe.read({
>> page: "first",
>> success: handle the data
>> });
>> // Get last page
>> pagedPipe.read({
>> page: "last",
>> success: handle the data
>> });
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> At first glance I don't like having the distinction between a "Pipe"
> and a "PagedPipe". In Java land PagedPipe will be an interface which
> extends Pipe (this is no big deal) and PagedRestAdatper would extend
> RestAdapted and implement PagedPipe. This isn't too bad but it makes
> reusing paging logic a bit harder. (And also this is at first glance).
>
> The biggest issue I see with a PagedPipe is it means a developer
> can't change his paging preferences without creating a new Pipe.
If I add a setter for "paged" that would effectively fix that on the
JS side since offset and limit are already updatable. Does that work
for you?
No because I think fundamentally paging is part of the query and not
part of the pipe.
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
8:34 p.m.
On Jan 14, 2013, at 1:29 PM, Summers Pittman <supittma(a)redhat.com> wrote:
On 01/14/2013 02:27 PM, Kris Borchers wrote:
>
> On Jan 14, 2013, at 1:17 PM, Summers Pittman <supittma(a)redhat.com> wrote:
>
>> On 01/14/2013 01:00 PM, Kris Borchers wrote:
>>> OK folks, below is the contents of this gist https://gist.github.com/4531575.
I may have missed a number of things, gotten too specific in places or not specific enough
in others. This should hopefully get a good discussion going on how we want to handle
paging across all of the client libraries. Let's keep all comments on the list and not
the gist as much as possible to avoid breaking up the conversation.
>>>
>>> Below is a pipe configuration showing the different paging options. Defaults
are just suggestions and are up for discussion as much as the rest of
it
>>>
>>> var pagedPipe = AeroGear.Pipeline({
>>> name: "pager",
>>> settings: {
>>> paged: {String}, // Default is "headers", can also be
"content", or undefined for no paging
>>> pageConfig: { // Only required if paged is not undefined
>>> // which page, header default is
"AG-Paging-Offset", content default is "paging.offset"
>>> offset: {String},
>>> offsetVal: {Number}, // Default 0 for first page
>>>
>>> // items per page, header default is
"AG-Paging-Limit", content default is "paging.limit"
>>> limit: {String},
>>> limitVal: {Number}, // Default 5 items per page
>>>
>>> // total number of items, header default is
"AG-Paging-Total", content default is "paging.total"
>>> total: {String},
>>>
>>> // link to next page, default in both cases is undefined
>>> next: {String},
>>>
>>> // link to previous page, default in both cases is undefined
>>> prev: {String}
>>> }
>>> }
>>> }).pipes.pager;
>>>
>>> Getter/Setter methods should be provided for getting and updating the
offsetVal and limitVal defaults
>>>
>>> var defaultOffset = pagedPipe.getOffsetVal();
>>> pagedPipe.setOffsetVal( defaultOffset + 1 ); // by default the second
page would be returned
>>>
>>> var defaultLimit = pagedPipe.getLimitVal();
>>> pagedPipe.setLimitVal( defaultLimit + 5 ); // by default, 10 items would
be returned per page
>>>
>>> ## read()
>>> By default, a read() against a paged pipe will return the first page based on
the default offsetVal and limitVal. We could possible add an option that doesn't
effect unpaged pipes but on a paged pipe, it can be used to turn off paging for that
read() and get all data
>>>
>>> // Get first page
>>> pagedPipe.read({success callback handles data});
>>>
>>> // Get all data from paged pipe
>>> pagedPipe.read({
>>> page: false,
>>> success: handle the data
>>> });
>>>
>>> To avoid code duplication, **next**, **prev**, **first** and **last** pages
can be retrieved by passing an option to the read method of a paged pipe since other than
some paging housekeeping, the code would be the same. We can also use that same option as
above that was used to get all data from a paged pipe. One question,
when requesting prev from first page or next from last page, should it throw an error that
needs to be handled or just return and empty data set? I see advantages and disadvantages
of both.
>>>
>>> // Get next page
>>> pagedPipe.read({
>>> page: "next",
>>> success: handle the data
>>> });
>>>
>>> // Get previous page
>>> pagedPipe.read({
>>> page: "prev",
>>> success: handle the data
>>> });
>>>
>>> // Get first page
>>> pagedPipe.read({
>>> page: "first",
>>> success: handle the data
>>> });
>>>
>>> // Get last page
>>> pagedPipe.read({
>>> page: "last",
>>> success: handle the data
>>> });
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> At first glance I don't like having the distinction between a
"Pipe" and a "PagedPipe". In Java land PagedPipe will be an interface
which extends Pipe (this is no big deal) and PagedRestAdatper would extend RestAdapted and
implement PagedPipe. This isn't too bad but it makes reusing paging logic a bit
harder. (And also this is at first glance).
>>
>> The biggest issue I see with a PagedPipe is it means a developer can't change
his paging preferences without creating a new Pipe.
>
> If I add a setter for "paged" that would effectively fix that on the JS
side since offset and limit are already updatable. Does that work for you?
No because I think fundamentally paging is part of the query and not part of the pipe.
OK, but then this is where I don't see the value in adding next/prev/first/last
methods if I have to pass parameters (that aren't already stored on the pipe) with
every use. Then as a developer, I might as well just use the basic query option in
JS's read method, specify my parameters and call it a day and have less stuff to sort
through in the docs on how to do paging.
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
8:36 p.m.
On 01/14/2013 02:34 PM, Kris Borchers wrote:
On Jan 14, 2013, at 1:29 PM, Summers Pittman <supittma(a)redhat.com
<mailto:supittma@redhat.com>> wrote:
> On 01/14/2013 02:27 PM, Kris Borchers wrote:
>>
>> On Jan 14, 2013, at 1:17 PM, Summers Pittman <supittma(a)redhat.com
>> <mailto:supittma@redhat.com>> wrote:
>>
>>> On 01/14/2013 01:00 PM, Kris Borchers wrote:
>>>> OK folks, below is the contents of this gist
>>>> https://gist.github.com/4531575. I may have missed a number of
>>>> things, gotten too specific in places or not specific enough in
>>>> others. This should hopefully get a good discussion going on how
>>>> we want to handle paging across all of the client libraries. Let's
>>>> keep all comments on the list and not the gist as much as possible
>>>> to avoid breaking up the conversation.
>>>>
>>>> Below is a pipe configuration showing the different paging
>>>> options. Defaults are just suggestions and are up for discussion
>>>> as much as the rest of it
>>>>
>>>> var pagedPipe = AeroGear.Pipeline({
>>>> name: "pager",
>>>> settings: {
>>>> paged: {String}, // Default is "headers", can also
be
>>>> "content", or undefined for no paging
>>>> pageConfig: { // Only required if paged is not undefined
>>>> // which page, header default is
>>>> "AG-Paging-Offset", content default is
"paging.offset"
>>>> offset: {String},
>>>> offsetVal: {Number}, // Default 0 for first page
>>>> // items per page, header default is
>>>> "AG-Paging-Limit", content default is "paging.limit"
>>>> limit: {String},
>>>> limitVal: {Number}, // Default 5 items per page
>>>> // total number of items, header default is
>>>> "AG-Paging-Total", content default is "paging.total"
>>>> total: {String},
>>>> // link to next page, default in both cases is
>>>> undefined
>>>> next: {String},
>>>> // link to previous page, default in both cases is
>>>> undefined
>>>> prev: {String}
>>>> }
>>>> }
>>>> }).pipes.pager;
>>>>
>>>> Getter/Setter methods should be provided for getting and updating
>>>> the offsetVal and limitVal defaults
>>>>
>>>> var defaultOffset = pagedPipe.getOffsetVal();
>>>> pagedPipe.setOffsetVal( defaultOffset + 1 ); // by default the
>>>> second page would be returned
>>>> var defaultLimit = pagedPipe.getLimitVal();
>>>> pagedPipe.setLimitVal( defaultLimit + 5 ); // by default, 10
>>>> items would be returned per page
>>>>
>>>> ## read()
>>>> By default, a read() against a paged pipe will return the first
>>>> page based on the default offsetVal and limitVal. We could
>>>> possible add an option that doesn't effect unpaged pipes but on a
>>>> paged pipe, it can be used to turn off paging for that read() and
>>>> get all data
>>>>
>>>> // Get first page
>>>> pagedPipe.read({success callback handles data});
>>>> // Get all data from paged pipe
>>>> pagedPipe.read({
>>>> page: false,
>>>> success: handle the data
>>>> });
>>>> To avoid code duplication, **next**, **prev**, **first** and
>>>> **last** pages can be retrieved by passing an option to the read
>>>> method of a paged pipe since other than some paging housekeeping,
>>>> the code would be the same. We can also use that same option as
>>>> above that was used to get all data from a paged pipe. One
>>>> question, when requesting prev from first page or next from last
>>>> page, should it throw an error that needs to be handled or just
>>>> return and empty data set? I see advantages and disadvantages of both.
>>>>
>>>> // Get next page
>>>> pagedPipe.read({
>>>> page: "next",
>>>> success: handle the data
>>>> });
>>>> // Get previous page
>>>> pagedPipe.read({
>>>> page: "prev",
>>>> success: handle the data
>>>> });
>>>> // Get first page
>>>> pagedPipe.read({
>>>> page: "first",
>>>> success: handle the data
>>>> });
>>>> // Get last page
>>>> pagedPipe.read({
>>>> page: "last",
>>>> success: handle the data
>>>> });
>>>>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> At first glance I don't like having the distinction between a
>>> "Pipe" and a "PagedPipe". In Java land PagedPipe will be
an
>>> interface which extends Pipe (this is no big deal) and
>>> PagedRestAdatper would extend RestAdapted and implement PagedPipe.
>>> This isn't too bad but it makes reusing paging logic a bit harder.
>>> (And also this is at first glance).
>>>
>>> The biggest issue I see with a PagedPipe is it means a developer
>>> can't change his paging preferences without creating a new Pipe.
>>
>> If I add a setter for "paged" that would effectively fix that on the
>> JS side since offset and limit are already updatable. Does that work
>> for you?
> No because I think fundamentally paging is part of the query and not
> part of the pipe.
OK, but then this is where I don't see the value in adding
next/prev/first/last methods if I have to pass parameters (that aren't
already stored on the pipe) with every use. Then as a developer, I
might as well just use the basic query option in JS's read method,
specify my parameters and call it a day and have less stuff to sort
through in the docs on how to do paging.
https://gist.github.com/4532661
That is a way to do paging which keeps Pipes immutable, uses
readWithFilter, and doesn't impose any (for convenient definitions of
any) bookkeeping on the developer.
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
8:45 p.m.
On Jan 14, 2013, at 1:36 PM, Summers Pittman <supittma(a)redhat.com> wrote:
On 01/14/2013 02:34 PM, Kris Borchers wrote:
>
> On Jan 14, 2013, at 1:29 PM, Summers Pittman <supittma(a)redhat.com> wrote:
>
>> On 01/14/2013 02:27 PM, Kris Borchers wrote:
>>>
>>> On Jan 14, 2013, at 1:17 PM, Summers Pittman <supittma(a)redhat.com>
wrote:
>>>
>>>> On 01/14/2013 01:00 PM, Kris Borchers wrote:
>>>>> OK folks, below is the contents of this gist
https://gist.github.com/4531575. I may have missed a number of things, gotten too specific
in places or not specific enough in others. This should hopefully get a good discussion
going on how we want to handle paging across all of the client libraries. Let's keep
all comments on the list and not the gist as much as possible to avoid breaking up the
conversation.
>>>>>
>>>>> Below is a pipe configuration showing the different paging options.
Defaults are just suggestions and are up for discussion as much as the rest of it
>>>>>
>>>>> var pagedPipe = AeroGear.Pipeline({
>>>>> name: "pager",
>>>>> settings: {
>>>>> paged: {String}, // Default is "headers", can
also be "content", or undefined for no paging
>>>>> pageConfig: { // Only required if paged is not undefined
>>>>> // which page, header default is
"AG-Paging-Offset", content default is "paging.offset"
>>>>> offset: {String},
>>>>> offsetVal: {Number}, // Default 0 for first page
>>>>>
>>>>> // items per page, header default is
"AG-Paging-Limit", content default is "paging.limit"
>>>>> limit: {String},
>>>>> limitVal: {Number}, // Default 5 items per page
>>>>>
>>>>> // total number of items, header default is
"AG-Paging-Total", content default is "paging.total"
>>>>> total: {String},
>>>>>
>>>>> // link to next page, default in both cases is
undefined
>>>>> next: {String},
>>>>>
>>>>> // link to previous page, default in both cases is
undefined
>>>>> prev: {String}
>>>>> }
>>>>> }
>>>>> }).pipes.pager;
>>>>>
>>>>> Getter/Setter methods should be provided for getting and updating the
offsetVal and limitVal defaults
>>>>>
>>>>> var defaultOffset = pagedPipe.getOffsetVal();
>>>>> pagedPipe.setOffsetVal( defaultOffset + 1 ); // by default the
second page would be returned
>>>>>
>>>>> var defaultLimit = pagedPipe.getLimitVal();
>>>>> pagedPipe.setLimitVal( defaultLimit + 5 ); // by default, 10
items would be returned per page
>>>>>
>>>>> ## read()
>>>>> By default, a read() against a paged pipe will return the first page
based on the default offsetVal and limitVal. We could possible add an option that
doesn't effect unpaged pipes but on a paged pipe, it can be used to turn off paging
for that read() and get all data
>>>>>
>>>>> // Get first page
>>>>> pagedPipe.read({success callback handles data});
>>>>>
>>>>> // Get all data from paged pipe
>>>>> pagedPipe.read({
>>>>> page: false,
>>>>> success: handle the data
>>>>> });
>>>>>
>>>>> To avoid code duplication, **next**, **prev**, **first** and **last**
pages can be retrieved by passing an option to the read method of a paged pipe since other
than some paging housekeeping, the code would be the same. We can also use that same
option as above that was used to get all data from a paged pipe. One question, when
requesting prev from first page or next from last page, should it throw an error that
needs to be handled or just return and empty data set? I see advantages and disadvantages
of both.
>>>>>
>>>>> // Get next page
>>>>> pagedPipe.read({
>>>>> page: "next",
>>>>> success: handle the data
>>>>> });
>>>>>
>>>>> // Get previous page
>>>>> pagedPipe.read({
>>>>> page: "prev",
>>>>> success: handle the data
>>>>> });
>>>>>
>>>>> // Get first page
>>>>> pagedPipe.read({
>>>>> page: "first",
>>>>> success: handle the data
>>>>> });
>>>>>
>>>>> // Get last page
>>>>> pagedPipe.read({
>>>>> page: "last",
>>>>> success: handle the data
>>>>> });
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>> At first glance I don't like having the distinction between a
"Pipe" and a "PagedPipe". In Java land PagedPipe will be an interface
which extends Pipe (this is no big deal) and PagedRestAdatper would extend RestAdapted and
implement PagedPipe. This isn't too bad but it makes reusing paging logic a bit
harder. (And also this is at first glance).
>>>>
>>>> The biggest issue I see with a PagedPipe is it means a developer
can't change his paging preferences without creating a new Pipe.
>>>
>>> If I add a setter for "paged" that would effectively fix that on
the JS side since offset and limit are already updatable. Does that work for you?
>> No because I think fundamentally paging is part of the query and not part of the
pipe.
>
> OK, but then this is where I don't see the value in adding next/prev/first/last
methods if I have to pass parameters (that aren't already stored on the pipe) with
every use. Then as a developer, I might as well just use the basic query option in
JS's read method, specify my parameters and call it a day and have less stuff to sort
through in the docs on how to do paging.
https://gist.github.com/4532661
That is a way to do paging which keeps Pipes immutable, uses readWithFilter, and
doesn't impose any (for convenient definitions of any) bookkeeping on the developer.
This just feels like we're killing the dynamic nature of JS. :)
>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
8:47 p.m.
On Jan 14, 2013, at 1:46 PM, Douglas Campos <qmx(a)qmx.me> wrote:
On 14/01/2013, at 17:17, Summers Pittman <supittma(a)redhat.com> wrote:
> The biggest issue I see with a PagedPipe is it means a developer can't change his
paging preferences without creating a new Pipe.
why would I want to change paging mid-flight?
I'm not sure on paged vs. non-paged but i could see the desire to change limit.
-- qmx
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
8:48 p.m.
On 01/14/2013 02:45 PM, Kris Borchers wrote:
On Jan 14, 2013, at 1:36 PM, Summers Pittman <supittma(a)redhat.com
<mailto:supittma@redhat.com>> wrote:
> On 01/14/2013 02:34 PM, Kris Borchers wrote:
>>
>> On Jan 14, 2013, at 1:29 PM, Summers Pittman <supittma(a)redhat.com
>> <mailto:supittma@redhat.com>> wrote:
>>
>>> On 01/14/2013 02:27 PM, Kris Borchers wrote:
>>>>
>>>> On Jan 14, 2013, at 1:17 PM, Summers Pittman <supittma(a)redhat.com
>>>> <mailto:supittma@redhat.com>> wrote:
>>>>
>>>>> On 01/14/2013 01:00 PM, Kris Borchers wrote:
>>>>>> OK folks, below is the contents of this gist
>>>>>> https://gist.github.com/4531575. I may have missed a number of
>>>>>> things, gotten too specific in places or not specific enough in
>>>>>> others. This should hopefully get a good discussion going on how
>>>>>> we want to handle paging across all of the client libraries.
>>>>>> Let's keep all comments on the list and not the gist as much
as
>>>>>> possible to avoid breaking up the conversation.
>>>>>>
>>>>>> Below is a pipe configuration showing the different paging
>>>>>> options. Defaults are just suggestions and are up for discussion
>>>>>> as much as the rest of it
>>>>>>
>>>>>> var pagedPipe = AeroGear.Pipeline({
>>>>>> name: "pager",
>>>>>> settings: {
>>>>>> paged: {String}, // Default is "headers",
can also
>>>>>> be "content", or undefined for no paging
>>>>>> pageConfig: { // Only required if paged is not
undefined
>>>>>> // which page, header default is
>>>>>> "AG-Paging-Offset", content default is
"paging.offset"
>>>>>> offset: {String},
>>>>>> offsetVal: {Number}, // Default 0 for first page
>>>>>> // items per page, header default is
>>>>>> "AG-Paging-Limit", content default is
"paging.limit"
>>>>>> limit: {String},
>>>>>> limitVal: {Number}, // Default 5 items per page
>>>>>> // total number of items, header default is
>>>>>> "AG-Paging-Total", content default is
"paging.total"
>>>>>> total: {String},
>>>>>> // link to next page, default in both cases is
>>>>>> undefined
>>>>>> next: {String},
>>>>>> // link to previous page, default in both cases
>>>>>> is undefined
>>>>>> prev: {String}
>>>>>> }
>>>>>> }
>>>>>> }).pipes.pager;
>>>>>>
>>>>>> Getter/Setter methods should be provided for getting and
>>>>>> updating the offsetVal and limitVal defaults
>>>>>>
>>>>>> var defaultOffset = pagedPipe.getOffsetVal();
>>>>>> pagedPipe.setOffsetVal( defaultOffset + 1 ); // by default
>>>>>> the second page would be returned
>>>>>> var defaultLimit = pagedPipe.getLimitVal();
>>>>>> pagedPipe.setLimitVal( defaultLimit + 5 ); // by default, 10
>>>>>> items would be returned per page
>>>>>>
>>>>>> ## read()
>>>>>> By default, a read() against a paged pipe will return the first
>>>>>> page based on the default offsetVal and limitVal. We could
>>>>>> possible add an option that doesn't effect unpaged pipes but
on
>>>>>> a paged pipe, it can be used to turn off paging for that read()
>>>>>> and get all data
>>>>>>
>>>>>> // Get first page
>>>>>> pagedPipe.read({success callback handles data});
>>>>>> // Get all data from paged pipe
>>>>>> pagedPipe.read({
>>>>>> page: false,
>>>>>> success: handle the data
>>>>>> });
>>>>>> To avoid code duplication, **next**, **prev**, **first** and
>>>>>> **last** pages can be retrieved by passing an option to the read
>>>>>> method of a paged pipe since other than some paging
>>>>>> housekeeping, the code would be the same. We can also use that
>>>>>> same option as above that was used to get all data from a paged
>>>>>> pipe. One question, when requesting prev from first page or next
>>>>>> from last page, should it throw an error that needs to be
>>>>>> handled or just return and empty data set? I see advantages and
>>>>>> disadvantages of both.
>>>>>>
>>>>>> // Get next page
>>>>>> pagedPipe.read({
>>>>>> page: "next",
>>>>>> success: handle the data
>>>>>> });
>>>>>> // Get previous page
>>>>>> pagedPipe.read({
>>>>>> page: "prev",
>>>>>> success: handle the data
>>>>>> });
>>>>>> // Get first page
>>>>>> pagedPipe.read({
>>>>>> page: "first",
>>>>>> success: handle the data
>>>>>> });
>>>>>> // Get last page
>>>>>> pagedPipe.read({
>>>>>> page: "last",
>>>>>> success: handle the data
>>>>>> });
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> aerogear-dev mailing list
>>>>>> aerogear-dev(a)lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>> At first glance I don't like having the distinction between a
>>>>> "Pipe" and a "PagedPipe". In Java land PagedPipe
will be an
>>>>> interface which extends Pipe (this is no big deal) and
>>>>> PagedRestAdatper would extend RestAdapted and implement
>>>>> PagedPipe. This isn't too bad but it makes reusing paging logic
>>>>> a bit harder. (And also this is at first glance).
>>>>>
>>>>> The biggest issue I see with a PagedPipe is it means a developer
>>>>> can't change his paging preferences without creating a new Pipe.
>>>>
>>>> If I add a setter for "paged" that would effectively fix that
on
>>>> the JS side since offset and limit are already updatable. Does
>>>> that work for you?
>>> No because I think fundamentally paging is part of the query and
>>> not part of the pipe.
>>
>> OK, but then this is where I don't see the value in adding
>> next/prev/first/last methods if I have to pass parameters (that
>> aren't already stored on the pipe) with every use. Then as a
>> developer, I might as well just use the basic query option in JS's
>> read method, specify my parameters and call it a day and have less
>> stuff to sort through in the docs on how to do paging.
> https://gist.github.com/4532661
>
> That is a way to do paging which keeps Pipes immutable, uses
> readWithFilter, and doesn't impose any (for convenient definitions of
> any) bookkeeping on the developer.
This just feels like we're killing the dynamic nature of JS. :)
Well this is a
an description of a Java implementation.
Instead of a separate PageContext what if readWithFilter() returns a
PagedList which has next() and prev() as methods on it? In java this
can implement a list and be cast at runtime. The only question is does
next() return a new PagedList or return void and update the current
pagedlist?
>>
>>>>>
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev(a)lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
8:50 p.m.
On Jan 14, 2013, at 1:48 PM, Summers Pittman <supittma(a)redhat.com> wrote:
On 01/14/2013 02:45 PM, Kris Borchers wrote:
>
> On Jan 14, 2013, at 1:36 PM, Summers Pittman <supittma(a)redhat.com> wrote:
>
>> On 01/14/2013 02:34 PM, Kris Borchers wrote:
>>>
>>> On Jan 14, 2013, at 1:29 PM, Summers Pittman <supittma(a)redhat.com>
wrote:
>>>
>>>> On 01/14/2013 02:27 PM, Kris Borchers wrote:
>>>>>
>>>>> On Jan 14, 2013, at 1:17 PM, Summers Pittman
<supittma(a)redhat.com> wrote:
>>>>>
>>>>>> On 01/14/2013 01:00 PM, Kris Borchers wrote:
>>>>>>> OK folks, below is the contents of this gist
https://gist.github.com/4531575. I may have missed a number of things, gotten too specific
in places or not specific enough in others. This should hopefully get a good discussion
going on how we want to handle paging across all of the client libraries. Let's keep
all comments on the list and not the gist as much as possible to avoid breaking up the
conversation.
>>>>>>>
>>>>>>> Below is a pipe configuration showing the different paging
options. Defaults are just suggestions and are up for discussion as much as the rest of
it
>>>>>>>
>>>>>>> var pagedPipe = AeroGear.Pipeline({
>>>>>>> name: "pager",
>>>>>>> settings: {
>>>>>>> paged: {String}, // Default is
"headers", can also be "content", or undefined for no paging
>>>>>>> pageConfig: { // Only required if paged is not
undefined
>>>>>>> // which page, header default is
"AG-Paging-Offset", content default is "paging.offset"
>>>>>>> offset: {String},
>>>>>>> offsetVal: {Number}, // Default 0 for first
page
>>>>>>>
>>>>>>> // items per page, header default is
"AG-Paging-Limit", content default is "paging.limit"
>>>>>>> limit: {String},
>>>>>>> limitVal: {Number}, // Default 5 items per
page
>>>>>>>
>>>>>>> // total number of items, header default is
"AG-Paging-Total", content default is "paging.total"
>>>>>>> total: {String},
>>>>>>>
>>>>>>> // link to next page, default in both cases
is undefined
>>>>>>> next: {String},
>>>>>>>
>>>>>>> // link to previous page, default in both
cases is undefined
>>>>>>> prev: {String}
>>>>>>> }
>>>>>>> }
>>>>>>> }).pipes.pager;
>>>>>>>
>>>>>>> Getter/Setter methods should be provided for getting and
updating the offsetVal and limitVal defaults
>>>>>>>
>>>>>>> var defaultOffset = pagedPipe.getOffsetVal();
>>>>>>> pagedPipe.setOffsetVal( defaultOffset + 1 ); // by
default the second page would be returned
>>>>>>>
>>>>>>> var defaultLimit = pagedPipe.getLimitVal();
>>>>>>> pagedPipe.setLimitVal( defaultLimit + 5 ); // by default,
10 items would be returned per page
>>>>>>>
>>>>>>> ## read()
>>>>>>> By default, a read() against a paged pipe will return the
first page based on the default offsetVal and limitVal. We could possible add an option
that doesn't effect unpaged pipes but on a paged pipe, it can be used to turn off
paging for that read() and get all data
>>>>>>>
>>>>>>> // Get first page
>>>>>>> pagedPipe.read({success callback handles data});
>>>>>>>
>>>>>>> // Get all data from paged pipe
>>>>>>> pagedPipe.read({
>>>>>>> page: false,
>>>>>>> success: handle the data
>>>>>>> });
>>>>>>>
>>>>>>> To avoid code duplication, **next**, **prev**, **first** and
**last** pages can be retrieved by passing an option to the read method of a paged pipe
since other than some paging housekeeping, the code would be the same. We can also use
that same option as above that was used to get all data from a paged pipe. One question,
when requesting prev from first page or next from last page, should it throw an error that
needs to be handled or just return and empty data set? I see advantages and disadvantages
of both.
>>>>>>>
>>>>>>> // Get next page
>>>>>>> pagedPipe.read({
>>>>>>> page: "next",
>>>>>>> success: handle the data
>>>>>>> });
>>>>>>>
>>>>>>> // Get previous page
>>>>>>> pagedPipe.read({
>>>>>>> page: "prev",
>>>>>>> success: handle the data
>>>>>>> });
>>>>>>>
>>>>>>> // Get first page
>>>>>>> pagedPipe.read({
>>>>>>> page: "first",
>>>>>>> success: handle the data
>>>>>>> });
>>>>>>>
>>>>>>> // Get last page
>>>>>>> pagedPipe.read({
>>>>>>> page: "last",
>>>>>>> success: handle the data
>>>>>>> });
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> aerogear-dev mailing list
>>>>>>> aerogear-dev(a)lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>> At first glance I don't like having the distinction between a
"Pipe" and a "PagedPipe". In Java land PagedPipe will be an interface
which extends Pipe (this is no big deal) and PagedRestAdatper would extend RestAdapted and
implement PagedPipe. This isn't too bad but it makes reusing paging logic a bit
harder. (And also this is at first glance).
>>>>>>
>>>>>> The biggest issue I see with a PagedPipe is it means a developer
can't change his paging preferences without creating a new Pipe.
>>>>>
>>>>> If I add a setter for "paged" that would effectively fix
that on the JS side since offset and limit are already updatable. Does that work for you?
>>>> No because I think fundamentally paging is part of the query and not part
of the pipe.
>>>
>>> OK, but then this is where I don't see the value in adding
next/prev/first/last methods if I have to pass parameters (that aren't already stored
on the pipe) with every use. Then as a developer, I might as well just use the basic query
option in JS's read method, specify my parameters and call it a day and have less
stuff to sort through in the docs on how to do paging.
>> https://gist.github.com/4532661
>>
>> That is a way to do paging which keeps Pipes immutable, uses readWithFilter, and
doesn't impose any (for convenient definitions of any) bookkeeping on the developer.
>
> This just feels like we're killing the dynamic nature of JS. :)
Well this is a an description of a Java implementation.
Instead of a separate PageContext what if readWithFilter() returns a PagedList which has
next() and prev() as methods on it? In java this can implement a list and be cast at
runtime. The only question is does next() return a new PagedList or return void and
update the current pagedlist?
My problem with that is I would expect read() and readWithFilter() (though I still
maintain JS only needs read()), to both return a Promise since the call to the server is
async. I guess I could return some object which also includes that Promise along with
other stuff but just doesn't feel right.
>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> aerogear-dev mailing list
>>>>>> aerogear-dev(a)lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
8:51 p.m.
On 14/01/2013, at 17:48, Summers Pittman <supittma(a)redhat.com> wrote:
> This just feels like we're killing the dynamic nature of JS.
:)
Well this is a an description of a Java implementation.
I lol'd
Instead of a separate PageContext what if readWithFilter() returns a
PagedList which has next() and prev() as methods on it? In java this can implement a list
and be cast at runtime. The only question is does next() return a new PagedList or return
void and update the current pagedlist?
Well, matzew gave me earlier the idea that a PagedResult makes more sense, and calling
next() returns a List<T> with the actual items - avoids casting & stuff but
increases API surface area.
Gotta love tradeoffs
-- qmx
8:51 p.m.
On 01/14/2013 02:46 PM, Douglas Campos wrote:
On 14/01/2013, at 17:17, Summers Pittman <supittma(a)redhat.com>
wrote:
> The biggest issue I see with a PagedPipe is it means a developer can't change his
paging preferences without creating a new Pipe.
why would I want to change paging mid-flight?
Contrived situation,
I am in the park reviewing JIRA bugs. I have chosen to only retrieve 5
at a time because I am on Sprint who has lousy data service. I walk
into my coffee shop which has terrific WiFi and I now want to retreive
50 at a time because they will load before the heat death of the universe.
-- qmx
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
8:53 p.m.
My problem with that is I would expect read() and readWithFilter()
(though I still maintain JS only needs read()), to both return a
Promise since the call to the server is async. I guess I could return
some object which also includes that Promise along with other stuff
but just doesn't feel right.
Ahhh. In Android/iOS read and readWithFilter also
take a callback
method instead of returning a Promise object.
9:04 p.m.
On 14/01/2013, at 17:51, Summers Pittman <supittma(a)redhat.com> wrote:
> why would I want to change paging mid-flight?
Contrived situation,
Contrived example is contrived :P
I am in the park reviewing JIRA bugs. I have chosen to only retrieve 5
at a time because I am on Sprint who has lousy data service. I walk
into my coffee shop which has terrific WiFi and I now want to retreive
50 at a time because they will load before the heat death of the universe.
Hmm, so you only create the pipes at app initialization? Looks like I was missing the
android lifecycle.
-- qmx
9:11 p.m.
On 01/14/2013 03:04 PM, Douglas Campos wrote:
On 14/01/2013, at 17:51, Summers Pittman <supittma(a)redhat.com>
wrote:
>> why would I want to change paging mid-flight?
> Contrived situation,
Contrived example is contrived :P
> I am in the park reviewing JIRA bugs. I have chosen to only retrieve 5
> at a time because I am on Sprint who has lousy data service. I walk
> into my coffee shop which has terrific WiFi and I now want to retreive
> 50 at a time because they will load before the heat death of the universe.
Hmm, so you only create the pipes at app initialization? Looks like I was missing the
android lifecycle.
You can create one any time you like, but either a) each
configuration
would overwrite the old pipe in Pipeline or b) you would have obnoxious
naming conventions.
As a less contrived example, you may have a background process updating
cached data and a foreground process querying data. For instance your
background thread was downloading all of the cars but you only want to
see five red cards. It makes sense for Pipeline.get("car") to be used
by both threads.
-- qmx
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
10:26 p.m.
On 14/01/2013, at 18:11, Summers Pittman <supittma(a)redhat.com> wrote:
> Hmm, so you only create the pipes at app initialization? Looks
like I was missing the android lifecycle.
You can create one any time you like, but either a) each configuration
would overwrite the old pipe in Pipeline or b) you would have obnoxious
naming conventions.
I'm not following the naming conventions part, mind to elaborate?
As a less contrived example, you may have a background process
updating
cached data and a foreground process querying data. For instance your
background thread was downloading all of the cars but you only want to
see five red cards. It makes sense for Pipeline.get("car") to be used
by both threads.
And this is the place where we disagree - I would go straight to make sure that background
stuff have its own pipe instances ;)
-- qmx
1:43 a.m.
On 01/14/2013 04:26 PM, Douglas Campos wrote:
On 14/01/2013, at 18:11, Summers Pittman <supittma(a)redhat.com>
wrote:
>> Hmm, so you only create the pipes at app initialization? Looks like I was missing
the android lifecycle.
> You can create one any time you like, but either a) each configuration
> would overwrite the old pipe in Pipeline or b) you would have obnoxious
> naming conventions.
I'm not following the naming conventions part, mind to elaborate?
I suppose it
just means you have to supply a name attribute to your
PipeConfig. What this means is that the name of the pipe stops being
the type of the pipe(which is our default) and starts being the role of
the pipe (which is a rather new concept).
> As a less contrived example, you may have a background process updating
> cached data and a foreground process querying data. For instance your
> background thread was downloading all of the cars but you only want to
> see five red cards. It makes sense for Pipeline.get("car") to be used
> by both threads.
And this is the place where we disagree - I would go straight to make sure that
background stuff have its own pipe instances ;)
I've been trying to keep the
pipe's methods threadsafe by minimizing
mutable and shared state. (PageContext is an exception, but WeakHashMap
explicitly uses the instance of the object for lookups and not the hash
code). While I do this there is (as far as my biased POV can see) no
good reason to have a single endpoint serviced by multiple RestAdapter
instances. I would like to keep doing things this way, but if it really
breaks the feel of a different language I can be flexible.
-- qmx
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
1:54 a.m.
On Jan 14, 2013, at 6:43 PM, Summers Pittman <supittma(a)redhat.com> wrote:
On 01/14/2013 04:26 PM, Douglas Campos wrote:
> On 14/01/2013, at 18:11, Summers Pittman <supittma(a)redhat.com> wrote:
>
>>> Hmm, so you only create the pipes at app initialization? Looks like I was
missing the android lifecycle.
>> You can create one any time you like, but either a) each configuration
>> would overwrite the old pipe in Pipeline or b) you would have obnoxious
>> naming conventions.
> I'm not following the naming conventions part, mind to elaborate?
I suppose it just means you have to supply a name attribute to your
PipeConfig. What this means is that the name of the pipe stops being
the type of the pipe(which is our default) and starts being the role of
the pipe (which is a rather new concept).
JS, and I believe iOS, both supply a name attribute in our configs so this would bring
Android in line with the other libs in that area.
>
>> As a less contrived example, you may have a background process updating
>> cached data and a foreground process querying data. For instance your
>> background thread was downloading all of the cars but you only want to
>> see five red cards. It makes sense for Pipeline.get("car") to be used
>> by both threads.
> And this is the place where we disagree - I would go straight to make sure that
background stuff have its own pipe instances ;)
I've been trying to keep the pipe's methods threadsafe by minimizing
mutable and shared state. (PageContext is an exception, but WeakHashMap
explicitly uses the instance of the object for lookups and not the hash
code). While I do this there is (as far as my biased POV can see) no
good reason to have a single endpoint serviced by multiple RestAdapter
instances. I would like to keep doing things this way, but if it really
breaks the feel of a different language I can be flexible.
I think this harkens back to the beginning of the Android library and the confusion over
Pipeline vs pipe. Again, I'm using JS as an example but I believe iOS is the same way
but in JS, a Pipeline is little more than a factory for pipes. A single Pipeline can have
multiple pipes and in fact, in the JS lib, it is encouraged. That way all of your pipes
(read interactions with a single endpoint) are contained in the same Pipeline. This does
not mean that a single endpoint would be serviced by multiple adapter instances, what this
means is that a single Pipeline would contain every pipe to each endpoint of a particular
service. This way, you could have one Pipeline containing all of the pipes to your
app's backend, and in the same app, another Pipeline with a set of pipes meant to
interact with Twitter and another for pulling in an RSS feed of blog posts. It gives some
logical organization to the app. Does that make sense? Does Android work that way at all?
Am I just way off here and rambling? :)
>
> -- qmx
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
2:02 a.m.
On 01/14/2013 07:54 PM, Kris Borchers wrote:
On Jan 14, 2013, at 6:43 PM, Summers Pittman
<supittma(a)redhat.com> wrote:
> On 01/14/2013 04:26 PM, Douglas Campos wrote:
>> On 14/01/2013, at 18:11, Summers Pittman <supittma(a)redhat.com> wrote:
>>
>>>> Hmm, so you only create the pipes at app initialization? Looks like I was
missing the android lifecycle.
>>> You can create one any time you like, but either a) each configuration
>>> would overwrite the old pipe in Pipeline or b) you would have obnoxious
>>> naming conventions.
>> I'm not following the naming conventions part, mind to elaborate?
> I suppose it just means you have to supply a name attribute to your
> PipeConfig. What this means is that the name of the pipe stops being
> the type of the pipe(which is our default) and starts being the role of
> the pipe (which is a rather new concept).
JS, and I believe iOS, both supply a name attribute in our configs so this would bring
Android in line with the other libs in that area.
You've always been able to
supply a name, just the name defaulted to the
class type if it wasn't supplied.
>>> As a less contrived example, you may have a background process updating
>>> cached data and a foreground process querying data. For instance your
>>> background thread was downloading all of the cars but you only want to
>>> see five red cards. It makes sense for Pipeline.get("car") to be
used
>>> by both threads.
>> And this is the place where we disagree - I would go straight to make sure that
background stuff have its own pipe instances ;)
> I've been trying to keep the pipe's methods threadsafe by minimizing
> mutable and shared state. (PageContext is an exception, but WeakHashMap
> explicitly uses the instance of the object for lookups and not the hash
> code). While I do this there is (as far as my biased POV can see) no
> good reason to have a single endpoint serviced by multiple RestAdapter
> instances. I would like to keep doing things this way, but if it really
> breaks the feel of a different language I can be flexible.
I think this harkens back to the beginning of the Android library and the confusion over
Pipeline vs pipe. Again, I'm using JS as an example but I believe iOS is the same way
but in JS, a Pipeline is little more than a factory for pipes.
Correct, it is this
way in Android as well
A single Pipeline can have multiple pipes and in fact, in the JS lib,
it is encouraged. That way all of your pipes (read interactions with a single endpoint)
are contained in the same Pipeline. This does not mean that a single endpoint would be
serviced by multiple adapter instances, what this means is that a single Pipeline would
contain every pipe to each endpoint of a particular service.
Which is what I am
arguing for. The system should encourage a Pipeline
to service a base URL and each Pipe to be a endpoint on that URL. By
keeping the paging config off of the Pipe itself you end up much closer
to this ideal (as I understand the ideal).
This way, you could have one Pipeline containing all of the pipes to
your app's backend, and in the same app, another Pipeline with a set of pipes meant to
interact with Twitter and another for pulling in an RSS feed of blog posts. It gives some
logical organization to the app. Does that make sense? Does Android work that way at all?
Am I just way off her!
e and rambling? :)
Nope makes sense and it works this way. My concern is when
you have a
pipe("cars"), pipe("redCars"), pipe("atMost10RedCars"), and
pipe("buildFromALinkToThe3rdPageOfRedCars").
>> -- qmx
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
2:03 a.m.
On 01/14/2013 02:46 PM, Douglas Campos wrote:
On 14/01/2013, at 17:17, Summers Pittman <supittma(a)redhat.com>
wrote:
> The biggest issue I see with a PagedPipe is it means a developer can't change his
paging preferences without creating a new Pipe.
why would I want to change paging mid-flight?
I thought of another while while
responding to Kris.
When your app opens a link to a specific set of results.
-- qmx
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
10:23 a.m.
On Mon, Jan 14, 2013 at 8:28 PM, Summers Pittman <supittma(a)redhat.com>wrote:
On 01/14/2013 02:21 PM, Matthias Wessendorf wrote:
On Mon, Jan 14, 2013 at 8:17 PM, Summers Pittman <supittma(a)redhat.com>wrote:
> On 01/14/2013 01:00 PM, Kris Borchers wrote:
>
> OK folks, below is the contents of this gist
> https://gist.github.com/4531575. I may have missed a number of things,
> gotten too specific in places or not specific enough in others. This should
> hopefully get a good discussion going on how we want to handle paging
> across all of the client libraries. Let's keep all comments on the list and
> not the gist as much as possible to avoid breaking up the conversation.
>
> Below is a pipe configuration showing the different paging options.
> Defaults are just suggestions and are up for discussion as much as the rest
> of it
>
> var pagedPipe = AeroGear.Pipeline({
> name: "pager",
> settings: {
> paged: {String}, // Default is "headers", can also be
> "content", or undefined for no paging
> pageConfig: { // Only required if paged is not undefined
> // which page, header default is "AG-Paging-Offset",
> content default is "paging.offset"
> offset: {String},
> offsetVal: {Number}, // Default 0 for first page
>
> // items per page, header default is "AG-Paging-Limit",
> content default is "paging.limit"
> limit: {String},
> limitVal: {Number}, // Default 5 items per page
>
> // total number of items, header default is
> "AG-Paging-Total", content default is "paging.total"
> total: {String},
>
> // link to next page, default in both cases is undefined
> next: {String},
>
> // link to previous page, default in both cases is
> undefined
> prev: {String}
> }
> }
> }).pipes.pager;
>
> Getter/Setter methods should be provided for getting and updating the
> offsetVal and limitVal defaults
>
> var defaultOffset = pagedPipe.getOffsetVal();
> pagedPipe.setOffsetVal( defaultOffset + 1 ); // by default the second
> page would be returned
>
> var defaultLimit = pagedPipe.getLimitVal();
> pagedPipe.setLimitVal( defaultLimit + 5 ); // by default, 10 items
> would be returned per page
>
> ## read()
> By default, a read() against a paged pipe will return the first page
> based on the default offsetVal and limitVal. We could possible add an
> option that doesn't effect unpaged pipes but on a paged pipe, it can be
> used to turn off paging for that read() and get all data
>
> // Get first page
> pagedPipe.read({success callback handles data});
>
> // Get all data from paged pipe
> pagedPipe.read({
> page: false,
> success: handle the data
> });
>
> To avoid code duplication, **next**, **prev**, **first** and **last**
> pages can be retrieved by passing an option to the read method of a paged
> pipe since other than some paging housekeeping, the code would be the same.
> We can also use that same option as above that was used to get all data
> from a paged pipe. One question, when requesting prev from first page or
> next from last page, should it throw an error that needs to be handled or
> just return and empty data set? I see advantages and disadvantages of both.
>
> // Get next page
> pagedPipe.read({
> page: "next",
> success: handle the data
> });
>
> // Get previous page
> pagedPipe.read({
> page: "prev",
> success: handle the data
> });
>
> // Get first page
> pagedPipe.read({
> page: "first",
> success: handle the data
> });
>
> // Get last page
> pagedPipe.read({
> page: "last",
> success: handle the data
> });
>
>
> _______________________________________________
> aerogear-dev mailing
listaerogear-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> At first glance I don't like having the distinction between a "Pipe"
> and a "PagedPipe". In Java land PagedPipe will be an interface which
> extends Pipe (this is no big deal) and PagedRestAdatper would extend
> RestAdapted and implement PagedPipe. This isn't too bad but it makes
> reusing paging logic a bit harder. (And also this is at first glance).
>
haven't thought about typing, but a subclass (in iOS / Java land) sounds
reasonable.
I say it makes reusing the paging logic harder because the thing which can
page is a subclass of RestAdapter. If we could somehow composite Paging
into rest adapter it would work out better. Composition is a bit more work
to get "right" than inheritance. (I say "right" because if it is
done
wrong the classes end up being too tightly coupled and you might as well
have used inheritance to begin with).
+1 on composition
Also, "previous" name "PagedPipe" would be wrong, as the composition
could
be handy for other query requests, instead of just plain paging
Will post something 2morrow
>
> The biggest issue I see with a PagedPipe is it means a developer can't
> change his paging preferences without creating a new Pipe.
>
oh, I could not update the settings? That's a -1
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing
listaerogear-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
10:24 a.m.
On Mon, Jan 14, 2013 at 8:29 PM, Summers Pittman <supittma(a)redhat.com>wrote:
On 01/14/2013 02:27 PM, Kris Borchers wrote:
On Jan 14, 2013, at 1:17 PM, Summers Pittman <supittma(a)redhat.com> wrote:
On 01/14/2013 01:00 PM, Kris Borchers wrote:
OK folks, below is the contents of this gist
https://gist.github.com/4531575. I may have missed a number of things,
gotten too specific in places or not specific enough in others. This should
hopefully get a good discussion going on how we want to handle paging
across all of the client libraries. Let's keep all comments on the list and
not the gist as much as possible to avoid breaking up the conversation.
Below is a pipe configuration showing the different paging options.
Defaults are just suggestions and are up for discussion as much as the rest
of it
var pagedPipe = AeroGear.Pipeline({
name: "pager",
settings: {
paged: {String}, // Default is "headers", can also be
"content", or undefined for no paging
pageConfig: { // Only required if paged is not undefined
// which page, header default is "AG-Paging-Offset",
content default is "paging.offset"
offset: {String},
offsetVal: {Number}, // Default 0 for first page
// items per page, header default is "AG-Paging-Limit",
content default is "paging.limit"
limit: {String},
limitVal: {Number}, // Default 5 items per page
// total number of items, header default is
"AG-Paging-Total", content default is "paging.total"
total: {String},
// link to next page, default in both cases is undefined
next: {String},
// link to previous page, default in both cases is
undefined
prev: {String}
}
}
}).pipes.pager;
Getter/Setter methods should be provided for getting and updating the
offsetVal and limitVal defaults
var defaultOffset = pagedPipe.getOffsetVal();
pagedPipe.setOffsetVal( defaultOffset + 1 ); // by default the second
page would be returned
var defaultLimit = pagedPipe.getLimitVal();
pagedPipe.setLimitVal( defaultLimit + 5 ); // by default, 10 items
would be returned per page
## read()
By default, a read() against a paged pipe will return the first page based
on the default offsetVal and limitVal. We could possible add an option that
doesn't effect unpaged pipes but on a paged pipe, it can be used to turn
off paging for that read() and get all data
// Get first page
pagedPipe.read({success callback handles data});
// Get all data from paged pipe
pagedPipe.read({
page: false,
success: handle the data
});
To avoid code duplication, **next**, **prev**, **first** and **last**
pages can be retrieved by passing an option to the read method of a paged
pipe since other than some paging housekeeping, the code would be the same.
We can also use that same option as above that was used to get all data
from a paged pipe. One question, when requesting prev from first page or
next from last page, should it throw an error that needs to be handled or
just return and empty data set? I see advantages and disadvantages of both.
// Get next page
pagedPipe.read({
page: "next",
success: handle the data
});
// Get previous page
pagedPipe.read({
page: "prev",
success: handle the data
});
// Get first page
pagedPipe.read({
page: "first",
success: handle the data
});
// Get last page
pagedPipe.read({
page: "last",
success: handle the data
});
_______________________________________________
aerogear-dev mailing
listaerogear-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev
At first glance I don't like having the distinction between a "Pipe" and
a "PagedPipe". In Java land PagedPipe will be an interface which extends
Pipe (this is no big deal) and PagedRestAdatper would extend RestAdapted
and implement PagedPipe. This isn't too bad but it makes reusing paging
logic a bit harder. (And also this is at first glance).
The biggest issue I see with a PagedPipe is it means a developer can't
change his paging preferences without creating a new Pipe.
If I add a setter for "paged" that would effectively fix that on the JS
side since offset and limit are already updatable. Does that work for you?
No because I think fundamentally paging is part of the query and not part
of the pipe.
+1
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing
listaerogear-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
11:37 a.m.
Hi Summers,
https://gist.github.com/4532661
That is a way to do paging which keeps Pipes immutable, uses
readWithFilter, and doesn't impose any (for convenient definitions of any)
bookkeeping on the developer.
from your Andorid gist <https://gist.github.com/4532661>;:
A) *Once the response has been received, the Pipe implementation will
return a List of objects. If this List instance is passed to
Pipe.getPageContext the appropriate PageContext will be returned*
Note: There is no 'return' - the readWithFilter is void, instead a Callback
is invoked (onSuccess(list)), see
Pipe.java<https://github.com/aerogear/aerogear-android/blob/master/src...
B) *The developer will receive from readWithFilter() a List of object. If
she passes this list into Pipe.getPageContext(List result) she will receive
the PageContext associated with this result.*
Do you mean like:
...myPipe.readWithFilter(filter, new Callback<List<Data>>() {
@Override
public void onSuccess(List<Data> data) {
// get the PageContext:
PageContext ctx = myPipe.getPageContext(data);
...
}
@Override
public void onFailure(Exception e) {
}});
Not sure about that.....
But for iOS I am thinking about passing in the PageContext into the
closure/block of the readWithFilter, like:
-(void) readWithFilter:(void (^)(id<AGFilterConfig> config)) config
success:(void (^)(id listOfObjects, id pageContext))success
failure:(void (^)(NSError *error))failure;
A usage would look like:
[pipe readWithFilter:^(id<AGFilterConfig> config) {
// set the filter args and override the given defaults
} success:^(id listOfObjects, id pageContext) {
// work with the listOfObjects reponse.
// for paging/query info, access the given pagecontext,
// of the CURRENT request
...
} failure:^(NSError *error) {
// handle errorz
}];
Any thoughts ?
Not sure I like (or understand) the Pipe.getPageContext(List result) call.
Current mindset is that thePageContext just (and *only*) belongs to the
previous (executed) request... Not sure I want to support something like
// first call:List<SomeType> first;myPipe.readWithFilter(.....) // set
first inside of callback...// second call:List<SomeType>
second;myPipe.readWithFilter(.....) // set second inside of
callback...// third call:List<SomeType>
third;myPipe.readWithFilter(.....) // set third inside of callback...
/// A BIT LATER ....:myPipe.getPageContext(first);
I am not sure if that (myPipe.getPageContext(first);) is really desired (or
would even easily work, as it would need to store the "metadata").....
Perhaps I am just wrong.
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
12:17 p.m.
Hi,
Some aditional remarks on Summers gist :
Instead of :
Pipe.readWithFilter(ReadFilter)
Couldn't we just overload the read() method ? i.e :
read(ReadFilter filter)
About the where property in ReadFilter class :
Do we really want to mix paging and querying ?
About Pipe.getPageContext(List result):
Same remarks as Matthias, not sure to understand how it works (even if I
think I've understand ...)
General remarks about Paging:
Even if it's not in scope for 1.0, I think we have to keep in mind that we
will also be able to do pagination "offline" / "only client side"
(maybe we
would do some paging on a Store element ?) , so we have to consider this
when designing our API.
Seb
On Tue, Jan 15, 2013 at 11:37 AM, Matthias Wessendorf <matzew(a)apache.org>wrote:
12:36 p.m.
On Tue, Jan 15, 2013 at 12:17 PM, Sebastien Blanc <scm.blanc(a)gmail.com>wrote:
Hi,
Some aditional remarks on Summers gist :
Instead of :
Pipe.readWithFilter(ReadFilter)
Couldn't we just overload the read() method ? i.e :
read(ReadFilter filter)
a huge +1 !
I *think* that this "limitation" was introduced when porting the iOS API
1-by1
(In iOS I can't do a similar overload (since we already have a
[read:success:failure], which queries for a specific ID))
About the where property in ReadFilter class :
Do we really want to mix paging and querying ?
About Pipe.getPageContext(List result):
Same remarks as Matthias, not sure to understand how it works (even if I
think I've understand ...)
General remarks about Paging:
Even if it's not in scope for 1.0, I think we have to keep in mind that we
will also be able to do pagination "offline" / "only client side"
(maybe we
would do some paging on a Store element ?) , so we have to consider this
when designing our API.
Seb
On Tue, Jan 15, 2013 at 11:37 AM, Matthias Wessendorf <matzew(a)apache.org>wrote:
> https://gist.github.com/4532661
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
1:29 p.m.
On 14/01/2013, at 22:43, Summers Pittman <supittma(a)redhat.com> wrote:
I've been trying to keep the pipe's methods threadsafe by
minimizing
mutable and shared state. (PageContext is an exception, but WeakHashMap
explicitly uses the instance of the object for lookups and not the hash
code).
Keep in mind that we're discussing end-user APIs, and those kind of implementation
detail leaks can lean you towards a "fabricated" solution to meet the
implementation you have in mind ;)
-- qmx
1:38 p.m.
I'm not a fan of those PageContext objects (remembers me of some wild-ass ThreadLocals
leaking all over)
My proposal for the paging aware APIs would be something like this:
public interface PagedResult<T> {
List<T> next();
List<T> prev();
List<T> page(int offset, int limit);
}
and the Async counterpart
public interface AsyncPagedResult<T> {
void next(Callback<List<T>> callback);
void prev(Callback<List<T>> callback);
void page(int offset, int limit, Callback<List<T>> callback);
public static interface Callback<U> {
public void onResult(U result);
}
}
I don't like the idea of having a companion object for holding the pagination state.
Thoughts?
-- qmx
On 15/01/2013, at 08:37, Matthias Wessendorf <matzew(a)apache.org> wrote:
Hi Summers,
https://gist.github.com/4532661
That is a way to do paging which keeps Pipes immutable, uses readWithFilter, and
doesn't impose any (for convenient definitions of any) bookkeeping on the developer.
from your Andorid gist:
A) Once the response has been received, the Pipe implementation will return a List of
objects. If this List instance is passed to Pipe.getPageContext the appropriate
PageContext will be returned
Note: There is no 'return' - the readWithFilter is void, instead a Callback is
invoked (onSuccess(list)), see Pipe.java
B) The developer will receive from readWithFilter() a List of object. If she passes this
list into Pipe.getPageContext(List result) she will receive the PageContext associated
with this result.
Do you mean like:
...
myPipe.readWithFilter(filter, new Callback<List<Data>>() {
@Override
public void onSuccess(List<Data> data) {
// get the PageContext:
PageContext ctx = myPipe.getPageContext(data);
...
}
@Override
public void onFailure(Exception e) {
}
});
Not sure about that.....
But for iOS I am thinking about passing in the PageContext into the closure/block of the
readWithFilter, like:
-(void) readWithFilter:(void (^)(id<AGFilterConfig> config)) config
success:(void (^)(id listOfObjects, id pageContext))success
failure:(void (^)(NSError *error))failure;
A usage would look like:
[pipe readWithFilter:^(id<AGFilterConfig> config) {
// set the filter args and override the given defaults
} success:^(id listOfObjects, id pageContext) {
// work with the listOfObjects reponse.
// for paging/query info, access the given pagecontext,
// of the CURRENT request
...
} failure:^(NSError *error) {
// handle errorz
}];
Any thoughts ?
Not sure I like (or understand) the Pipe.getPageContext(List result) call. Current
mindset is that thePageContext just (and only) belongs to the previous (executed)
request... Not sure I want to support something like
// first call:
List<SomeType> first;
myPipe.readWithFilter(.....) // set first inside of callback
...
// second call:
List<SomeType> second;
myPipe.readWithFilter(.....) // set second inside of callback
...
// third call:
List<SomeType> third;
myPipe.readWithFilter(.....) // set third inside of callback
...
/// A BIT LATER ....:
myPipe.getPageContext(first);
I am not sure if that (myPipe.getPageContext(first);) is really desired (or would even
easily work, as it would need to store the "metadata").....
Perhaps I am just wrong.
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf _______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
1:54 p.m.
the pageResult.next() (and the asyncResult.next(someCallback)) would
invoke the "read(readFilter)" on the previously used pipe object,
right ?
-M
On Tue, Jan 15, 2013 at 1:38 PM, Douglas Campos <qmx(a)qmx.me> wrote:
I'm not a fan of those PageContext objects (remembers me of some
wild-ass ThreadLocals leaking all over)
My proposal for the paging aware APIs would be something like this:
public interface PagedResult<T> {
List<T> next();
List<T> prev();
List<T> page(int offset, int limit);
}
and the Async counterpart
public interface AsyncPagedResult<T> {
void next(Callback<List<T>> callback);
void prev(Callback<List<T>> callback);
void page(int offset, int limit, Callback<List<T>> callback);
public static interface Callback<U> {
public void onResult(U result);
}
}
I don't like the idea of having a companion object for holding the pagination state.
Thoughts?
-- qmx
On 15/01/2013, at 08:37, Matthias Wessendorf <matzew(a)apache.org> wrote:
> Hi Summers,
>
>
> https://gist.github.com/4532661
>
> That is a way to do paging which keeps Pipes immutable, uses readWithFilter, and
doesn't impose any (for convenient definitions of any) bookkeeping on the developer.
>
>
> from your Andorid gist:
>
> A) Once the response has been received, the Pipe implementation will return a List of
objects. If this List instance is passed to Pipe.getPageContext the appropriate
PageContext will be returned
>
> Note: There is no 'return' - the readWithFilter is void, instead a Callback
is invoked (onSuccess(list)), see Pipe.java
>
> B) The developer will receive from readWithFilter() a List of object. If she passes
this list into Pipe.getPageContext(List result) she will receive the PageContext
associated with this result.
>
> Do you mean like:
>
> ...
> myPipe.readWithFilter(filter, new Callback<List<Data>>() {
>
>
> @Override
>
>
> public void onSuccess(List<Data> data) {
>
>
>
> // get the PageContext:
>
>
> PageContext ctx = myPipe.getPageContext(data);
>
>
> ...
>
>
> }
>
>
>
> @Override
>
>
> public void onFailure(Exception e) {
>
>
> }
> });
> Not sure about that.....
>
> But for iOS I am thinking about passing in the PageContext into the closure/block of
the readWithFilter, like:
>
> -(void) readWithFilter:(void (^)(id<AGFilterConfig> config)) config
>
>
> success:(void (^)(id listOfObjects, id pageContext))success
>
>
> failure:(void (^)(NSError *error))failure;
> A usage would look like:
>
> [pipe readWithFilter:^(id<AGFilterConfig> config) {
>
>
> // set the filter args and override the given defaults
>
>
> } success:^(id listOfObjects, id pageContext) {
>
>
> // work with the listOfObjects reponse.
>
>
> // for paging/query info, access the given pagecontext,
>
>
> // of the CURRENT request
>
>
> ...
>
>
> } failure:^(NSError *error) {
>
>
> // handle errorz
>
>
> }];
> Any thoughts ?
>
> Not sure I like (or understand) the Pipe.getPageContext(List result) call. Current
mindset is that thePageContext just (and only) belongs to the previous (executed)
request... Not sure I want to support something like
>
> // first call:
> List<SomeType> first;
> myPipe.readWithFilter(.....) // set first inside of callback
> ...
> // second call:
> List<SomeType> second;
> myPipe.readWithFilter(.....) // set second inside of callback
> ...
> // third call:
> List<SomeType> third;
> myPipe.readWithFilter(.....) // set third inside of callback
> ...
>
>
>
>
> /// A BIT LATER ....:
> myPipe.getPageContext(first);
>
>
> I am not sure if that (myPipe.getPageContext(first);) is really desired (or would
even easily work, as it would need to store the "metadata").....
>
>
> Perhaps I am just wrong.
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
_______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
2:01 p.m.
In the same spirit (inspired from
http://stackoverflow.com/questions/5412059/how-to-implement-general-pagin...
) :
public interface PagedResult<T> {
PagedResult<T> next();
PagedResult<T> prev();
PagedResult<T> withOffset(int offset);
PagedResult<T> withLimit(int limit);
List<T> result();
}
On Tue, Jan 15, 2013 at 1:38 PM, Douglas Campos <qmx(a)qmx.me> wrote:
I'm not a fan of those PageContext objects (remembers me of some
wild-ass
ThreadLocals leaking all over)
My proposal for the paging aware APIs would be something like this:
public interface PagedResult<T> {
List<T> next();
List<T> prev();
List<T> page(int offset, int limit);
}
and the Async counterpart
public interface AsyncPagedResult<T> {
void next(Callback<List<T>> callback);
void prev(Callback<List<T>> callback);
void page(int offset, int limit, Callback<List<T>> callback);
public static interface Callback<U> {
public void onResult(U result);
}
}
I don't like the idea of having a companion object for holding the
pagination state.
Thoughts?
-- qmx
On 15/01/2013, at 08:37, Matthias Wessendorf <matzew(a)apache.org> wrote:
> Hi Summers,
>
>
> https://gist.github.com/4532661
>
> That is a way to do paging which keeps Pipes immutable, uses
readWithFilter, and doesn't impose any (for convenient definitions of any)
bookkeeping on the developer.
>
>
> from your Andorid gist:
>
> A) Once the response has been received, the Pipe implementation will
return a List of objects. If this List instance is passed to
Pipe.getPageContext the appropriate PageContext will be returned
>
> Note: There is no 'return' - the readWithFilter is void, instead a
Callback is invoked (onSuccess(list)), see Pipe.java
>
> B) The developer will receive from readWithFilter() a List of object. If
she passes this list into Pipe.getPageContext(List result) she will receive
the PageContext associated with this result.
>
> Do you mean like:
>
> ...
> myPipe.readWithFilter(filter, new Callback<List<Data>>() {
>
>
> @Override
>
>
> public void onSuccess(List<Data> data) {
>
>
>
> // get the PageContext:
>
>
> PageContext ctx = myPipe.getPageContext(data);
>
>
> ...
>
>
> }
>
>
>
> @Override
>
>
> public void onFailure(Exception e) {
>
>
> }
> });
> Not sure about that.....
>
> But for iOS I am thinking about passing in the PageContext into the
closure/block of the readWithFilter, like:
>
> -(void) readWithFilter:(void (^)(id<AGFilterConfig> config)) config
>
>
> success:(void (^)(id listOfObjects, id pageContext))success
>
>
> failure:(void (^)(NSError *error))failure;
> A usage would look like:
>
> [pipe readWithFilter:^(id<AGFilterConfig> config) {
>
>
> // set the filter args and override the given defaults
>
>
> } success:^(id listOfObjects, id pageContext) {
>
>
> // work with the listOfObjects reponse.
>
>
> // for paging/query info, access the given pagecontext,
>
>
> // of the CURRENT request
>
>
> ...
>
>
> } failure:^(NSError *error) {
>
>
> // handle errorz
>
>
> }];
> Any thoughts ?
>
> Not sure I like (or understand) the Pipe.getPageContext(List result)
call. Current mindset is that thePageContext just (and only) belongs to the
previous (executed) request... Not sure I want to support something like
>
> // first call:
> List<SomeType> first;
> myPipe.readWithFilter(.....) // set first inside of callback
> ...
> // second call:
> List<SomeType> second;
> myPipe.readWithFilter(.....) // set second inside of callback
> ...
> // third call:
> List<SomeType> third;
> myPipe.readWithFilter(.....) // set third inside of callback
> ...
>
>
>
>
> /// A BIT LATER ....:
> myPipe.getPageContext(first);
>
>
> I am not sure if that (myPipe.getPageContext(first);) is really desired
(or would even easily work, as it would need to store the "metadata").....
>
>
> Perhaps I am just wrong.
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter:
http://twitter.com/mwessendorf___________________________________________...
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
2:12 p.m.
would the (Async)PagedResult be delivered on the "success callback" of
the "readWithFilter") ?
-M
On Tue, Jan 15, 2013 at 1:54 PM, Matthias Wessendorf <matzew(a)apache.org> wrote:
the pageResult.next() (and the asyncResult.next(someCallback)) would
invoke the "read(readFilter)" on the previously used pipe object,
right ?
-M
On Tue, Jan 15, 2013 at 1:38 PM, Douglas Campos <qmx(a)qmx.me> wrote:
> I'm not a fan of those PageContext objects (remembers me of some wild-ass
ThreadLocals leaking all over)
>
> My proposal for the paging aware APIs would be something like this:
>
> public interface PagedResult<T> {
>
> List<T> next();
>
> List<T> prev();
>
> List<T> page(int offset, int limit);
>
> }
>
> and the Async counterpart
>
> public interface AsyncPagedResult<T> {
>
> void next(Callback<List<T>> callback);
>
> void prev(Callback<List<T>> callback);
>
> void page(int offset, int limit, Callback<List<T>> callback);
>
> public static interface Callback<U> {
> public void onResult(U result);
> }
> }
>
> I don't like the idea of having a companion object for holding the pagination
state.
>
> Thoughts?
>
> -- qmx
>
> On 15/01/2013, at 08:37, Matthias Wessendorf <matzew(a)apache.org> wrote:
>
>> Hi Summers,
>>
>>
>> https://gist.github.com/4532661
>>
>> That is a way to do paging which keeps Pipes immutable, uses readWithFilter, and
doesn't impose any (for convenient definitions of any) bookkeeping on the developer.
>>
>>
>> from your Andorid gist:
>>
>> A) Once the response has been received, the Pipe implementation will return a
List of objects. If this List instance is passed to Pipe.getPageContext the appropriate
PageContext will be returned
>>
>> Note: There is no 'return' - the readWithFilter is void, instead a
Callback is invoked (onSuccess(list)), see Pipe.java
>>
>> B) The developer will receive from readWithFilter() a List of object. If she
passes this list into Pipe.getPageContext(List result) she will receive the PageContext
associated with this result.
>>
>> Do you mean like:
>>
>> ...
>> myPipe.readWithFilter(filter, new Callback<List<Data>>() {
>>
>>
>> @Override
>>
>>
>> public void onSuccess(List<Data> data) {
>>
>>
>>
>> // get the PageContext:
>>
>>
>> PageContext ctx = myPipe.getPageContext(data);
>>
>>
>> ...
>>
>>
>> }
>>
>>
>>
>> @Override
>>
>>
>> public void onFailure(Exception e) {
>>
>>
>> }
>> });
>> Not sure about that.....
>>
>> But for iOS I am thinking about passing in the PageContext into the closure/block
of the readWithFilter, like:
>>
>> -(void) readWithFilter:(void (^)(id<AGFilterConfig> config)) config
>>
>>
>> success:(void (^)(id listOfObjects, id pageContext))success
>>
>>
>> failure:(void (^)(NSError *error))failure;
>> A usage would look like:
>>
>> [pipe readWithFilter:^(id<AGFilterConfig> config) {
>>
>>
>> // set the filter args and override the given defaults
>>
>>
>> } success:^(id listOfObjects, id pageContext) {
>>
>>
>> // work with the listOfObjects reponse.
>>
>>
>> // for paging/query info, access the given pagecontext,
>>
>>
>> // of the CURRENT request
>>
>>
>> ...
>>
>>
>> } failure:^(NSError *error) {
>>
>>
>> // handle errorz
>>
>>
>> }];
>> Any thoughts ?
>>
>> Not sure I like (or understand) the Pipe.getPageContext(List result) call.
Current mindset is that thePageContext just (and only) belongs to the previous (executed)
request... Not sure I want to support something like
>>
>> // first call:
>> List<SomeType> first;
>> myPipe.readWithFilter(.....) // set first inside of callback
>> ...
>> // second call:
>> List<SomeType> second;
>> myPipe.readWithFilter(.....) // set second inside of callback
>> ...
>> // third call:
>> List<SomeType> third;
>> myPipe.readWithFilter(.....) // set third inside of callback
>> ...
>>
>>
>>
>>
>> /// A BIT LATER ....:
>> myPipe.getPageContext(first);
>>
>>
>> I am not sure if that (myPipe.getPageContext(first);) is really desired (or would
even easily work, as it would need to store the "metadata").....
>>
>>
>> Perhaps I am just wrong.
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
_______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
2:25 p.m.
I was wondering, if the result should be received on every rquest,
thx
On Tue, Jan 15, 2013 at 2:01 PM, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
In the same spirit (inspired from
http://stackoverflow.com/questions/5412059/how-to-implement-general-pagin...)
:
public interface PagedResult<T> {
PagedResult<T> next();
PagedResult<T> prev();
PagedResult<T> withOffset(int offset);
PagedResult<T> withLimit(int limit);
List<T> result();
}
On Tue, Jan 15, 2013 at 1:38 PM, Douglas Campos <qmx(a)qmx.me> wrote:
>
> I'm not a fan of those PageContext objects (remembers me of some wild-ass
> ThreadLocals leaking all over)
>
> My proposal for the paging aware APIs would be something like this:
>
> public interface PagedResult<T> {
>
> List<T> next();
>
> List<T> prev();
>
> List<T> page(int offset, int limit);
>
> }
>
> and the Async counterpart
>
> public interface AsyncPagedResult<T> {
>
> void next(Callback<List<T>> callback);
>
> void prev(Callback<List<T>> callback);
>
> void page(int offset, int limit, Callback<List<T>> callback);
>
> public static interface Callback<U> {
> public void onResult(U result);
> }
> }
>
> I don't like the idea of having a companion object for holding the
> pagination state.
>
> Thoughts?
>
> -- qmx
>
> On 15/01/2013, at 08:37, Matthias Wessendorf <matzew(a)apache.org> wrote:
>
> > Hi Summers,
> >
> >
> > https://gist.github.com/4532661
> >
> > That is a way to do paging which keeps Pipes immutable, uses
> > readWithFilter, and doesn't impose any (for convenient definitions of any)
> > bookkeeping on the developer.
> >
> >
> > from your Andorid gist:
> >
> > A) Once the response has been received, the Pipe implementation will
> > return a List of objects. If this List instance is passed to
> > Pipe.getPageContext the appropriate PageContext will be returned
> >
> > Note: There is no 'return' - the readWithFilter is void, instead a
> > Callback is invoked (onSuccess(list)), see Pipe.java
> >
> > B) The developer will receive from readWithFilter() a List of object. If
> > she passes this list into Pipe.getPageContext(List result) she will receive
> > the PageContext associated with this result.
> >
> > Do you mean like:
> >
> > ...
> > myPipe.readWithFilter(filter, new Callback<List<Data>>() {
> >
> >
> > @Override
> >
> >
> > public void onSuccess(List<Data> data) {
> >
> >
> >
> > // get the PageContext:
> >
> >
> > PageContext ctx = myPipe.getPageContext(data);
> >
> >
> > ...
> >
> >
> > }
> >
> >
> >
> > @Override
> >
> >
> > public void onFailure(Exception e) {
> >
> >
> > }
> > });
> > Not sure about that.....
> >
> > But for iOS I am thinking about passing in the PageContext into the
> > closure/block of the readWithFilter, like:
> >
> > -(void) readWithFilter:(void (^)(id<AGFilterConfig> config)) config
> >
> >
> > success:(void (^)(id listOfObjects, id pageContext))success
> >
> >
> > failure:(void (^)(NSError *error))failure;
> > A usage would look like:
> >
> > [pipe readWithFilter:^(id<AGFilterConfig> config) {
> >
> >
> > // set the filter args and override the given defaults
> >
> >
> > } success:^(id listOfObjects, id pageContext) {
> >
> >
> > // work with the listOfObjects reponse.
> >
> >
> > // for paging/query info, access the given pagecontext,
> >
> >
> > // of the CURRENT request
> >
> >
> > ...
> >
> >
> > } failure:^(NSError *error) {
> >
> >
> > // handle errorz
> >
> >
> > }];
> > Any thoughts ?
> >
> > Not sure I like (or understand) the Pipe.getPageContext(List result)
> > call. Current mindset is that thePageContext just (and only) belongs to the
> > previous (executed) request... Not sure I want to support something like
> >
> > // first call:
> > List<SomeType> first;
> > myPipe.readWithFilter(.....) // set first inside of callback
> > ...
> > // second call:
> > List<SomeType> second;
> > myPipe.readWithFilter(.....) // set second inside of callback
> > ...
> > // third call:
> > List<SomeType> third;
> > myPipe.readWithFilter(.....) // set third inside of callback
> > ...
> >
> >
> >
> >
> > /// A BIT LATER ....:
> > myPipe.getPageContext(first);
> >
> >
> > I am not sure if that (myPipe.getPageContext(first);) is really desired
> > (or would even easily work, as it would need to store the
"metadata").....
> >
> >
> > Perhaps I am just wrong.
> >
> >
> > --
> > Matthias Wessendorf
> >
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > twitter: http://twitter.com/mwessendorf
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
2:25 p.m.
On Tue, Jan 15, 2013 at 2:01 PM, Douglas Campos <qmx(a)qmx.me> wrote:
On 15/01/2013, at 10:54, Matthias Wessendorf
<matzew(a)apache.org> wrote:
> the pageResult.next() (and the asyncResult.next(someCallback)) would
> invoke the "read(readFilter)" on the previously used pipe object,
> right ?
implementation detail ;) (but I suppose so)
not really, since the callback API would have it
-- qmx
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
2:32 p.m.
On Tue, Jan 15, 2013 at 2:25 PM, Matthias Wessendorf <matzew(a)apache.org> wrote:
I was wondering, if the result should be received on every rquest,
ideally on the callback..., to not block (at least in iOS land, I
would pass that "result set" on to the "success" block)
-M
thx
On Tue, Jan 15, 2013 at 2:01 PM, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
> In the same spirit (inspired from
> http://stackoverflow.com/questions/5412059/how-to-implement-general-pagin...)
> :
>
>
> public interface PagedResult<T> {
>
> PagedResult<T> next();
>
> PagedResult<T> prev();
>
> PagedResult<T> withOffset(int offset);
>
> PagedResult<T> withLimit(int limit);
>
> List<T> result();
>
> }
>
>
> On Tue, Jan 15, 2013 at 1:38 PM, Douglas Campos <qmx(a)qmx.me> wrote:
>>
>> I'm not a fan of those PageContext objects (remembers me of some wild-ass
>> ThreadLocals leaking all over)
>>
>> My proposal for the paging aware APIs would be something like this:
>>
>> public interface PagedResult<T> {
>>
>> List<T> next();
>>
>> List<T> prev();
>>
>> List<T> page(int offset, int limit);
>>
>> }
>>
>> and the Async counterpart
>>
>> public interface AsyncPagedResult<T> {
>>
>> void next(Callback<List<T>> callback);
>>
>> void prev(Callback<List<T>> callback);
>>
>> void page(int offset, int limit, Callback<List<T>> callback);
>>
>> public static interface Callback<U> {
>> public void onResult(U result);
>> }
>> }
>>
>> I don't like the idea of having a companion object for holding the
>> pagination state.
>>
>> Thoughts?
>>
>> -- qmx
>>
>> On 15/01/2013, at 08:37, Matthias Wessendorf <matzew(a)apache.org> wrote:
>>
>> > Hi Summers,
>> >
>> >
>> > https://gist.github.com/4532661
>> >
>> > That is a way to do paging which keeps Pipes immutable, uses
>> > readWithFilter, and doesn't impose any (for convenient definitions of
any)
>> > bookkeeping on the developer.
>> >
>> >
>> > from your Andorid gist:
>> >
>> > A) Once the response has been received, the Pipe implementation will
>> > return a List of objects. If this List instance is passed to
>> > Pipe.getPageContext the appropriate PageContext will be returned
>> >
>> > Note: There is no 'return' - the readWithFilter is void, instead a
>> > Callback is invoked (onSuccess(list)), see Pipe.java
>> >
>> > B) The developer will receive from readWithFilter() a List of object. If
>> > she passes this list into Pipe.getPageContext(List result) she will receive
>> > the PageContext associated with this result.
>> >
>> > Do you mean like:
>> >
>> > ...
>> > myPipe.readWithFilter(filter, new Callback<List<Data>>() {
>> >
>> >
>> > @Override
>> >
>> >
>> > public void onSuccess(List<Data> data) {
>> >
>> >
>> >
>> > // get the PageContext:
>> >
>> >
>> > PageContext ctx = myPipe.getPageContext(data);
>> >
>> >
>> > ...
>> >
>> >
>> > }
>> >
>> >
>> >
>> > @Override
>> >
>> >
>> > public void onFailure(Exception e) {
>> >
>> >
>> > }
>> > });
>> > Not sure about that.....
>> >
>> > But for iOS I am thinking about passing in the PageContext into the
>> > closure/block of the readWithFilter, like:
>> >
>> > -(void) readWithFilter:(void (^)(id<AGFilterConfig> config)) config
>> >
>> >
>> > success:(void (^)(id listOfObjects, id pageContext))success
>> >
>> >
>> > failure:(void (^)(NSError *error))failure;
>> > A usage would look like:
>> >
>> > [pipe readWithFilter:^(id<AGFilterConfig> config) {
>> >
>> >
>> > // set the filter args and override the given defaults
>> >
>> >
>> > } success:^(id listOfObjects, id pageContext) {
>> >
>> >
>> > // work with the listOfObjects reponse.
>> >
>> >
>> > // for paging/query info, access the given pagecontext,
>> >
>> >
>> > // of the CURRENT request
>> >
>> >
>> > ...
>> >
>> >
>> > } failure:^(NSError *error) {
>> >
>> >
>> > // handle errorz
>> >
>> >
>> > }];
>> > Any thoughts ?
>> >
>> > Not sure I like (or understand) the Pipe.getPageContext(List result)
>> > call. Current mindset is that thePageContext just (and only) belongs to the
>> > previous (executed) request... Not sure I want to support something like
>> >
>> > // first call:
>> > List<SomeType> first;
>> > myPipe.readWithFilter(.....) // set first inside of callback
>> > ...
>> > // second call:
>> > List<SomeType> second;
>> > myPipe.readWithFilter(.....) // set second inside of callback
>> > ...
>> > // third call:
>> > List<SomeType> third;
>> > myPipe.readWithFilter(.....) // set third inside of callback
>> > ...
>> >
>> >
>> >
>> >
>> > /// A BIT LATER ....:
>> > myPipe.getPageContext(first);
>> >
>> >
>> > I am not sure if that (myPipe.getPageContext(first);) is really desired
>> > (or would even easily work, as it would need to store the
"metadata").....
>> >
>> >
>> > Perhaps I am just wrong.
>> >
>> >
>> > --
>> > Matthias Wessendorf
>> >
>> > blog: http://matthiaswessendorf.wordpress.com/
>> > sessions: http://www.slideshare.net/mwessendorf
>> > twitter: http://twitter.com/mwessendorf
>> > _______________________________________________
>> > aerogear-dev mailing list
>> > aerogear-dev(a)lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
2:45 p.m.
Just to summarize what have until now :
1. Kris's proposition: https://gist.github.com/4531575
2. Summers's proposition: https://gist.github.com/4532661
3. qmx's propositon: https://gist.github.com/4538709
4. Sebi's propositionhttps://gist.github.com/4538725
On Tue, Jan 15, 2013 at 2:32 PM, Matthias Wessendorf <matzew(a)apache.org>wrote:
On Tue, Jan 15, 2013 at 2:25 PM, Matthias Wessendorf
<matzew(a)apache.org>
wrote:
> I was wondering, if the result should be received on every rquest,
ideally on the callback..., to not block (at least in iOS land, I
would pass that "result set" on to the "success" block)
-M
>
> thx
>
> On Tue, Jan 15, 2013 at 2:01 PM, Sebastien Blanc <scm.blanc(a)gmail.com>
wrote:
>> In the same spirit (inspired from
>>
http://stackoverflow.com/questions/5412059/how-to-implement-general-pagin...
)
>> :
>>
>>
>> public interface PagedResult<T> {
>>
>> PagedResult<T> next();
>>
>> PagedResult<T> prev();
>>
>> PagedResult<T> withOffset(int offset);
>>
>> PagedResult<T> withLimit(int limit);
>>
>> List<T> result();
>>
>> }
>>
>>
>> On Tue, Jan 15, 2013 at 1:38 PM, Douglas Campos <qmx(a)qmx.me> wrote:
>>>
>>> I'm not a fan of those PageContext objects (remembers me of some
wild-ass
>>> ThreadLocals leaking all over)
>>>
>>> My proposal for the paging aware APIs would be something like this:
>>>
>>> public interface PagedResult<T> {
>>>
>>> List<T> next();
>>>
>>> List<T> prev();
>>>
>>> List<T> page(int offset, int limit);
>>>
>>> }
>>>
>>> and the Async counterpart
>>>
>>> public interface AsyncPagedResult<T> {
>>>
>>> void next(Callback<List<T>> callback);
>>>
>>> void prev(Callback<List<T>> callback);
>>>
>>> void page(int offset, int limit, Callback<List<T>>
callback);
>>>
>>> public static interface Callback<U> {
>>> public void onResult(U result);
>>> }
>>> }
>>>
>>> I don't like the idea of having a companion object for holding the
>>> pagination state.
>>>
>>> Thoughts?
>>>
>>> -- qmx
>>>
>>> On 15/01/2013, at 08:37, Matthias Wessendorf <matzew(a)apache.org>
wrote:
>>>
>>> > Hi Summers,
>>> >
>>> >
>>> > https://gist.github.com/4532661
>>> >
>>> > That is a way to do paging which keeps Pipes immutable, uses
>>> > readWithFilter, and doesn't impose any (for convenient definitions
of any)
>>> > bookkeeping on the developer.
>>> >
>>> >
>>> > from your Andorid gist:
>>> >
>>> > A) Once the response has been received, the Pipe implementation will
>>> > return a List of objects. If this List instance is passed to
>>> > Pipe.getPageContext the appropriate PageContext will be returned
>>> >
>>> > Note: There is no 'return' - the readWithFilter is void,
instead a
>>> > Callback is invoked (onSuccess(list)), see Pipe.java
>>> >
>>> > B) The developer will receive from readWithFilter() a List of
object. If
>>> > she passes this list into Pipe.getPageContext(List result) she will
receive
>>> > the PageContext associated with this result.
>>> >
>>> > Do you mean like:
>>> >
>>> > ...
>>> > myPipe.readWithFilter(filter, new Callback<List<Data>>() {
>>> >
>>> >
>>> > @Override
>>> >
>>> >
>>> > public void onSuccess(List<Data> data) {
>>> >
>>> >
>>> >
>>> > // get the PageContext:
>>> >
>>> >
>>> > PageContext ctx = myPipe.getPageContext(data);
>>> >
>>> >
>>> > ...
>>> >
>>> >
>>> > }
>>> >
>>> >
>>> >
>>> > @Override
>>> >
>>> >
>>> > public void onFailure(Exception e) {
>>> >
>>> >
>>> > }
>>> > });
>>> > Not sure about that.....
>>> >
>>> > But for iOS I am thinking about passing in the PageContext into the
>>> > closure/block of the readWithFilter, like:
>>> >
>>> > -(void) readWithFilter:(void (^)(id<AGFilterConfig> config))
config
>>> >
>>> >
>>> > success:(void (^)(id listOfObjects, id pageContext))success
>>> >
>>> >
>>> > failure:(void (^)(NSError *error))failure;
>>> > A usage would look like:
>>> >
>>> > [pipe readWithFilter:^(id<AGFilterConfig> config) {
>>> >
>>> >
>>> > // set the filter args and override the given defaults
>>> >
>>> >
>>> > } success:^(id listOfObjects, id pageContext) {
>>> >
>>> >
>>> > // work with the listOfObjects reponse.
>>> >
>>> >
>>> > // for paging/query info, access the given pagecontext,
>>> >
>>> >
>>> > // of the CURRENT request
>>> >
>>> >
>>> > ...
>>> >
>>> >
>>> > } failure:^(NSError *error) {
>>> >
>>> >
>>> > // handle errorz
>>> >
>>> >
>>> > }];
>>> > Any thoughts ?
>>> >
>>> > Not sure I like (or understand) the Pipe.getPageContext(List result)
>>> > call. Current mindset is that thePageContext just (and only) belongs
to the
>>> > previous (executed) request... Not sure I want to support something
like
>>> >
>>> > // first call:
>>> > List<SomeType> first;
>>> > myPipe.readWithFilter(.....) // set first inside of callback
>>> > ...
>>> > // second call:
>>> > List<SomeType> second;
>>> > myPipe.readWithFilter(.....) // set second inside of callback
>>> > ...
>>> > // third call:
>>> > List<SomeType> third;
>>> > myPipe.readWithFilter(.....) // set third inside of callback
>>> > ...
>>> >
>>> >
>>> >
>>> >
>>> > /// A BIT LATER ....:
>>> > myPipe.getPageContext(first);
>>> >
>>> >
>>> > I am not sure if that (myPipe.getPageContext(first);) is really
desired
>>> > (or would even easily work, as it would need to store the
"metadata").....
>>> >
>>> >
>>> > Perhaps I am just wrong.
>>> >
>>> >
>>> > --
>>> > Matthias Wessendorf
>>> >
>>> > blog: http://matthiaswessendorf.wordpress.com/
>>> > sessions: http://www.slideshare.net/mwessendorf
>>> > twitter: http://twitter.com/mwessendorf
>>> > _______________________________________________
>>> > aerogear-dev mailing list
>>> > aerogear-dev(a)lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
2:49 p.m.
5. iOS, matthias https://gist.github.com/cbff741b3b21a50c3b67
(to be changed :-))
On Tue, Jan 15, 2013 at 2:45 PM, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
Just to summarize what have until now :
1. Kris's proposition: https://gist.github.com/4531575
2. Summers's proposition: https://gist.github.com/4532661
3. qmx's propositon: https://gist.github.com/4538709
4. Sebi's propositionhttps://gist.github.com/4538725
On Tue, Jan 15, 2013 at 2:32 PM, Matthias Wessendorf <matzew(a)apache.org>
wrote:
>
> On Tue, Jan 15, 2013 at 2:25 PM, Matthias Wessendorf <matzew(a)apache.org>
> wrote:
> > I was wondering, if the result should be received on every rquest,
>
>
> ideally on the callback..., to not block (at least in iOS land, I
> would pass that "result set" on to the "success" block)
>
> -M
>
> >
> > thx
> >
> > On Tue, Jan 15, 2013 at 2:01 PM, Sebastien Blanc <scm.blanc(a)gmail.com>
> > wrote:
> >> In the same spirit (inspired from
> >>
> >>
http://stackoverflow.com/questions/5412059/how-to-implement-general-pagin...)
> >> :
> >>
> >>
> >> public interface PagedResult<T> {
> >>
> >> PagedResult<T> next();
> >>
> >> PagedResult<T> prev();
> >>
> >> PagedResult<T> withOffset(int offset);
> >>
> >> PagedResult<T> withLimit(int limit);
> >>
> >> List<T> result();
> >>
> >> }
> >>
> >>
> >> On Tue, Jan 15, 2013 at 1:38 PM, Douglas Campos <qmx(a)qmx.me> wrote:
> >>>
> >>> I'm not a fan of those PageContext objects (remembers me of some
> >>> wild-ass
> >>> ThreadLocals leaking all over)
> >>>
> >>> My proposal for the paging aware APIs would be something like this:
> >>>
> >>> public interface PagedResult<T> {
> >>>
> >>> List<T> next();
> >>>
> >>> List<T> prev();
> >>>
> >>> List<T> page(int offset, int limit);
> >>>
> >>> }
> >>>
> >>> and the Async counterpart
> >>>
> >>> public interface AsyncPagedResult<T> {
> >>>
> >>> void next(Callback<List<T>> callback);
> >>>
> >>> void prev(Callback<List<T>> callback);
> >>>
> >>> void page(int offset, int limit, Callback<List<T>>
callback);
> >>>
> >>> public static interface Callback<U> {
> >>> public void onResult(U result);
> >>> }
> >>> }
> >>>
> >>> I don't like the idea of having a companion object for holding the
> >>> pagination state.
> >>>
> >>> Thoughts?
> >>>
> >>> -- qmx
> >>>
> >>> On 15/01/2013, at 08:37, Matthias Wessendorf <matzew(a)apache.org>
> >>> wrote:
> >>>
> >>> > Hi Summers,
> >>> >
> >>> >
> >>> > https://gist.github.com/4532661
> >>> >
> >>> > That is a way to do paging which keeps Pipes immutable, uses
> >>> > readWithFilter, and doesn't impose any (for convenient
definitions
> >>> > of any)
> >>> > bookkeeping on the developer.
> >>> >
> >>> >
> >>> > from your Andorid gist:
> >>> >
> >>> > A) Once the response has been received, the Pipe implementation
will
> >>> > return a List of objects. If this List instance is passed to
> >>> > Pipe.getPageContext the appropriate PageContext will be returned
> >>> >
> >>> > Note: There is no 'return' - the readWithFilter is void,
instead a
> >>> > Callback is invoked (onSuccess(list)), see Pipe.java
> >>> >
> >>> > B) The developer will receive from readWithFilter() a List of
> >>> > object. If
> >>> > she passes this list into Pipe.getPageContext(List result) she
will
> >>> > receive
> >>> > the PageContext associated with this result.
> >>> >
> >>> > Do you mean like:
> >>> >
> >>> > ...
> >>> > myPipe.readWithFilter(filter, new
Callback<List<Data>>() {
> >>> >
> >>> >
> >>> > @Override
> >>> >
> >>> >
> >>> > public void onSuccess(List<Data> data) {
> >>> >
> >>> >
> >>> >
> >>> > // get the PageContext:
> >>> >
> >>> >
> >>> > PageContext ctx = myPipe.getPageContext(data);
> >>> >
> >>> >
> >>> > ...
> >>> >
> >>> >
> >>> > }
> >>> >
> >>> >
> >>> >
> >>> > @Override
> >>> >
> >>> >
> >>> > public void onFailure(Exception e) {
> >>> >
> >>> >
> >>> > }
> >>> > });
> >>> > Not sure about that.....
> >>> >
> >>> > But for iOS I am thinking about passing in the PageContext into
the
> >>> > closure/block of the readWithFilter, like:
> >>> >
> >>> > -(void) readWithFilter:(void (^)(id<AGFilterConfig> config))
config
> >>> >
> >>> >
> >>> > success:(void (^)(id listOfObjects, id pageContext))success
> >>> >
> >>> >
> >>> > failure:(void (^)(NSError *error))failure;
> >>> > A usage would look like:
> >>> >
> >>> > [pipe readWithFilter:^(id<AGFilterConfig> config) {
> >>> >
> >>> >
> >>> > // set the filter args and override the given defaults
> >>> >
> >>> >
> >>> > } success:^(id listOfObjects, id pageContext) {
> >>> >
> >>> >
> >>> > // work with the listOfObjects reponse.
> >>> >
> >>> >
> >>> > // for paging/query info, access the given pagecontext,
> >>> >
> >>> >
> >>> > // of the CURRENT request
> >>> >
> >>> >
> >>> > ...
> >>> >
> >>> >
> >>> > } failure:^(NSError *error) {
> >>> >
> >>> >
> >>> > // handle errorz
> >>> >
> >>> >
> >>> > }];
> >>> > Any thoughts ?
> >>> >
> >>> > Not sure I like (or understand) the Pipe.getPageContext(List
result)
> >>> > call. Current mindset is that thePageContext just (and only)
belongs
> >>> > to the
> >>> > previous (executed) request... Not sure I want to support
something
> >>> > like
> >>> >
> >>> > // first call:
> >>> > List<SomeType> first;
> >>> > myPipe.readWithFilter(.....) // set first inside of callback
> >>> > ...
> >>> > // second call:
> >>> > List<SomeType> second;
> >>> > myPipe.readWithFilter(.....) // set second inside of callback
> >>> > ...
> >>> > // third call:
> >>> > List<SomeType> third;
> >>> > myPipe.readWithFilter(.....) // set third inside of callback
> >>> > ...
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > /// A BIT LATER ....:
> >>> > myPipe.getPageContext(first);
> >>> >
> >>> >
> >>> > I am not sure if that (myPipe.getPageContext(first);) is really
> >>> > desired
> >>> > (or would even easily work, as it would need to store the
> >>> > "metadata").....
> >>> >
> >>> >
> >>> > Perhaps I am just wrong.
> >>> >
> >>> >
> >>> > --
> >>> > Matthias Wessendorf
> >>> >
> >>> > blog: http://matthiaswessendorf.wordpress.com/
> >>> > sessions: http://www.slideshare.net/mwessendorf
> >>> > twitter: http://twitter.com/mwessendorf
> >>> > _______________________________________________
> >>> > aerogear-dev mailing list
> >>> > aerogear-dev(a)lists.jboss.org
> >>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>
> >>>
> >>> _______________________________________________
> >>> aerogear-dev mailing list
> >>> aerogear-dev(a)lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >>
> >>
> >> _______________________________________________
> >> aerogear-dev mailing list
> >> aerogear-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > twitter: http://twitter.com/mwessendorf
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
2:52 p.m.
Though this discussion has been great, I feel like it has headed "down a path I (JS)
cannot follow". Luke, that Star Wars quote was for you. ;)
When doing a read() (or next() or prev()…), I would expect the exact same type of
response, which is a list of objects. This is easily accomplished in JS, we overload the
read method to accept a parameter that tells it to use paging and which page to grab and
then return only the results that were requested. This can then be made easier with helper
functions like next(), prev(), etc. that use the overloaded read() method so the dev
doesn't even need to know it exists of they don't want. This would be accomplished
by maintaining the current paging state on the pipe so a call to next() just knows what to
do. Also, via a couple of setter methods on the pipe instance, we can adjust the offset
and limit at any time.
I honestly feel like this is going to be the best developer experience on JS, I just
don't know how or if it even makes sense for iOS and Java to try to get there but for
JS I just can't get myself onboard with this idea of returning an object that contains
next(), prev(), etc. methods instead of just the data that the user wants.
On Jan 15, 2013, at 7:45 AM, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
Just to summarize what have until now :
1. Kris's proposition: https://gist.github.com/4531575
2. Summers's proposition: https://gist.github.com/4532661
3. qmx's propositon: https://gist.github.com/4538709
4. Sebi's propositionhttps://gist.github.com/4538725
On Tue, Jan 15, 2013 at 2:32 PM, Matthias Wessendorf <matzew(a)apache.org> wrote:
On Tue, Jan 15, 2013 at 2:25 PM, Matthias Wessendorf <matzew(a)apache.org> wrote:
> I was wondering, if the result should be received on every rquest,
ideally on the callback..., to not block (at least in iOS land, I
would pass that "result set" on to the "success" block)
-M
>
> thx
>
> On Tue, Jan 15, 2013 at 2:01 PM, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
>> In the same spirit (inspired from
>> http://stackoverflow.com/questions/5412059/how-to-implement-general-pagin...)
>> :
>>
>>
>> public interface PagedResult<T> {
>>
>> PagedResult<T> next();
>>
>> PagedResult<T> prev();
>>
>> PagedResult<T> withOffset(int offset);
>>
>> PagedResult<T> withLimit(int limit);
>>
>> List<T> result();
>>
>> }
>>
>>
>> On Tue, Jan 15, 2013 at 1:38 PM, Douglas Campos <qmx(a)qmx.me> wrote:
>>>
>>> I'm not a fan of those PageContext objects (remembers me of some
wild-ass
>>> ThreadLocals leaking all over)
>>>
>>> My proposal for the paging aware APIs would be something like this:
>>>
>>> public interface PagedResult<T> {
>>>
>>> List<T> next();
>>>
>>> List<T> prev();
>>>
>>> List<T> page(int offset, int limit);
>>>
>>> }
>>>
>>> and the Async counterpart
>>>
>>> public interface AsyncPagedResult<T> {
>>>
>>> void next(Callback<List<T>> callback);
>>>
>>> void prev(Callback<List<T>> callback);
>>>
>>> void page(int offset, int limit, Callback<List<T>>
callback);
>>>
>>> public static interface Callback<U> {
>>> public void onResult(U result);
>>> }
>>> }
>>>
>>> I don't like the idea of having a companion object for holding the
>>> pagination state.
>>>
>>> Thoughts?
>>>
>>> -- qmx
>>>
>>> On 15/01/2013, at 08:37, Matthias Wessendorf <matzew(a)apache.org>
wrote:
>>>
>>> > Hi Summers,
>>> >
>>> >
>>> > https://gist.github.com/4532661
>>> >
>>> > That is a way to do paging which keeps Pipes immutable, uses
>>> > readWithFilter, and doesn't impose any (for convenient definitions
of any)
>>> > bookkeeping on the developer.
>>> >
>>> >
>>> > from your Andorid gist:
>>> >
>>> > A) Once the response has been received, the Pipe implementation will
>>> > return a List of objects. If this List instance is passed to
>>> > Pipe.getPageContext the appropriate PageContext will be returned
>>> >
>>> > Note: There is no 'return' - the readWithFilter is void,
instead a
>>> > Callback is invoked (onSuccess(list)), see Pipe.java
>>> >
>>> > B) The developer will receive from readWithFilter() a List of object.
If
>>> > she passes this list into Pipe.getPageContext(List result) she will
receive
>>> > the PageContext associated with this result.
>>> >
>>> > Do you mean like:
>>> >
>>> > ...
>>> > myPipe.readWithFilter(filter, new Callback<List<Data>>() {
>>> >
>>> >
>>> > @Override
>>> >
>>> >
>>> > public void onSuccess(List<Data> data) {
>>> >
>>> >
>>> >
>>> > // get the PageContext:
>>> >
>>> >
>>> > PageContext ctx = myPipe.getPageContext(data);
>>> >
>>> >
>>> > ...
>>> >
>>> >
>>> > }
>>> >
>>> >
>>> >
>>> > @Override
>>> >
>>> >
>>> > public void onFailure(Exception e) {
>>> >
>>> >
>>> > }
>>> > });
>>> > Not sure about that.....
>>> >
>>> > But for iOS I am thinking about passing in the PageContext into the
>>> > closure/block of the readWithFilter, like:
>>> >
>>> > -(void) readWithFilter:(void (^)(id<AGFilterConfig> config))
config
>>> >
>>> >
>>> > success:(void (^)(id listOfObjects, id pageContext))success
>>> >
>>> >
>>> > failure:(void (^)(NSError *error))failure;
>>> > A usage would look like:
>>> >
>>> > [pipe readWithFilter:^(id<AGFilterConfig> config) {
>>> >
>>> >
>>> > // set the filter args and override the given defaults
>>> >
>>> >
>>> > } success:^(id listOfObjects, id pageContext) {
>>> >
>>> >
>>> > // work with the listOfObjects reponse.
>>> >
>>> >
>>> > // for paging/query info, access the given pagecontext,
>>> >
>>> >
>>> > // of the CURRENT request
>>> >
>>> >
>>> > ...
>>> >
>>> >
>>> > } failure:^(NSError *error) {
>>> >
>>> >
>>> > // handle errorz
>>> >
>>> >
>>> > }];
>>> > Any thoughts ?
>>> >
>>> > Not sure I like (or understand) the Pipe.getPageContext(List result)
>>> > call. Current mindset is that thePageContext just (and only) belongs to
the
>>> > previous (executed) request... Not sure I want to support something
like
>>> >
>>> > // first call:
>>> > List<SomeType> first;
>>> > myPipe.readWithFilter(.....) // set first inside of callback
>>> > ...
>>> > // second call:
>>> > List<SomeType> second;
>>> > myPipe.readWithFilter(.....) // set second inside of callback
>>> > ...
>>> > // third call:
>>> > List<SomeType> third;
>>> > myPipe.readWithFilter(.....) // set third inside of callback
>>> > ...
>>> >
>>> >
>>> >
>>> >
>>> > /// A BIT LATER ....:
>>> > myPipe.getPageContext(first);
>>> >
>>> >
>>> > I am not sure if that (myPipe.getPageContext(first);) is really
desired
>>> > (or would even easily work, as it would need to store the
"metadata").....
>>> >
>>> >
>>> > Perhaps I am just wrong.
>>> >
>>> >
>>> > --
>>> > Matthias Wessendorf
>>> >
>>> > blog: http://matthiaswessendorf.wordpress.com/
>>> > sessions: http://www.slideshare.net/mwessendorf
>>> > twitter: http://twitter.com/mwessendorf
>>> > _______________________________________________
>>> > aerogear-dev mailing list
>>> > aerogear-dev(a)lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
2:57 p.m.
On Tue, Jan 15, 2013 at 2:52 PM, Kris Borchers <kris(a)redhat.com> wrote:
Though this discussion has been great, I feel like it has headed
"down a
path I (JS) cannot follow". Luke, that Star Wars quote was for you. ;)
When doing a read() (or next() or prev()…), I would expect the exact same
type of response, which is a list of objects. This is easily accomplished in
JS, we overload the read method to accept a parameter that tells it to use
paging and which page to grab and then return only the results that were
requested. This can then be made easier with helper functions like next(),
prev(), etc. that use the overloaded read() method so the dev doesn't even
need to know it exists of they don't want. This would be accomplished by
maintaining the current paging state on the pipe so a call to next() just
knows what to do. Also, via a couple of setter methods on the pipe instance,
we can adjust the offset and limit at any time.
I honestly feel like this is going to be the best developer experience on
JS, I just don't know how or if it even makes sense for iOS and Java to try
to get there but for JS I just can't get myself onboard with this idea of
returning an object that contains next(), prev(), etc. methods instead of
just the data that the user wants.
on next() a callback would be invoked, which delivers:
- the payload (like it does on read)
- the "paged result set"
does that make sense ?
On Jan 15, 2013, at 7:45 AM, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
Just to summarize what have until now :
1. Kris's proposition: https://gist.github.com/4531575
2. Summers's proposition: https://gist.github.com/4532661
3. qmx's propositon: https://gist.github.com/4538709
4. Sebi's propositionhttps://gist.github.com/4538725
On Tue, Jan 15, 2013 at 2:32 PM, Matthias Wessendorf <matzew(a)apache.org>
wrote:
>
> On Tue, Jan 15, 2013 at 2:25 PM, Matthias Wessendorf <matzew(a)apache.org>
> wrote:
> > I was wondering, if the result should be received on every rquest,
>
>
> ideally on the callback..., to not block (at least in iOS land, I
> would pass that "result set" on to the "success" block)
>
> -M
>
> >
> > thx
> >
> > On Tue, Jan 15, 2013 at 2:01 PM, Sebastien Blanc <scm.blanc(a)gmail.com>
> > wrote:
> >> In the same spirit (inspired from
> >>
> >>
http://stackoverflow.com/questions/5412059/how-to-implement-general-pagin...)
> >> :
> >>
> >>
> >> public interface PagedResult<T> {
> >>
> >> PagedResult<T> next();
> >>
> >> PagedResult<T> prev();
> >>
> >> PagedResult<T> withOffset(int offset);
> >>
> >> PagedResult<T> withLimit(int limit);
> >>
> >> List<T> result();
> >>
> >> }
> >>
> >>
> >> On Tue, Jan 15, 2013 at 1:38 PM, Douglas Campos <qmx(a)qmx.me> wrote:
> >>>
> >>> I'm not a fan of those PageContext objects (remembers me of some
> >>> wild-ass
> >>> ThreadLocals leaking all over)
> >>>
> >>> My proposal for the paging aware APIs would be something like this:
> >>>
> >>> public interface PagedResult<T> {
> >>>
> >>> List<T> next();
> >>>
> >>> List<T> prev();
> >>>
> >>> List<T> page(int offset, int limit);
> >>>
> >>> }
> >>>
> >>> and the Async counterpart
> >>>
> >>> public interface AsyncPagedResult<T> {
> >>>
> >>> void next(Callback<List<T>> callback);
> >>>
> >>> void prev(Callback<List<T>> callback);
> >>>
> >>> void page(int offset, int limit, Callback<List<T>>
callback);
> >>>
> >>> public static interface Callback<U> {
> >>> public void onResult(U result);
> >>> }
> >>> }
> >>>
> >>> I don't like the idea of having a companion object for holding the
> >>> pagination state.
> >>>
> >>> Thoughts?
> >>>
> >>> -- qmx
> >>>
> >>> On 15/01/2013, at 08:37, Matthias Wessendorf <matzew(a)apache.org>
> >>> wrote:
> >>>
> >>> > Hi Summers,
> >>> >
> >>> >
> >>> > https://gist.github.com/4532661
> >>> >
> >>> > That is a way to do paging which keeps Pipes immutable, uses
> >>> > readWithFilter, and doesn't impose any (for convenient
definitions
> >>> > of any)
> >>> > bookkeeping on the developer.
> >>> >
> >>> >
> >>> > from your Andorid gist:
> >>> >
> >>> > A) Once the response has been received, the Pipe implementation
will
> >>> > return a List of objects. If this List instance is passed to
> >>> > Pipe.getPageContext the appropriate PageContext will be returned
> >>> >
> >>> > Note: There is no 'return' - the readWithFilter is void,
instead a
> >>> > Callback is invoked (onSuccess(list)), see Pipe.java
> >>> >
> >>> > B) The developer will receive from readWithFilter() a List of
> >>> > object. If
> >>> > she passes this list into Pipe.getPageContext(List result) she
will
> >>> > receive
> >>> > the PageContext associated with this result.
> >>> >
> >>> > Do you mean like:
> >>> >
> >>> > ...
> >>> > myPipe.readWithFilter(filter, new
Callback<List<Data>>() {
> >>> >
> >>> >
> >>> > @Override
> >>> >
> >>> >
> >>> > public void onSuccess(List<Data> data) {
> >>> >
> >>> >
> >>> >
> >>> > // get the PageContext:
> >>> >
> >>> >
> >>> > PageContext ctx = myPipe.getPageContext(data);
> >>> >
> >>> >
> >>> > ...
> >>> >
> >>> >
> >>> > }
> >>> >
> >>> >
> >>> >
> >>> > @Override
> >>> >
> >>> >
> >>> > public void onFailure(Exception e) {
> >>> >
> >>> >
> >>> > }
> >>> > });
> >>> > Not sure about that.....
> >>> >
> >>> > But for iOS I am thinking about passing in the PageContext into
the
> >>> > closure/block of the readWithFilter, like:
> >>> >
> >>> > -(void) readWithFilter:(void (^)(id<AGFilterConfig> config))
config
> >>> >
> >>> >
> >>> > success:(void (^)(id listOfObjects, id pageContext))success
> >>> >
> >>> >
> >>> > failure:(void (^)(NSError *error))failure;
> >>> > A usage would look like:
> >>> >
> >>> > [pipe readWithFilter:^(id<AGFilterConfig> config) {
> >>> >
> >>> >
> >>> > // set the filter args and override the given defaults
> >>> >
> >>> >
> >>> > } success:^(id listOfObjects, id pageContext) {
> >>> >
> >>> >
> >>> > // work with the listOfObjects reponse.
> >>> >
> >>> >
> >>> > // for paging/query info, access the given pagecontext,
> >>> >
> >>> >
> >>> > // of the CURRENT request
> >>> >
> >>> >
> >>> > ...
> >>> >
> >>> >
> >>> > } failure:^(NSError *error) {
> >>> >
> >>> >
> >>> > // handle errorz
> >>> >
> >>> >
> >>> > }];
> >>> > Any thoughts ?
> >>> >
> >>> > Not sure I like (or understand) the Pipe.getPageContext(List
result)
> >>> > call. Current mindset is that thePageContext just (and only)
belongs
> >>> > to the
> >>> > previous (executed) request... Not sure I want to support
something
> >>> > like
> >>> >
> >>> > // first call:
> >>> > List<SomeType> first;
> >>> > myPipe.readWithFilter(.....) // set first inside of callback
> >>> > ...
> >>> > // second call:
> >>> > List<SomeType> second;
> >>> > myPipe.readWithFilter(.....) // set second inside of callback
> >>> > ...
> >>> > // third call:
> >>> > List<SomeType> third;
> >>> > myPipe.readWithFilter(.....) // set third inside of callback
> >>> > ...
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > /// A BIT LATER ....:
> >>> > myPipe.getPageContext(first);
> >>> >
> >>> >
> >>> > I am not sure if that (myPipe.getPageContext(first);) is really
> >>> > desired
> >>> > (or would even easily work, as it would need to store the
> >>> > "metadata").....
> >>> >
> >>> >
> >>> > Perhaps I am just wrong.
> >>> >
> >>> >
> >>> > --
> >>> > Matthias Wessendorf
> >>> >
> >>> > blog: http://matthiaswessendorf.wordpress.com/
> >>> > sessions: http://www.slideshare.net/mwessendorf
> >>> > twitter: http://twitter.com/mwessendorf
> >>> > _______________________________________________
> >>> > aerogear-dev mailing list
> >>> > aerogear-dev(a)lists.jboss.org
> >>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>
> >>>
> >>> _______________________________________________
> >>> aerogear-dev mailing list
> >>> aerogear-dev(a)lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >>
> >>
> >> _______________________________________________
> >> aerogear-dev mailing list
> >> aerogear-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > twitter: http://twitter.com/mwessendorf
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
3:01 p.m.
On Jan 15, 2013, at 7:57 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
On Tue, Jan 15, 2013 at 2:52 PM, Kris Borchers
<kris(a)redhat.com> wrote:
> Though this discussion has been great, I feel like it has headed "down a
> path I (JS) cannot follow". Luke, that Star Wars quote was for you. ;)
>
> When doing a read() (or next() or prev()…), I would expect the exact same
> type of response, which is a list of objects. This is easily accomplished in
> JS, we overload the read method to accept a parameter that tells it to use
> paging and which page to grab and then return only the results that were
> requested. This can then be made easier with helper functions like next(),
> prev(), etc. that use the overloaded read() method so the dev doesn't even
> need to know it exists of they don't want. This would be accomplished by
> maintaining the current paging state on the pipe so a call to next() just
> knows what to do. Also, via a couple of setter methods on the pipe instance,
> we can adjust the offset and limit at any time.
>
> I honestly feel like this is going to be the best developer experience on
> JS, I just don't know how or if it even makes sense for iOS and Java to try
> to get there but for JS I just can't get myself onboard with this idea of
> returning an object that contains next(), prev(), etc. methods instead of
> just the data that the user wants.
on next() a callback would be invoked, which delivers:
- the payload (like it does on read)
- the "paged result set"
does that make sense ?
Not really. All I would want returned from next() is the array of objects (payload) just
as read() works. If that changes, then I have to interact with next() differently than I
would read() and that doesn't seem like a good developer experience because I can just
dump the result of read() into my templates for example, but I have to hang on to and
further process the result from next() in your suggestion. I'm not a fan.
>
> On Jan 15, 2013, at 7:45 AM, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
>
> Just to summarize what have until now :
>
> 1. Kris's proposition: https://gist.github.com/4531575
>
> 2. Summers's proposition: https://gist.github.com/4532661
>
> 3. qmx's propositon: https://gist.github.com/4538709
>
> 4. Sebi's propositionhttps://gist.github.com/4538725
>
>
>
>
> On Tue, Jan 15, 2013 at 2:32 PM, Matthias Wessendorf <matzew(a)apache.org>
> wrote:
>>
>> On Tue, Jan 15, 2013 at 2:25 PM, Matthias Wessendorf <matzew(a)apache.org>
>> wrote:
>>> I was wondering, if the result should be received on every rquest,
>>
>>
>> ideally on the callback..., to not block (at least in iOS land, I
>> would pass that "result set" on to the "success" block)
>>
>> -M
>>
>>>
>>> thx
>>>
>>> On Tue, Jan 15, 2013 at 2:01 PM, Sebastien Blanc <scm.blanc(a)gmail.com>
>>> wrote:
>>>> In the same spirit (inspired from
>>>>
>>>>
http://stackoverflow.com/questions/5412059/how-to-implement-general-pagin...)
>>>> :
>>>>
>>>>
>>>> public interface PagedResult<T> {
>>>>
>>>> PagedResult<T> next();
>>>>
>>>> PagedResult<T> prev();
>>>>
>>>> PagedResult<T> withOffset(int offset);
>>>>
>>>> PagedResult<T> withLimit(int limit);
>>>>
>>>> List<T> result();
>>>>
>>>> }
>>>>
>>>>
>>>> On Tue, Jan 15, 2013 at 1:38 PM, Douglas Campos <qmx(a)qmx.me>
wrote:
>>>>>
>>>>> I'm not a fan of those PageContext objects (remembers me of some
>>>>> wild-ass
>>>>> ThreadLocals leaking all over)
>>>>>
>>>>> My proposal for the paging aware APIs would be something like this:
>>>>>
>>>>> public interface PagedResult<T> {
>>>>>
>>>>> List<T> next();
>>>>>
>>>>> List<T> prev();
>>>>>
>>>>> List<T> page(int offset, int limit);
>>>>>
>>>>> }
>>>>>
>>>>> and the Async counterpart
>>>>>
>>>>> public interface AsyncPagedResult<T> {
>>>>>
>>>>> void next(Callback<List<T>> callback);
>>>>>
>>>>> void prev(Callback<List<T>> callback);
>>>>>
>>>>> void page(int offset, int limit, Callback<List<T>>
callback);
>>>>>
>>>>> public static interface Callback<U> {
>>>>> public void onResult(U result);
>>>>> }
>>>>> }
>>>>>
>>>>> I don't like the idea of having a companion object for holding
the
>>>>> pagination state.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> -- qmx
>>>>>
>>>>> On 15/01/2013, at 08:37, Matthias Wessendorf
<matzew(a)apache.org>
>>>>> wrote:
>>>>>
>>>>>> Hi Summers,
>>>>>>
>>>>>>
>>>>>> https://gist.github.com/4532661
>>>>>>
>>>>>> That is a way to do paging which keeps Pipes immutable, uses
>>>>>> readWithFilter, and doesn't impose any (for convenient
definitions
>>>>>> of any)
>>>>>> bookkeeping on the developer.
>>>>>>
>>>>>>
>>>>>> from your Andorid gist:
>>>>>>
>>>>>> A) Once the response has been received, the Pipe implementation
will
>>>>>> return a List of objects. If this List instance is passed to
>>>>>> Pipe.getPageContext the appropriate PageContext will be returned
>>>>>>
>>>>>> Note: There is no 'return' - the readWithFilter is void,
instead a
>>>>>> Callback is invoked (onSuccess(list)), see Pipe.java
>>>>>>
>>>>>> B) The developer will receive from readWithFilter() a List of
>>>>>> object. If
>>>>>> she passes this list into Pipe.getPageContext(List result) she
will
>>>>>> receive
>>>>>> the PageContext associated with this result.
>>>>>>
>>>>>> Do you mean like:
>>>>>>
>>>>>> ...
>>>>>> myPipe.readWithFilter(filter, new
Callback<List<Data>>() {
>>>>>>
>>>>>>
>>>>>> @Override
>>>>>>
>>>>>>
>>>>>> public void onSuccess(List<Data> data) {
>>>>>>
>>>>>>
>>>>>>
>>>>>> // get the PageContext:
>>>>>>
>>>>>>
>>>>>> PageContext ctx = myPipe.getPageContext(data);
>>>>>>
>>>>>>
>>>>>> ...
>>>>>>
>>>>>>
>>>>>> }
>>>>>>
>>>>>>
>>>>>>
>>>>>> @Override
>>>>>>
>>>>>>
>>>>>> public void onFailure(Exception e) {
>>>>>>
>>>>>>
>>>>>> }
>>>>>> });
>>>>>> Not sure about that.....
>>>>>>
>>>>>> But for iOS I am thinking about passing in the PageContext into
the
>>>>>> closure/block of the readWithFilter, like:
>>>>>>
>>>>>> -(void) readWithFilter:(void (^)(id<AGFilterConfig>
config)) config
>>>>>>
>>>>>>
>>>>>> success:(void (^)(id listOfObjects, id pageContext))success
>>>>>>
>>>>>>
>>>>>> failure:(void (^)(NSError *error))failure;
>>>>>> A usage would look like:
>>>>>>
>>>>>> [pipe readWithFilter:^(id<AGFilterConfig> config) {
>>>>>>
>>>>>>
>>>>>> // set the filter args and override the given defaults
>>>>>>
>>>>>>
>>>>>> } success:^(id listOfObjects, id pageContext) {
>>>>>>
>>>>>>
>>>>>> // work with the listOfObjects reponse.
>>>>>>
>>>>>>
>>>>>> // for paging/query info, access the given pagecontext,
>>>>>>
>>>>>>
>>>>>> // of the CURRENT request
>>>>>>
>>>>>>
>>>>>> ...
>>>>>>
>>>>>>
>>>>>> } failure:^(NSError *error) {
>>>>>>
>>>>>>
>>>>>> // handle errorz
>>>>>>
>>>>>>
>>>>>> }];
>>>>>> Any thoughts ?
>>>>>>
>>>>>> Not sure I like (or understand) the Pipe.getPageContext(List
result)
>>>>>> call. Current mindset is that thePageContext just (and only)
belongs
>>>>>> to the
>>>>>> previous (executed) request... Not sure I want to support
something
>>>>>> like
>>>>>>
>>>>>> // first call:
>>>>>> List<SomeType> first;
>>>>>> myPipe.readWithFilter(.....) // set first inside of callback
>>>>>> ...
>>>>>> // second call:
>>>>>> List<SomeType> second;
>>>>>> myPipe.readWithFilter(.....) // set second inside of callback
>>>>>> ...
>>>>>> // third call:
>>>>>> List<SomeType> third;
>>>>>> myPipe.readWithFilter(.....) // set third inside of callback
>>>>>> ...
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> /// A BIT LATER ....:
>>>>>> myPipe.getPageContext(first);
>>>>>>
>>>>>>
>>>>>> I am not sure if that (myPipe.getPageContext(first);) is really
>>>>>> desired
>>>>>> (or would even easily work, as it would need to store the
>>>>>> "metadata").....
>>>>>>
>>>>>>
>>>>>> Perhaps I am just wrong.
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matthias Wessendorf
>>>>>>
>>>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>>>> sessions: http://www.slideshare.net/mwessendorf
>>>>>> twitter: http://twitter.com/mwessendorf
>>>>>> _______________________________________________
>>>>>> aerogear-dev mailing list
>>>>>> aerogear-dev(a)lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>
>>>
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> sessions: http://www.slideshare.net/mwessendorf
>>> twitter: http://twitter.com/mwessendorf
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
3:09 p.m.
On Tue, Jan 15, 2013 at 3:01 PM, Kris Borchers <kris(a)redhat.com> wrote:
On Jan 15, 2013, at 7:57 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
> On Tue, Jan 15, 2013 at 2:52 PM, Kris Borchers <kris(a)redhat.com> wrote:
>> Though this discussion has been great, I feel like it has headed "down a
>> path I (JS) cannot follow". Luke, that Star Wars quote was for you. ;)
>>
>> When doing a read() (or next() or prev()…), I would expect the exact same
>> type of response, which is a list of objects. This is easily accomplished in
>> JS, we overload the read method to accept a parameter that tells it to use
>> paging and which page to grab and then return only the results that were
>> requested. This can then be made easier with helper functions like next(),
>> prev(), etc. that use the overloaded read() method so the dev doesn't even
>> need to know it exists of they don't want. This would be accomplished by
>> maintaining the current paging state on the pipe so a call to next() just
>> knows what to do. Also, via a couple of setter methods on the pipe instance,
>> we can adjust the offset and limit at any time.
>>
>> I honestly feel like this is going to be the best developer experience on
>> JS, I just don't know how or if it even makes sense for iOS and Java to try
>> to get there but for JS I just can't get myself onboard with this idea of
>> returning an object that contains next(), prev(), etc. methods instead of
>> just the data that the user wants.
>
>
> on next() a callback would be invoked, which delivers:
> - the payload (like it does on read)
> - the "paged result set"
>
> does that make sense ?
Not really. All I would want returned from next() is the array of objects (payload) just
as read() works.
yes
If that changes, then I have to interact with next() differently than
I would read() and that doesn't seem like a good developer experience because
how would you change the paging params? Like from "3rd next invoke, I
want to show 20, instead of 5". Hrm...Perhaps that would mean a new
"pipe" needs to be set up ?
-M
I can just dump the result of read() into my templates for example,
but I have to hang on to and further process the result from next() in your suggestion.
I'm not a fan.
>
>
>
>>
>> On Jan 15, 2013, at 7:45 AM, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
>>
>> Just to summarize what have until now :
>>
>> 1. Kris's proposition: https://gist.github.com/4531575
>>
>> 2. Summers's proposition: https://gist.github.com/4532661
>>
>> 3. qmx's propositon: https://gist.github.com/4538709
>>
>> 4. Sebi's propositionhttps://gist.github.com/4538725
>>
>>
>>
>>
>> On Tue, Jan 15, 2013 at 2:32 PM, Matthias Wessendorf <matzew(a)apache.org>
>> wrote:
>>>
>>> On Tue, Jan 15, 2013 at 2:25 PM, Matthias Wessendorf
<matzew(a)apache.org>
>>> wrote:
>>>> I was wondering, if the result should be received on every rquest,
>>>
>>>
>>> ideally on the callback..., to not block (at least in iOS land, I
>>> would pass that "result set" on to the "success" block)
>>>
>>> -M
>>>
>>>>
>>>> thx
>>>>
>>>> On Tue, Jan 15, 2013 at 2:01 PM, Sebastien Blanc
<scm.blanc(a)gmail.com>
>>>> wrote:
>>>>> In the same spirit (inspired from
>>>>>
>>>>>
http://stackoverflow.com/questions/5412059/how-to-implement-general-pagin...)
>>>>> :
>>>>>
>>>>>
>>>>> public interface PagedResult<T> {
>>>>>
>>>>> PagedResult<T> next();
>>>>>
>>>>> PagedResult<T> prev();
>>>>>
>>>>> PagedResult<T> withOffset(int offset);
>>>>>
>>>>> PagedResult<T> withLimit(int limit);
>>>>>
>>>>> List<T> result();
>>>>>
>>>>> }
>>>>>
>>>>>
>>>>> On Tue, Jan 15, 2013 at 1:38 PM, Douglas Campos <qmx(a)qmx.me>
wrote:
>>>>>>
>>>>>> I'm not a fan of those PageContext objects (remembers me of
some
>>>>>> wild-ass
>>>>>> ThreadLocals leaking all over)
>>>>>>
>>>>>> My proposal for the paging aware APIs would be something like
this:
>>>>>>
>>>>>> public interface PagedResult<T> {
>>>>>>
>>>>>> List<T> next();
>>>>>>
>>>>>> List<T> prev();
>>>>>>
>>>>>> List<T> page(int offset, int limit);
>>>>>>
>>>>>> }
>>>>>>
>>>>>> and the Async counterpart
>>>>>>
>>>>>> public interface AsyncPagedResult<T> {
>>>>>>
>>>>>> void next(Callback<List<T>> callback);
>>>>>>
>>>>>> void prev(Callback<List<T>> callback);
>>>>>>
>>>>>> void page(int offset, int limit, Callback<List<T>>
callback);
>>>>>>
>>>>>> public static interface Callback<U> {
>>>>>> public void onResult(U result);
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> I don't like the idea of having a companion object for
holding the
>>>>>> pagination state.
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>> -- qmx
>>>>>>
>>>>>> On 15/01/2013, at 08:37, Matthias Wessendorf
<matzew(a)apache.org>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Summers,
>>>>>>>
>>>>>>>
>>>>>>> https://gist.github.com/4532661
>>>>>>>
>>>>>>> That is a way to do paging which keeps Pipes immutable, uses
>>>>>>> readWithFilter, and doesn't impose any (for convenient
definitions
>>>>>>> of any)
>>>>>>> bookkeeping on the developer.
>>>>>>>
>>>>>>>
>>>>>>> from your Andorid gist:
>>>>>>>
>>>>>>> A) Once the response has been received, the Pipe
implementation will
>>>>>>> return a List of objects. If this List instance is passed to
>>>>>>> Pipe.getPageContext the appropriate PageContext will be
returned
>>>>>>>
>>>>>>> Note: There is no 'return' - the readWithFilter is
void, instead a
>>>>>>> Callback is invoked (onSuccess(list)), see Pipe.java
>>>>>>>
>>>>>>> B) The developer will receive from readWithFilter() a List
of
>>>>>>> object. If
>>>>>>> she passes this list into Pipe.getPageContext(List result)
she will
>>>>>>> receive
>>>>>>> the PageContext associated with this result.
>>>>>>>
>>>>>>> Do you mean like:
>>>>>>>
>>>>>>> ...
>>>>>>> myPipe.readWithFilter(filter, new
Callback<List<Data>>() {
>>>>>>>
>>>>>>>
>>>>>>> @Override
>>>>>>>
>>>>>>>
>>>>>>> public void onSuccess(List<Data> data) {
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> // get the PageContext:
>>>>>>>
>>>>>>>
>>>>>>> PageContext ctx = myPipe.getPageContext(data);
>>>>>>>
>>>>>>>
>>>>>>> ...
>>>>>>>
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> @Override
>>>>>>>
>>>>>>>
>>>>>>> public void onFailure(Exception e) {
>>>>>>>
>>>>>>>
>>>>>>> }
>>>>>>> });
>>>>>>> Not sure about that.....
>>>>>>>
>>>>>>> But for iOS I am thinking about passing in the PageContext
into the
>>>>>>> closure/block of the readWithFilter, like:
>>>>>>>
>>>>>>> -(void) readWithFilter:(void (^)(id<AGFilterConfig>
config)) config
>>>>>>>
>>>>>>>
>>>>>>> success:(void (^)(id listOfObjects, id pageContext))success
>>>>>>>
>>>>>>>
>>>>>>> failure:(void (^)(NSError *error))failure;
>>>>>>> A usage would look like:
>>>>>>>
>>>>>>> [pipe readWithFilter:^(id<AGFilterConfig> config) {
>>>>>>>
>>>>>>>
>>>>>>> // set the filter args and override the given defaults
>>>>>>>
>>>>>>>
>>>>>>> } success:^(id listOfObjects, id pageContext) {
>>>>>>>
>>>>>>>
>>>>>>> // work with the listOfObjects reponse.
>>>>>>>
>>>>>>>
>>>>>>> // for paging/query info, access the given pagecontext,
>>>>>>>
>>>>>>>
>>>>>>> // of the CURRENT request
>>>>>>>
>>>>>>>
>>>>>>> ...
>>>>>>>
>>>>>>>
>>>>>>> } failure:^(NSError *error) {
>>>>>>>
>>>>>>>
>>>>>>> // handle errorz
>>>>>>>
>>>>>>>
>>>>>>> }];
>>>>>>> Any thoughts ?
>>>>>>>
>>>>>>> Not sure I like (or understand) the Pipe.getPageContext(List
result)
>>>>>>> call. Current mindset is that thePageContext just (and only)
belongs
>>>>>>> to the
>>>>>>> previous (executed) request... Not sure I want to support
something
>>>>>>> like
>>>>>>>
>>>>>>> // first call:
>>>>>>> List<SomeType> first;
>>>>>>> myPipe.readWithFilter(.....) // set first inside of callback
>>>>>>> ...
>>>>>>> // second call:
>>>>>>> List<SomeType> second;
>>>>>>> myPipe.readWithFilter(.....) // set second inside of
callback
>>>>>>> ...
>>>>>>> // third call:
>>>>>>> List<SomeType> third;
>>>>>>> myPipe.readWithFilter(.....) // set third inside of callback
>>>>>>> ...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> /// A BIT LATER ....:
>>>>>>> myPipe.getPageContext(first);
>>>>>>>
>>>>>>>
>>>>>>> I am not sure if that (myPipe.getPageContext(first);) is
really
>>>>>>> desired
>>>>>>> (or would even easily work, as it would need to store the
>>>>>>> "metadata").....
>>>>>>>
>>>>>>>
>>>>>>> Perhaps I am just wrong.
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matthias Wessendorf
>>>>>>>
>>>>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>>>>> sessions: http://www.slideshare.net/mwessendorf
>>>>>>> twitter: http://twitter.com/mwessendorf
>>>>>>> _______________________________________________
>>>>>>> aerogear-dev mailing list
>>>>>>> aerogear-dev(a)lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> aerogear-dev mailing list
>>>>>> aerogear-dev(a)lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matthias Wessendorf
>>>>
>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>> sessions: http://www.slideshare.net/mwessendorf
>>>> twitter: http://twitter.com/mwessendorf
>>>
>>>
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> sessions: http://www.slideshare.net/mwessendorf
>>> twitter: http://twitter.com/mwessendorf
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
3:12 p.m.
On Jan 15, 2013, at 8:09 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
On Tue, Jan 15, 2013 at 3:01 PM, Kris Borchers
<kris(a)redhat.com> wrote:
>
> On Jan 15, 2013, at 7:57 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
>
>> On Tue, Jan 15, 2013 at 2:52 PM, Kris Borchers <kris(a)redhat.com> wrote:
>>> Though this discussion has been great, I feel like it has headed "down
a
>>> path I (JS) cannot follow". Luke, that Star Wars quote was for you. ;)
>>>
>>> When doing a read() (or next() or prev()…), I would expect the exact same
>>> type of response, which is a list of objects. This is easily accomplished in
>>> JS, we overload the read method to accept a parameter that tells it to use
>>> paging and which page to grab and then return only the results that were
>>> requested. This can then be made easier with helper functions like next(),
>>> prev(), etc. that use the overloaded read() method so the dev doesn't
even
>>> need to know it exists of they don't want. This would be accomplished by
>>> maintaining the current paging state on the pipe so a call to next() just
>>> knows what to do. Also, via a couple of setter methods on the pipe instance,
>>> we can adjust the offset and limit at any time.
>>>
>>> I honestly feel like this is going to be the best developer experience on
>>> JS, I just don't know how or if it even makes sense for iOS and Java to
try
>>> to get there but for JS I just can't get myself onboard with this idea
of
>>> returning an object that contains next(), prev(), etc. methods instead of
>>> just the data that the user wants.
>>
>>
>> on next() a callback would be invoked, which delivers:
>> - the payload (like it does on read)
>> - the "paged result set"
>>
>> does that make sense ?
>
> Not really. All I would want returned from next() is the array of objects (payload)
just as read() works.
yes
> If that changes, then I have to interact with next() differently than I would read()
and that doesn't seem like a good developer experience because
how would you change the paging params? Like from "3rd next invoke, I
want to show 20, instead of 5". Hrm...Perhaps that would mean a new
"pipe" needs to be set up ?
Nope, as I've said before, there would be a setter for offset and limit so that the
initial values that were used when the pipe was set up can be modified at any time.
-M
> I can just dump the result of read() into my templates for example, but I have to
hang on to and further process the result from next() in your suggestion. I'm not a
fan.
>>
>>
>>
>>>
>>> On Jan 15, 2013, at 7:45 AM, Sebastien Blanc <scm.blanc(a)gmail.com>
wrote:
>>>
>>> Just to summarize what have until now :
>>>
>>> 1. Kris's proposition: https://gist.github.com/4531575
>>>
>>> 2. Summers's proposition: https://gist.github.com/4532661
>>>
>>> 3. qmx's propositon: https://gist.github.com/4538709
>>>
>>> 4. Sebi's propositionhttps://gist.github.com/4538725
>>>
>>>
>>>
>>>
>>> On Tue, Jan 15, 2013 at 2:32 PM, Matthias Wessendorf
<matzew(a)apache.org>
>>> wrote:
>>>>
>>>> On Tue, Jan 15, 2013 at 2:25 PM, Matthias Wessendorf
<matzew(a)apache.org>
>>>> wrote:
>>>>> I was wondering, if the result should be received on every rquest,
>>>>
>>>>
>>>> ideally on the callback..., to not block (at least in iOS land, I
>>>> would pass that "result set" on to the "success"
block)
>>>>
>>>> -M
>>>>
>>>>>
>>>>> thx
>>>>>
>>>>> On Tue, Jan 15, 2013 at 2:01 PM, Sebastien Blanc
<scm.blanc(a)gmail.com>
>>>>> wrote:
>>>>>> In the same spirit (inspired from
>>>>>>
>>>>>>
http://stackoverflow.com/questions/5412059/how-to-implement-general-pagin...)
>>>>>> :
>>>>>>
>>>>>>
>>>>>> public interface PagedResult<T> {
>>>>>>
>>>>>> PagedResult<T> next();
>>>>>>
>>>>>> PagedResult<T> prev();
>>>>>>
>>>>>> PagedResult<T> withOffset(int offset);
>>>>>>
>>>>>> PagedResult<T> withLimit(int limit);
>>>>>>
>>>>>> List<T> result();
>>>>>>
>>>>>> }
>>>>>>
>>>>>>
>>>>>> On Tue, Jan 15, 2013 at 1:38 PM, Douglas Campos
<qmx(a)qmx.me> wrote:
>>>>>>>
>>>>>>> I'm not a fan of those PageContext objects (remembers me
of some
>>>>>>> wild-ass
>>>>>>> ThreadLocals leaking all over)
>>>>>>>
>>>>>>> My proposal for the paging aware APIs would be something like
this:
>>>>>>>
>>>>>>> public interface PagedResult<T> {
>>>>>>>
>>>>>>> List<T> next();
>>>>>>>
>>>>>>> List<T> prev();
>>>>>>>
>>>>>>> List<T> page(int offset, int limit);
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>> and the Async counterpart
>>>>>>>
>>>>>>> public interface AsyncPagedResult<T> {
>>>>>>>
>>>>>>> void next(Callback<List<T>> callback);
>>>>>>>
>>>>>>> void prev(Callback<List<T>> callback);
>>>>>>>
>>>>>>> void page(int offset, int limit,
Callback<List<T>> callback);
>>>>>>>
>>>>>>> public static interface Callback<U> {
>>>>>>> public void onResult(U result);
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> I don't like the idea of having a companion object for
holding the
>>>>>>> pagination state.
>>>>>>>
>>>>>>> Thoughts?
>>>>>>>
>>>>>>> -- qmx
>>>>>>>
>>>>>>> On 15/01/2013, at 08:37, Matthias Wessendorf
<matzew(a)apache.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Summers,
>>>>>>>>
>>>>>>>>
>>>>>>>> https://gist.github.com/4532661
>>>>>>>>
>>>>>>>> That is a way to do paging which keeps Pipes immutable,
uses
>>>>>>>> readWithFilter, and doesn't impose any (for
convenient definitions
>>>>>>>> of any)
>>>>>>>> bookkeeping on the developer.
>>>>>>>>
>>>>>>>>
>>>>>>>> from your Andorid gist:
>>>>>>>>
>>>>>>>> A) Once the response has been received, the Pipe
implementation will
>>>>>>>> return a List of objects. If this List instance is passed
to
>>>>>>>> Pipe.getPageContext the appropriate PageContext will be
returned
>>>>>>>>
>>>>>>>> Note: There is no 'return' - the readWithFilter
is void, instead a
>>>>>>>> Callback is invoked (onSuccess(list)), see Pipe.java
>>>>>>>>
>>>>>>>> B) The developer will receive from readWithFilter() a
List of
>>>>>>>> object. If
>>>>>>>> she passes this list into Pipe.getPageContext(List
result) she will
>>>>>>>> receive
>>>>>>>> the PageContext associated with this result.
>>>>>>>>
>>>>>>>> Do you mean like:
>>>>>>>>
>>>>>>>> ...
>>>>>>>> myPipe.readWithFilter(filter, new
Callback<List<Data>>() {
>>>>>>>>
>>>>>>>>
>>>>>>>> @Override
>>>>>>>>
>>>>>>>>
>>>>>>>> public void onSuccess(List<Data> data) {
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> // get the PageContext:
>>>>>>>>
>>>>>>>>
>>>>>>>> PageContext ctx = myPipe.getPageContext(data);
>>>>>>>>
>>>>>>>>
>>>>>>>> ...
>>>>>>>>
>>>>>>>>
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> @Override
>>>>>>>>
>>>>>>>>
>>>>>>>> public void onFailure(Exception e) {
>>>>>>>>
>>>>>>>>
>>>>>>>> }
>>>>>>>> });
>>>>>>>> Not sure about that.....
>>>>>>>>
>>>>>>>> But for iOS I am thinking about passing in the
PageContext into the
>>>>>>>> closure/block of the readWithFilter, like:
>>>>>>>>
>>>>>>>> -(void) readWithFilter:(void (^)(id<AGFilterConfig>
config)) config
>>>>>>>>
>>>>>>>>
>>>>>>>> success:(void (^)(id listOfObjects, id
pageContext))success
>>>>>>>>
>>>>>>>>
>>>>>>>> failure:(void (^)(NSError *error))failure;
>>>>>>>> A usage would look like:
>>>>>>>>
>>>>>>>> [pipe readWithFilter:^(id<AGFilterConfig> config)
{
>>>>>>>>
>>>>>>>>
>>>>>>>> // set the filter args and override the given defaults
>>>>>>>>
>>>>>>>>
>>>>>>>> } success:^(id listOfObjects, id pageContext) {
>>>>>>>>
>>>>>>>>
>>>>>>>> // work with the listOfObjects reponse.
>>>>>>>>
>>>>>>>>
>>>>>>>> // for paging/query info, access the given pagecontext,
>>>>>>>>
>>>>>>>>
>>>>>>>> // of the CURRENT request
>>>>>>>>
>>>>>>>>
>>>>>>>> ...
>>>>>>>>
>>>>>>>>
>>>>>>>> } failure:^(NSError *error) {
>>>>>>>>
>>>>>>>>
>>>>>>>> // handle errorz
>>>>>>>>
>>>>>>>>
>>>>>>>> }];
>>>>>>>> Any thoughts ?
>>>>>>>>
>>>>>>>> Not sure I like (or understand) the
Pipe.getPageContext(List result)
>>>>>>>> call. Current mindset is that thePageContext just (and
only) belongs
>>>>>>>> to the
>>>>>>>> previous (executed) request... Not sure I want to support
something
>>>>>>>> like
>>>>>>>>
>>>>>>>> // first call:
>>>>>>>> List<SomeType> first;
>>>>>>>> myPipe.readWithFilter(.....) // set first inside of
callback
>>>>>>>> ...
>>>>>>>> // second call:
>>>>>>>> List<SomeType> second;
>>>>>>>> myPipe.readWithFilter(.....) // set second inside of
callback
>>>>>>>> ...
>>>>>>>> // third call:
>>>>>>>> List<SomeType> third;
>>>>>>>> myPipe.readWithFilter(.....) // set third inside of
callback
>>>>>>>> ...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> /// A BIT LATER ....:
>>>>>>>> myPipe.getPageContext(first);
>>>>>>>>
>>>>>>>>
>>>>>>>> I am not sure if that (myPipe.getPageContext(first);) is
really
>>>>>>>> desired
>>>>>>>> (or would even easily work, as it would need to store
the
>>>>>>>> "metadata").....
>>>>>>>>
>>>>>>>>
>>>>>>>> Perhaps I am just wrong.
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Matthias Wessendorf
>>>>>>>>
>>>>>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>>>>>> sessions: http://www.slideshare.net/mwessendorf
>>>>>>>> twitter: http://twitter.com/mwessendorf
>>>>>>>> _______________________________________________
>>>>>>>> aerogear-dev mailing list
>>>>>>>> aerogear-dev(a)lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> aerogear-dev mailing list
>>>>>>> aerogear-dev(a)lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> aerogear-dev mailing list
>>>>>> aerogear-dev(a)lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matthias Wessendorf
>>>>>
>>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>>> sessions: http://www.slideshare.net/mwessendorf
>>>>> twitter: http://twitter.com/mwessendorf
>>>>
>>>>
>>>>
>>>> --
>>>> Matthias Wessendorf
>>>>
>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>> sessions: http://www.slideshare.net/mwessendorf
>>>> twitter: http://twitter.com/mwessendorf
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
3:22 p.m.
On Tue, Jan 15, 2013 at 3:12 PM, Kris Borchers <kris(a)redhat.com> wrote:
Nope, as I've said before, there would be a setter for offset and
limit so that the initial values that were used when the pipe was set up can be modified
at any time.
ok, that's a detail - but on a "context" (or what ever) this could be
done..
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
3:36 p.m.
HEre:
if one wants to change the paging params.... simply start a new
"readWithFilter" (yes, that name can change)
https://gist.github.com/cbff741b3b21a50c3b67
On Tue, Jan 15, 2013 at 3:22 PM, Matthias Wessendorf <matzew(a)apache.org> wrote:
On Tue, Jan 15, 2013 at 3:12 PM, Kris Borchers
<kris(a)redhat.com> wrote:
> Nope, as I've said before, there would be a setter for offset and limit so that
the initial values that were used when the pipe was set up can be modified at any time.
ok, that's a detail - but on a "context" (or what ever) this could be
done..
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
4:02 p.m.
On 01/15/2013 05:37 AM, Matthias Wessendorf wrote:
Hi Summers,
https://gist.github.com/4532661
That is a way to do paging which keeps Pipes immutable, uses
readWithFilter, and doesn't impose any (for convenient definitions
of any) bookkeeping on the developer.
from your Andorid gist <https://gist.github.com/4532661>;:
A) /Once the response has been received, the Pipe implementation will
return a List of objects. If this List instance is passed to
Pipe.getPageContext the appropriate PageContext will be returned/
Note: There is no 'return' - the |readWithFilter| is |void|, instead a
Callback is invoked (|onSuccess(list)|), see Pipe.java
<https://github.com/aerogear/aerogear-android/blob/master/src/org/jboss/ae...
Yeah I totally fubarred that when I was putting together the gist.
B) /The developer will receive from readWithFilter() a List of object.
If she passes this list into Pipe.getPageContext(List result) she will
receive the PageContext associated with this result./
Do you mean like:
...
myPipe.readWithFilter(filter, new Callback<List<Data>>() {
@Override
public void onSuccess(List<Data> data) {
// get the PageContext:
PageContext ctx = myPipe.getPageContext(data);
...
}
@Override
public void onFailure(Exception e) {
}
});
Not sure about that.....
But for iOS I am thinking about passing in the |PageContext| into the
closure/block of the |readWithFilter|, like:
-(void) readWithFilter:(void (^)(id<AGFilterConfig> config)) config
success:(void (^)(id listOfObjects, id pageContext))success
failure:(void (^)(NSError *error))failure;
A usage would look like:
[pipe readWithFilter:^(id<AGFilterConfig> config) {
// set the filter args and override the given defaults
} success:^(id listOfObjects, id pageContext) {
// work with the listOfObjects reponse.
// for paging/query info, access the given pagecontext,
// of the CURRENT request
...
} failure:^(NSError *error) {
// handle errorz
}];
Any thoughts ?
I don't hate it. I don't love it but I don't hate it. On the one hand
it makes where the pageContext comes from explicit and you get it with
your request. On the other hand you don't always a PageContext for a
request so it will be something devs always have to drag around.
Not sure I like (or understand) the |Pipe.getPageContext(List
result)| call. Current mindset is that the|PageContext| just (and
/only/) belongs to the previous (executed) request... Not sure I want
to support something like
// first call:
List<SomeType> first;
myPipe.readWithFilter(.....) // set first inside of callback
...
// second call:
List<SomeType> second;
myPipe.readWithFilter(.....) // set second inside of callback
...
// third call:
List<SomeType> third;
myPipe.readWithFilter(.....) // set third inside of callback
...
/// A BIT LATER ....:
myPipe.getPageContext(first);
I am not sure if that (|myPipe.getPageContext(first);|) is really
desired (or would even easily work, as it would need to store the
"metadata").....
It easily works in Java land. (To leak some implementation here look at
WeakHashMap, the entries die when the keys die).
I'm open to suggestions because I am not in love with this method either.
Perhaps I am just wrong.
You are not wrong at all.
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
4:02 p.m.
I think what we are talking about is pretty much the same, just different semantics and a
little bit different impl/usage. See https://gist.github.com/4539188
On Jan 15, 2013, at 8:36 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
HEre:
if one wants to change the paging params.... simply start a new
"readWithFilter" (yes, that name can change)
https://gist.github.com/cbff741b3b21a50c3b67
On Tue, Jan 15, 2013 at 3:22 PM, Matthias Wessendorf <matzew(a)apache.org> wrote:
> On Tue, Jan 15, 2013 at 3:12 PM, Kris Borchers <kris(a)redhat.com> wrote:
>> Nope, as I've said before, there would be a setter for offset and limit so
that the initial values that were used when the pipe was set up can be modified at any
time.
>
> ok, that's a detail - but on a "context" (or what ever) this could be
done..
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
4:06 p.m.
On 01/15/2013 06:17 AM, Sebastien Blanc wrote:
Hi,
Some aditional remarks on Summers gist :
Instead of :
Pipe.readWithFilter(ReadFilter)
Couldn't we just overload the read() method ? i.e :
read(ReadFilter filter)
We can depending on how it interacts with the other implementations of
the library.
About the where property in ReadFilter class :
Do we really want to mix paging and querying ?
We do and we don't. The request
itself requires both of these
properties so it makes technical sense to pass them in a single
wrapper. I agree it makes more logical sense to keep them as two
separate object which you can pass independently.
About Pipe.getPageContext(List result):
Same remarks as Matthias, not sure to understand how it works (even if
I think I've understand ...)
In Java it's back by a WeakHashMap. Lots of Java specific
implementation magic makes it very easy. As I've said otherwise I'm not
in love with the method but it scratches an itch.
General remarks about Paging:
Even if it's not in scope for 1.0, I think we have to keep in mind
that we will also be able to do pagination "offline" / "only client
side" (maybe we would do some paging on a Store element ?) , so we
have to consider this when designing our API.
I've been thinking about that as well. The Stores we have right now
don't lend themselves to paging very well because they don't have a
concept of order built in.
Seb
On Tue, Jan 15, 2013 at 11:37 AM, Matthias Wessendorf
<matzew(a)apache.org <mailto:matzew@apache.org>> wrote:
https://gist.github.com/4532661
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
4:11 p.m.
On 01/15/2013 07:29 AM, Douglas Campos wrote:
On 14/01/2013, at 22:43, Summers Pittman <supittma(a)redhat.com>
wrote:
> I've been trying to keep the pipe's methods threadsafe by minimizing
> mutable and shared state. (PageContext is an exception, but WeakHashMap
> explicitly uses the instance of the object for lookups and not the hash
> code).
Keep in mind that we're discussing end-user APIs, and those kind of implementation
detail leaks can lean you towards a "fabricated" solution to meet the
implementation you have in mind ;)
I agree. I just want the end user API not to
blast the users foot off
if she makes the wrong assumption.
-- qmx
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
5:18 p.m.
On 01/15/2013 08:45 AM, Sebastien Blanc wrote:
Just to summarize what have until now :
1. Kris's proposition: https://gist.github.com/4531575
2. Summers's proposition: https://gist.github.com/4532661
3. qmx's propositon: https://gist.github.com/4538709
4. Sebi's propositionhttps://gist.github.com/4538725
I've just updated my proposition. PageContext is no longer and thing
and I've replaced it with a PagedList interface.
On Tue, Jan 15, 2013 at 2:32 PM, Matthias Wessendorf
<matzew(a)apache.org <mailto:matzew@apache.org>> wrote:
On Tue, Jan 15, 2013 at 2:25 PM, Matthias Wessendorf
<matzew(a)apache.org <mailto:matzew@apache.org>> wrote:
> I was wondering, if the result should be received on every rquest,
ideally on the callback..., to not block (at least in iOS land, I
would pass that "result set" on to the "success" block)
-M
>
> thx
>
> On Tue, Jan 15, 2013 at 2:01 PM, Sebastien Blanc
<scm.blanc(a)gmail.com <mailto:scm.blanc@gmail.com>> wrote:
>> In the same spirit (inspired from
>>
http://stackoverflow.com/questions/5412059/how-to-implement-general-pagin...)
>> :
>>
>>
>> public interface PagedResult<T> {
>>
>> PagedResult<T> next();
>>
>> PagedResult<T> prev();
>>
>> PagedResult<T> withOffset(int offset);
>>
>> PagedResult<T> withLimit(int limit);
>>
>> List<T> result();
>>
>> }
>>
>>
>> On Tue, Jan 15, 2013 at 1:38 PM, Douglas Campos <qmx(a)qmx.me
<mailto:qmx@qmx.me>> wrote:
>>>
>>> I'm not a fan of those PageContext objects (remembers me of
some wild-ass
>>> ThreadLocals leaking all over)
>>>
>>> My proposal for the paging aware APIs would be something like
this:
>>>
>>> public interface PagedResult<T> {
>>>
>>> List<T> next();
>>>
>>> List<T> prev();
>>>
>>> List<T> page(int offset, int limit);
>>>
>>> }
>>>
>>> and the Async counterpart
>>>
>>> public interface AsyncPagedResult<T> {
>>>
>>> void next(Callback<List<T>> callback);
>>>
>>> void prev(Callback<List<T>> callback);
>>>
>>> void page(int offset, int limit, Callback<List<T>>
callback);
>>>
>>> public static interface Callback<U> {
>>> public void onResult(U result);
>>> }
>>> }
>>>
>>> I don't like the idea of having a companion object for holding the
>>> pagination state.
>>>
>>> Thoughts?
>>>
>>> -- qmx
>>>
>>> On 15/01/2013, at 08:37, Matthias Wessendorf
<matzew(a)apache.org <mailto:matzew@apache.org>> wrote:
>>>
>>> > Hi Summers,
>>> >
>>> >
>>> > https://gist.github.com/4532661
>>> >
>>> > That is a way to do paging which keeps Pipes immutable, uses
>>> > readWithFilter, and doesn't impose any (for convenient
definitions of any)
>>> > bookkeeping on the developer.
>>> >
>>> >
>>> > from your Andorid gist:
>>> >
>>> > A) Once the response has been received, the Pipe
implementation will
>>> > return a List of objects. If this List instance is passed to
>>> > Pipe.getPageContext the appropriate PageContext will be returned
>>> >
>>> > Note: There is no 'return' - the readWithFilter is void,
instead a
>>> > Callback is invoked (onSuccess(list)), see Pipe.java
>>> >
>>> > B) The developer will receive from readWithFilter() a List
of object. If
>>> > she passes this list into Pipe.getPageContext(List result)
she will receive
>>> > the PageContext associated with this result.
>>> >
>>> > Do you mean like:
>>> >
>>> > ...
>>> > myPipe.readWithFilter(filter, new
Callback<List<Data>>() {
>>> >
>>> >
>>> > @Override
>>> >
>>> >
>>> > public void onSuccess(List<Data> data) {
>>> >
>>> >
>>> >
>>> > // get the PageContext:
>>> >
>>> >
>>> > PageContext ctx = myPipe.getPageContext(data);
>>> >
>>> >
>>> > ...
>>> >
>>> >
>>> > }
>>> >
>>> >
>>> >
>>> > @Override
>>> >
>>> >
>>> > public void onFailure(Exception e) {
>>> >
>>> >
>>> > }
>>> > });
>>> > Not sure about that.....
>>> >
>>> > But for iOS I am thinking about passing in the PageContext
into the
>>> > closure/block of the readWithFilter, like:
>>> >
>>> > -(void) readWithFilter:(void (^)(id<AGFilterConfig> config))
config
>>> >
>>> >
>>> > success:(void (^)(id listOfObjects, id pageContext))success
>>> >
>>> >
>>> > failure:(void (^)(NSError *error))failure;
>>> > A usage would look like:
>>> >
>>> > [pipe readWithFilter:^(id<AGFilterConfig> config) {
>>> >
>>> >
>>> > // set the filter args and override the given defaults
>>> >
>>> >
>>> > } success:^(id listOfObjects, id pageContext) {
>>> >
>>> >
>>> > // work with the listOfObjects reponse.
>>> >
>>> >
>>> > // for paging/query info, access the given pagecontext,
>>> >
>>> >
>>> > // of the CURRENT request
>>> >
>>> >
>>> > ...
>>> >
>>> >
>>> > } failure:^(NSError *error) {
>>> >
>>> >
>>> > // handle errorz
>>> >
>>> >
>>> > }];
>>> > Any thoughts ?
>>> >
>>> > Not sure I like (or understand) the Pipe.getPageContext(List
result)
>>> > call. Current mindset is that thePageContext just (and only)
belongs to the
>>> > previous (executed) request... Not sure I want to support
something like
>>> >
>>> > // first call:
>>> > List<SomeType> first;
>>> > myPipe.readWithFilter(.....) // set first inside of callback
>>> > ...
>>> > // second call:
>>> > List<SomeType> second;
>>> > myPipe.readWithFilter(.....) // set second inside of callback
>>> > ...
>>> > // third call:
>>> > List<SomeType> third;
>>> > myPipe.readWithFilter(.....) // set third inside of callback
>>> > ...
>>> >
>>> >
>>> >
>>> >
>>> > /// A BIT LATER ....:
>>> > myPipe.getPageContext(first);
>>> >
>>> >
>>> > I am not sure if that (myPipe.getPageContext(first);) is
really desired
>>> > (or would even easily work, as it would need to store the
"metadata").....
>>> >
>>> >
>>> > Perhaps I am just wrong.
>>> >
>>> >
>>> > --
>>> > Matthias Wessendorf
>>> >
>>> > blog: http://matthiaswessendorf.wordpress.com/
>>> > sessions: http://www.slideshare.net/mwessendorf
>>> > twitter: http://twitter.com/mwessendorf
>>> > _______________________________________________
>>> > aerogear-dev mailing list
>>> > aerogear-dev(a)lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>
>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
8:32 p.m.
OK, so here is where I stand. I don't think there is any way to have the API's
match identically between JS and the others. It sounds like Android and iOS are getting
closer to agreement but as they get closer, it seems they get further away from what makes
sense for JS. Basically, anything that involves creating a new object to maintain paged
pipes rather than just using any other pipe and overloading the read method to do paging
doesn't make sense to me. IMO, JS should move forward with basically what was written
up in the strawman as that feels like the best solution for JS.
On Jan 15, 2013, at 10:18 AM, Summers Pittman <supittma(a)redhat.com> wrote:
On 01/15/2013 08:45 AM, Sebastien Blanc wrote:
> Just to summarize what have until now :
>
> 1. Kris's proposition: https://gist.github.com/4531575
>
> 2. Summers's proposition: https://gist.github.com/4532661
>
> 3. qmx's propositon: https://gist.github.com/4538709
>
> 4. Sebi's propositionhttps://gist.github.com/4538725
>
>
I've just updated my proposition. PageContext is no longer and thing and I've
replaced it with a PagedList interface.
>
>
> On Tue, Jan 15, 2013 at 2:32 PM, Matthias Wessendorf <matzew(a)apache.org>
wrote:
> On Tue, Jan 15, 2013 at 2:25 PM, Matthias Wessendorf <matzew(a)apache.org>
wrote:
> > I was wondering, if the result should be received on every rquest,
>
>
> ideally on the callback..., to not block (at least in iOS land, I
> would pass that "result set" on to the "success" block)
>
> -M
>
> >
> > thx
> >
> > On Tue, Jan 15, 2013 at 2:01 PM, Sebastien Blanc <scm.blanc(a)gmail.com>
wrote:
> >> In the same spirit (inspired from
> >>
http://stackoverflow.com/questions/5412059/how-to-implement-general-pagin...)
> >> :
> >>
> >>
> >> public interface PagedResult<T> {
> >>
> >> PagedResult<T> next();
> >>
> >> PagedResult<T> prev();
> >>
> >> PagedResult<T> withOffset(int offset);
> >>
> >> PagedResult<T> withLimit(int limit);
> >>
> >> List<T> result();
> >>
> >> }
> >>
> >>
> >> On Tue, Jan 15, 2013 at 1:38 PM, Douglas Campos <qmx(a)qmx.me> wrote:
> >>>
> >>> I'm not a fan of those PageContext objects (remembers me of some
wild-ass
> >>> ThreadLocals leaking all over)
> >>>
> >>> My proposal for the paging aware APIs would be something like this:
> >>>
> >>> public interface PagedResult<T> {
> >>>
> >>> List<T> next();
> >>>
> >>> List<T> prev();
> >>>
> >>> List<T> page(int offset, int limit);
> >>>
> >>> }
> >>>
> >>> and the Async counterpart
> >>>
> >>> public interface AsyncPagedResult<T> {
> >>>
> >>> void next(Callback<List<T>> callback);
> >>>
> >>> void prev(Callback<List<T>> callback);
> >>>
> >>> void page(int offset, int limit, Callback<List<T>>
callback);
> >>>
> >>> public static interface Callback<U> {
> >>> public void onResult(U result);
> >>> }
> >>> }
> >>>
> >>> I don't like the idea of having a companion object for holding the
> >>> pagination state.
> >>>
> >>> Thoughts?
> >>>
> >>> -- qmx
> >>>
> >>> On 15/01/2013, at 08:37, Matthias Wessendorf <matzew(a)apache.org>
wrote:
> >>>
> >>> > Hi Summers,
> >>> >
> >>> >
> >>> > https://gist.github.com/4532661
> >>> >
> >>> > That is a way to do paging which keeps Pipes immutable, uses
> >>> > readWithFilter, and doesn't impose any (for convenient
definitions of any)
> >>> > bookkeeping on the developer.
> >>> >
> >>> >
> >>> > from your Andorid gist:
> >>> >
> >>> > A) Once the response has been received, the Pipe implementation
will
> >>> > return a List of objects. If this List instance is passed to
> >>> > Pipe.getPageContext the appropriate PageContext will be returned
> >>> >
> >>> > Note: There is no 'return' - the readWithFilter is void,
instead a
> >>> > Callback is invoked (onSuccess(list)), see Pipe.java
> >>> >
> >>> > B) The developer will receive from readWithFilter() a List of
object. If
> >>> > she passes this list into Pipe.getPageContext(List result) she will
receive
> >>> > the PageContext associated with this result.
> >>> >
> >>> > Do you mean like:
> >>> >
> >>> > ...
> >>> > myPipe.readWithFilter(filter, new
Callback<List<Data>>() {
> >>> >
> >>> >
> >>> > @Override
> >>> >
> >>> >
> >>> > public void onSuccess(List<Data> data) {
> >>> >
> >>> >
> >>> >
> >>> > // get the PageContext:
> >>> >
> >>> >
> >>> > PageContext ctx = myPipe.getPageContext(data);
> >>> >
> >>> >
> >>> > ...
> >>> >
> >>> >
> >>> > }
> >>> >
> >>> >
> >>> >
> >>> > @Override
> >>> >
> >>> >
> >>> > public void onFailure(Exception e) {
> >>> >
> >>> >
> >>> > }
> >>> > });
> >>> > Not sure about that.....
> >>> >
> >>> > But for iOS I am thinking about passing in the PageContext into
the
> >>> > closure/block of the readWithFilter, like:
> >>> >
> >>> > -(void) readWithFilter:(void (^)(id<AGFilterConfig> config))
config
> >>> >
> >>> >
> >>> > success:(void (^)(id listOfObjects, id pageContext))success
> >>> >
> >>> >
> >>> > failure:(void (^)(NSError *error))failure;
> >>> > A usage would look like:
> >>> >
> >>> > [pipe readWithFilter:^(id<AGFilterConfig> config) {
> >>> >
> >>> >
> >>> > // set the filter args and override the given defaults
> >>> >
> >>> >
> >>> > } success:^(id listOfObjects, id pageContext) {
> >>> >
> >>> >
> >>> > // work with the listOfObjects reponse.
> >>> >
> >>> >
> >>> > // for paging/query info, access the given pagecontext,
> >>> >
> >>> >
> >>> > // of the CURRENT request
> >>> >
> >>> >
> >>> > ...
> >>> >
> >>> >
> >>> > } failure:^(NSError *error) {
> >>> >
> >>> >
> >>> > // handle errorz
> >>> >
> >>> >
> >>> > }];
> >>> > Any thoughts ?
> >>> >
> >>> > Not sure I like (or understand) the Pipe.getPageContext(List
result)
> >>> > call. Current mindset is that thePageContext just (and only)
belongs to the
> >>> > previous (executed) request... Not sure I want to support something
like
> >>> >
> >>> > // first call:
> >>> > List<SomeType> first;
> >>> > myPipe.readWithFilter(.....) // set first inside of callback
> >>> > ...
> >>> > // second call:
> >>> > List<SomeType> second;
> >>> > myPipe.readWithFilter(.....) // set second inside of callback
> >>> > ...
> >>> > // third call:
> >>> > List<SomeType> third;
> >>> > myPipe.readWithFilter(.....) // set third inside of callback
> >>> > ...
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > /// A BIT LATER ....:
> >>> > myPipe.getPageContext(first);
> >>> >
> >>> >
> >>> > I am not sure if that (myPipe.getPageContext(first);) is really
desired
> >>> > (or would even easily work, as it would need to store the
"metadata").....
> >>> >
> >>> >
> >>> > Perhaps I am just wrong.
> >>> >
> >>> >
> >>> > --
> >>> > Matthias Wessendorf
> >>> >
> >>> > blog: http://matthiaswessendorf.wordpress.com/
> >>> > sessions: http://www.slideshare.net/mwessendorf
> >>> > twitter: http://twitter.com/mwessendorf
> >>> > _______________________________________________
> >>> > aerogear-dev mailing list
> >>> > aerogear-dev(a)lists.jboss.org
> >>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>
> >>>
> >>> _______________________________________________
> >>> aerogear-dev mailing list
> >>> aerogear-dev(a)lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >>
> >>
> >> _______________________________________________
> >> aerogear-dev mailing list
> >> aerogear-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > twitter: http://twitter.com/mwessendorf
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
8:38 p.m.
On 15/01/2013, at 17:32, Kris Borchers <kris(a)redhat.com> wrote:
OK, so here is where I stand. I don't think there is any way to
have the API's match identically between JS and the others. It sounds like Android and
iOS are getting closer to agreement but as they get closer, it seems they get further away
from what makes sense for JS. Basically, anything that involves creating a new object to
maintain paged pipes rather than just using any other pipe and overloading the read method
to do paging doesn't make sense to me. IMO, JS should move forward with basically what
was written up in the strawman as that feels like the best solution for JS.
I felt a great disturbance in the Force. (reply is on the way ;))
-- qmx
8:40 p.m.
Basically, anything that involves creating a new object to maintain
paged pipes rather than just using any other pipe and overloading the
read method to do paging doesn't make sense to me.
I'm confused. Your
strawman creates extra pipes to maintain paged
states. The other proposals all use an overridden read method and
return a list which can be used to fetch different pages of data (which
is what it sounds like you want).
On 01/15/2013 02:32 PM, Kris Borchers wrote:
OK, so here is where I stand. I don't think there is any way to
have
the API's match identically between JS and the others. It sounds like
Android and iOS are getting closer to agreement but as they get
closer, it seems they get further away from what makes sense for JS.
Basically, anything that involves creating a new object to maintain
paged pipes rather than just using any other pipe and overloading the
read method to do paging doesn't make sense to me. IMO, JS should move
forward with basically what was written up in the strawman as that
feels like the best solution for JS.
On Jan 15, 2013, at 10:18 AM, Summers Pittman <supittma(a)redhat.com
<mailto:supittma@redhat.com>> wrote:
> On 01/15/2013 08:45 AM, Sebastien Blanc wrote:
>> Just to summarize what have until now :
>>
>> 1. Kris's proposition: https://gist.github.com/4531575
>>
>> 2. Summers's proposition: https://gist.github.com/4532661
>>
>> 3. qmx's propositon: https://gist.github.com/4538709
>>
>> 4. Sebi's propositionhttps://gist.github.com/4538725
>>
>>
> I've just updated my proposition. PageContext is no longer and thing
> and I've replaced it with a PagedList interface.
>>
>>
>> On Tue, Jan 15, 2013 at 2:32 PM, Matthias Wessendorf
>> <matzew(a)apache.org <mailto:matzew@apache.org>> wrote:
>>
>> On Tue, Jan 15, 2013 at 2:25 PM, Matthias Wessendorf
>> <matzew(a)apache.org <mailto:matzew@apache.org>> wrote:
>> > I was wondering, if the result should be received on every rquest,
>>
>>
>> ideally on the callback..., to not block (at least in iOS land, I
>> would pass that "result set" on to the "success" block)
>>
>> -M
>>
>> >
>> > thx
>> >
>> > On Tue, Jan 15, 2013 at 2:01 PM, Sebastien Blanc
>> <scm.blanc(a)gmail.com <mailto:scm.blanc@gmail.com>> wrote:
>> >> In the same spirit (inspired from
>> >>
>>
http://stackoverflow.com/questions/5412059/how-to-implement-general-pagin...)
>> >> :
>> >>
>> >>
>> >> public interface PagedResult<T> {
>> >>
>> >> PagedResult<T> next();
>> >>
>> >> PagedResult<T> prev();
>> >>
>> >> PagedResult<T> withOffset(int offset);
>> >>
>> >> PagedResult<T> withLimit(int limit);
>> >>
>> >> List<T> result();
>> >>
>> >> }
>> >>
>> >>
>> >> On Tue, Jan 15, 2013 at 1:38 PM, Douglas Campos <qmx(a)qmx.me
>> <mailto:qmx@qmx.me>> wrote:
>> >>>
>> >>> I'm not a fan of those PageContext objects (remembers me of
>> some wild-ass
>> >>> ThreadLocals leaking all over)
>> >>>
>> >>> My proposal for the paging aware APIs would be something
>> like this:
>> >>>
>> >>> public interface PagedResult<T> {
>> >>>
>> >>> List<T> next();
>> >>>
>> >>> List<T> prev();
>> >>>
>> >>> List<T> page(int offset, int limit);
>> >>>
>> >>> }
>> >>>
>> >>> and the Async counterpart
>> >>>
>> >>> public interface AsyncPagedResult<T> {
>> >>>
>> >>> void next(Callback<List<T>> callback);
>> >>>
>> >>> void prev(Callback<List<T>> callback);
>> >>>
>> >>> void page(int offset, int limit,
Callback<List<T>>
>> callback);
>> >>>
>> >>> public static interface Callback<U> {
>> >>> public void onResult(U result);
>> >>> }
>> >>> }
>> >>>
>> >>> I don't like the idea of having a companion object for
>> holding the
>> >>> pagination state.
>> >>>
>> >>> Thoughts?
>> >>>
>> >>> -- qmx
>> >>>
>> >>> On 15/01/2013, at 08:37, Matthias Wessendorf
>> <matzew(a)apache.org <mailto:matzew@apache.org>> wrote:
>> >>>
>> >>> > Hi Summers,
>> >>> >
>> >>> >
>> >>> > https://gist.github.com/4532661
>> >>> >
>> >>> > That is a way to do paging which keeps Pipes immutable,
uses
>> >>> > readWithFilter, and doesn't impose any (for convenient
>> definitions of any)
>> >>> > bookkeeping on the developer.
>> >>> >
>> >>> >
>> >>> > from your Andorid gist:
>> >>> >
>> >>> > A) Once the response has been received, the Pipe
>> implementation will
>> >>> > return a List of objects. If this List instance is passed
to
>> >>> > Pipe.getPageContext the appropriate PageContext will be
>> returned
>> >>> >
>> >>> > Note: There is no 'return' - the readWithFilter is
void,
>> instead a
>> >>> > Callback is invoked (onSuccess(list)), see Pipe.java
>> >>> >
>> >>> > B) The developer will receive from readWithFilter() a List
>> of object. If
>> >>> > she passes this list into Pipe.getPageContext(List result)
>> she will receive
>> >>> > the PageContext associated with this result.
>> >>> >
>> >>> > Do you mean like:
>> >>> >
>> >>> > ...
>> >>> > myPipe.readWithFilter(filter, new
Callback<List<Data>>() {
>> >>> >
>> >>> >
>> >>> > @Override
>> >>> >
>> >>> >
>> >>> > public void onSuccess(List<Data> data) {
>> >>> >
>> >>> >
>> >>> >
>> >>> > // get the PageContext:
>> >>> >
>> >>> >
>> >>> > PageContext ctx = myPipe.getPageContext(data);
>> >>> >
>> >>> >
>> >>> > ...
>> >>> >
>> >>> >
>> >>> > }
>> >>> >
>> >>> >
>> >>> >
>> >>> > @Override
>> >>> >
>> >>> >
>> >>> > public void onFailure(Exception e) {
>> >>> >
>> >>> >
>> >>> > }
>> >>> > });
>> >>> > Not sure about that.....
>> >>> >
>> >>> > But for iOS I am thinking about passing in the PageContext
>> into the
>> >>> > closure/block of the readWithFilter, like:
>> >>> >
>> >>> > -(void) readWithFilter:(void (^)(id<AGFilterConfig>
>> config)) config
>> >>> >
>> >>> >
>> >>> > success:(void (^)(id listOfObjects, id
pageContext))success
>> >>> >
>> >>> >
>> >>> > failure:(void (^)(NSError *error))failure;
>> >>> > A usage would look like:
>> >>> >
>> >>> > [pipe readWithFilter:^(id<AGFilterConfig> config)
{
>> >>> >
>> >>> >
>> >>> > // set the filter args and override the given defaults
>> >>> >
>> >>> >
>> >>> > } success:^(id listOfObjects, id pageContext) {
>> >>> >
>> >>> >
>> >>> > // work with the listOfObjects reponse.
>> >>> >
>> >>> >
>> >>> > // for paging/query info, access the given pagecontext,
>> >>> >
>> >>> >
>> >>> > // of the CURRENT request
>> >>> >
>> >>> >
>> >>> > ...
>> >>> >
>> >>> >
>> >>> > } failure:^(NSError *error) {
>> >>> >
>> >>> >
>> >>> > // handle errorz
>> >>> >
>> >>> >
>> >>> > }];
>> >>> > Any thoughts ?
>> >>> >
>> >>> > Not sure I like (or understand) the
>> Pipe.getPageContext(List result)
>> >>> > call. Current mindset is that thePageContext just (and
>> only) belongs to the
>> >>> > previous (executed) request... Not sure I want to support
>> something like
>> >>> >
>> >>> > // first call:
>> >>> > List<SomeType> first;
>> >>> > myPipe.readWithFilter(.....) // set first inside of
callback
>> >>> > ...
>> >>> > // second call:
>> >>> > List<SomeType> second;
>> >>> > myPipe.readWithFilter(.....) // set second inside of
callback
>> >>> > ...
>> >>> > // third call:
>> >>> > List<SomeType> third;
>> >>> > myPipe.readWithFilter(.....) // set third inside of
callback
>> >>> > ...
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> > /// A BIT LATER ....:
>> >>> > myPipe.getPageContext(first);
>> >>> >
>> >>> >
>> >>> > I am not sure if that (myPipe.getPageContext(first);) is
>> really desired
>> >>> > (or would even easily work, as it would need to store the
>> "metadata").....
>> >>> >
>> >>> >
>> >>> > Perhaps I am just wrong.
>> >>> >
>> >>> >
>> >>> > --
>> >>> > Matthias Wessendorf
>> >>> >
>> >>> > blog: http://matthiaswessendorf.wordpress.com/
>> >>> > sessions: http://www.slideshare.net/mwessendorf
>> >>> > twitter: http://twitter.com/mwessendorf
>> >>> > _______________________________________________
>> >>> > aerogear-dev mailing list
>> >>> > aerogear-dev(a)lists.jboss.org
>> <mailto:aerogear-dev@lists.jboss.org>
>> >>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> aerogear-dev mailing list
>> >>> aerogear-dev(a)lists.jboss.org
>> <mailto:aerogear-dev@lists.jboss.org>
>> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> aerogear-dev mailing list
>> >> aerogear-dev(a)lists.jboss.org
>> <mailto:aerogear-dev@lists.jboss.org>
>> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> >>
>> >
>> >
>> >
>> > --
>> > Matthias Wessendorf
>> >
>> > blog: http://matthiaswessendorf.wordpress.com/
>> > sessions: http://www.slideshare.net/mwessendorf
>> > twitter: http://twitter.com/mwessendorf
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
8:51 p.m.
As we wrap the day one of API design discussions, what about summarize the API proposals
with usage?
JS/iOS/Android:
1) usage example, covering some mentioned usecases like changing the paging
"midflight" - something really straight to the point (no fluff, just stuff)
2) API definition
I think this will give the orthogonal view we need to come to a decision.
kris: What about you providing a snippet of the API you hate too? just for comparison sake
:P
-- qmx
8:55 p.m.
On Jan 15, 2013, at 1:40 PM, Summers Pittman <supittma(a)redhat.com> wrote:
> Basically, anything that involves creating a new object to
maintain paged pipes rather than just using any other pipe and overloading the read method
to do paging doesn't make sense to me.
I'm confused. Your strawman creates extra pipes to maintain paged states. The other
proposals all use an overridden read method and return a list which can be used to fetch
different pages of data (which is what it sounds like you want).
Not true. I create a pipe that is paged but it doesn't have to start that way, it was
just a simple example. It can be updated on the fly to be paged or it can start paged and
changed to not be paged as well as updating the offset and limit on the fly. See
https://gist.github.com/4539188 again.
On 01/15/2013 02:32 PM, Kris Borchers wrote:
> OK, so here is where I stand. I don't think there is any way to have the
API's match identically between JS and the others. It sounds like Android and iOS are
getting closer to agreement but as they get closer, it seems they get further away from
what makes sense for JS. Basically, anything that involves creating a new object to
maintain paged pipes rather than just using any other pipe and overloading the read method
to do paging doesn't make sense to me. IMO, JS should move forward with basically what
was written up in the strawman as that feels like the best solution for JS.
>
> On Jan 15, 2013, at 10:18 AM, Summers Pittman <supittma(a)redhat.com> wrote:
>
>> On 01/15/2013 08:45 AM, Sebastien Blanc wrote:
>>> Just to summarize what have until now :
>>>
>>> 1. Kris's proposition: https://gist.github.com/4531575
>>>
>>> 2. Summers's proposition: https://gist.github.com/4532661
>>>
>>> 3. qmx's propositon: https://gist.github.com/4538709
>>>
>>> 4. Sebi's propositionhttps://gist.github.com/4538725
>>>
>>>
>> I've just updated my proposition. PageContext is no longer and thing and
I've replaced it with a PagedList interface.
>>>
>>>
>>> On Tue, Jan 15, 2013 at 2:32 PM, Matthias Wessendorf
<matzew(a)apache.org> wrote:
>>> On Tue, Jan 15, 2013 at 2:25 PM, Matthias Wessendorf
<matzew(a)apache.org> wrote:
>>> > I was wondering, if the result should be received on every rquest,
>>>
>>>
>>> ideally on the callback..., to not block (at least in iOS land, I
>>> would pass that "result set" on to the "success" block)
>>>
>>> -M
>>>
>>> >
>>> > thx
>>> >
>>> > On Tue, Jan 15, 2013 at 2:01 PM, Sebastien Blanc
<scm.blanc(a)gmail.com> wrote:
>>> >> In the same spirit (inspired from
>>> >>
http://stackoverflow.com/questions/5412059/how-to-implement-general-pagin...)
>>> >> :
>>> >>
>>> >>
>>> >> public interface PagedResult<T> {
>>> >>
>>> >> PagedResult<T> next();
>>> >>
>>> >> PagedResult<T> prev();
>>> >>
>>> >> PagedResult<T> withOffset(int offset);
>>> >>
>>> >> PagedResult<T> withLimit(int limit);
>>> >>
>>> >> List<T> result();
>>> >>
>>> >> }
>>> >>
>>> >>
>>> >> On Tue, Jan 15, 2013 at 1:38 PM, Douglas Campos <qmx(a)qmx.me>
wrote:
>>> >>>
>>> >>> I'm not a fan of those PageContext objects (remembers me of
some wild-ass
>>> >>> ThreadLocals leaking all over)
>>> >>>
>>> >>> My proposal for the paging aware APIs would be something like
this:
>>> >>>
>>> >>> public interface PagedResult<T> {
>>> >>>
>>> >>> List<T> next();
>>> >>>
>>> >>> List<T> prev();
>>> >>>
>>> >>> List<T> page(int offset, int limit);
>>> >>>
>>> >>> }
>>> >>>
>>> >>> and the Async counterpart
>>> >>>
>>> >>> public interface AsyncPagedResult<T> {
>>> >>>
>>> >>> void next(Callback<List<T>> callback);
>>> >>>
>>> >>> void prev(Callback<List<T>> callback);
>>> >>>
>>> >>> void page(int offset, int limit,
Callback<List<T>> callback);
>>> >>>
>>> >>> public static interface Callback<U> {
>>> >>> public void onResult(U result);
>>> >>> }
>>> >>> }
>>> >>>
>>> >>> I don't like the idea of having a companion object for
holding the
>>> >>> pagination state.
>>> >>>
>>> >>> Thoughts?
>>> >>>
>>> >>> -- qmx
>>> >>>
>>> >>> On 15/01/2013, at 08:37, Matthias Wessendorf
<matzew(a)apache.org> wrote:
>>> >>>
>>> >>> > Hi Summers,
>>> >>> >
>>> >>> >
>>> >>> > https://gist.github.com/4532661
>>> >>> >
>>> >>> > That is a way to do paging which keeps Pipes immutable,
uses
>>> >>> > readWithFilter, and doesn't impose any (for convenient
definitions of any)
>>> >>> > bookkeeping on the developer.
>>> >>> >
>>> >>> >
>>> >>> > from your Andorid gist:
>>> >>> >
>>> >>> > A) Once the response has been received, the Pipe
implementation will
>>> >>> > return a List of objects. If this List instance is passed
to
>>> >>> > Pipe.getPageContext the appropriate PageContext will be
returned
>>> >>> >
>>> >>> > Note: There is no 'return' - the readWithFilter is
void, instead a
>>> >>> > Callback is invoked (onSuccess(list)), see Pipe.java
>>> >>> >
>>> >>> > B) The developer will receive from readWithFilter() a List
of object. If
>>> >>> > she passes this list into Pipe.getPageContext(List result)
she will receive
>>> >>> > the PageContext associated with this result.
>>> >>> >
>>> >>> > Do you mean like:
>>> >>> >
>>> >>> > ...
>>> >>> > myPipe.readWithFilter(filter, new
Callback<List<Data>>() {
>>> >>> >
>>> >>> >
>>> >>> > @Override
>>> >>> >
>>> >>> >
>>> >>> > public void onSuccess(List<Data> data) {
>>> >>> >
>>> >>> >
>>> >>> >
>>> >>> > // get the PageContext:
>>> >>> >
>>> >>> >
>>> >>> > PageContext ctx = myPipe.getPageContext(data);
>>> >>> >
>>> >>> >
>>> >>> > ...
>>> >>> >
>>> >>> >
>>> >>> > }
>>> >>> >
>>> >>> >
>>> >>> >
>>> >>> > @Override
>>> >>> >
>>> >>> >
>>> >>> > public void onFailure(Exception e) {
>>> >>> >
>>> >>> >
>>> >>> > }
>>> >>> > });
>>> >>> > Not sure about that.....
>>> >>> >
>>> >>> > But for iOS I am thinking about passing in the PageContext
into the
>>> >>> > closure/block of the readWithFilter, like:
>>> >>> >
>>> >>> > -(void) readWithFilter:(void (^)(id<AGFilterConfig>
config)) config
>>> >>> >
>>> >>> >
>>> >>> > success:(void (^)(id listOfObjects, id
pageContext))success
>>> >>> >
>>> >>> >
>>> >>> > failure:(void (^)(NSError *error))failure;
>>> >>> > A usage would look like:
>>> >>> >
>>> >>> > [pipe readWithFilter:^(id<AGFilterConfig> config)
{
>>> >>> >
>>> >>> >
>>> >>> > // set the filter args and override the given defaults
>>> >>> >
>>> >>> >
>>> >>> > } success:^(id listOfObjects, id pageContext) {
>>> >>> >
>>> >>> >
>>> >>> > // work with the listOfObjects reponse.
>>> >>> >
>>> >>> >
>>> >>> > // for paging/query info, access the given pagecontext,
>>> >>> >
>>> >>> >
>>> >>> > // of the CURRENT request
>>> >>> >
>>> >>> >
>>> >>> > ...
>>> >>> >
>>> >>> >
>>> >>> > } failure:^(NSError *error) {
>>> >>> >
>>> >>> >
>>> >>> > // handle errorz
>>> >>> >
>>> >>> >
>>> >>> > }];
>>> >>> > Any thoughts ?
>>> >>> >
>>> >>> > Not sure I like (or understand) the
Pipe.getPageContext(List result)
>>> >>> > call. Current mindset is that thePageContext just (and
only) belongs to the
>>> >>> > previous (executed) request... Not sure I want to support
something like
>>> >>> >
>>> >>> > // first call:
>>> >>> > List<SomeType> first;
>>> >>> > myPipe.readWithFilter(.....) // set first inside of
callback
>>> >>> > ...
>>> >>> > // second call:
>>> >>> > List<SomeType> second;
>>> >>> > myPipe.readWithFilter(.....) // set second inside of
callback
>>> >>> > ...
>>> >>> > // third call:
>>> >>> > List<SomeType> third;
>>> >>> > myPipe.readWithFilter(.....) // set third inside of
callback
>>> >>> > ...
>>> >>> >
>>> >>> >
>>> >>> >
>>> >>> >
>>> >>> > /// A BIT LATER ....:
>>> >>> > myPipe.getPageContext(first);
>>> >>> >
>>> >>> >
>>> >>> > I am not sure if that (myPipe.getPageContext(first);) is
really desired
>>> >>> > (or would even easily work, as it would need to store the
"metadata").....
>>> >>> >
>>> >>> >
>>> >>> > Perhaps I am just wrong.
>>> >>> >
>>> >>> >
>>> >>> > --
>>> >>> > Matthias Wessendorf
>>> >>> >
>>> >>> > blog: http://matthiaswessendorf.wordpress.com/
>>> >>> > sessions: http://www.slideshare.net/mwessendorf
>>> >>> > twitter: http://twitter.com/mwessendorf
>>> >>> > _______________________________________________
>>> >>> > aerogear-dev mailing list
>>> >>> > aerogear-dev(a)lists.jboss.org
>>> >>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> >>>
>>> >>>
>>> >>> _______________________________________________
>>> >>> aerogear-dev mailing list
>>> >>> aerogear-dev(a)lists.jboss.org
>>> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> >>
>>> >>
>>> >>
>>> >> _______________________________________________
>>> >> aerogear-dev mailing list
>>> >> aerogear-dev(a)lists.jboss.org
>>> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Matthias Wessendorf
>>> >
>>> > blog: http://matthiaswessendorf.wordpress.com/
>>> > sessions: http://www.slideshare.net/mwessendorf
>>> > twitter: http://twitter.com/mwessendorf
>>>
>>>
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> sessions: http://www.slideshare.net/mwessendorf
>>> twitter: http://twitter.com/mwessendorf
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
8:59 p.m.
On 15/01/2013, at 17:40, Summers Pittman <supittma(a)redhat.com> wrote:
> Basically, anything that involves creating a new object to
maintain paged pipes rather than just using any other pipe and overloading the read method
to do paging doesn't make sense to me.
I'm confused. Your strawman creates extra pipes to maintain paged states. The other
proposals all use an overridden read method and return a list which can be used to fetch
different pages of data (which is what it sounds like you want).
This is where things get tricky for our java-rotted minds - everything is mutable in JS,
and Kris is (ab)using this on his API freely :P
-- qmx
9:01 p.m.
Just to make it clear, I meant **side to side** comparisons of the APIs ;)
On 15/01/2013, at 17:51, Douglas Campos <qmx(a)qmx.me> wrote:
As we wrap the day one of API design discussions, what about
summarize the API proposals with usage?
JS/iOS/Android:
1) usage example, covering some mentioned usecases like changing the paging
"midflight" - something really straight to the point (no fluff, just stuff)
2) API definition
I think this will give the orthogonal view we need to come to a decision.
kris: What about you providing a snippet of the API you hate too? just for comparison
sake :P
-- qmx
9:03 p.m.
I'm sure that we can find an arrangement. I understand Kris's concerns on
some points but not always sure that we are all on the same page. I will
try to write a snippet in JS that tries to conciliates both worlds. Will
may be be tomorrow ...
Seb
On Tue, Jan 15, 2013 at 8:59 PM, Douglas Campos <qmx(a)qmx.me> wrote:
On 15/01/2013, at 17:40, Summers Pittman <supittma(a)redhat.com> wrote:
>> Basically, anything that involves creating a new object to maintain
paged pipes rather than just using any other pipe and overloading the read
method to do paging doesn't make sense to me.
> I'm confused. Your strawman creates extra pipes to maintain paged
states. The other proposals all use an overridden read method and return a
list which can be used to fetch different pages of data (which is what it
sounds like you want).
This is where things get tricky for our java-rotted minds - everything is
mutable in JS, and Kris is (ab)using this on his API freely :P
-- qmx
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
9:50 p.m.
On Jan 15, 2013, at 1:51 PM, Douglas Campos <qmx(a)qmx.me> wrote:
As we wrap the day one of API design discussions, what about
summarize the API proposals with usage?
JS/iOS/Android:
1) usage example, covering some mentioned usecases like changing the paging
"midflight" - something really straight to the point (no fluff, just stuff)
OK, hopefully this can get us going on #1 https://gist.github.com/4541788
2) API definition
I think this will give the orthogonal view we need to come to a decision.
kris: What about you providing a snippet of the API you hate too? just for comparison
sake :P
-- qmx
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
9:59 p.m.
For Read all Records
cars.updatePageConfig({
paged: false
});
cars.read({
success: function( data ) {
// do something
},
error: function() {
// handle it
}
});
I think we also want the ability to get all the records with a flag in the read method,
without changing the pipe.
I think that may have been in your original proposal.
On Jan 15, 2013, at 3:50 PM, Kris Borchers <kris(a)redhat.com> wrote:
On Jan 15, 2013, at 1:51 PM, Douglas Campos <qmx(a)qmx.me> wrote:
> As we wrap the day one of API design discussions, what about summarize the API
proposals with usage?
>
> JS/iOS/Android:
>
> 1) usage example, covering some mentioned usecases like changing the paging
"midflight" - something really straight to the point (no fluff, just stuff)
OK, hopefully this can get us going on #1 https://gist.github.com/4541788
>
> 2) API definition
>
> I think this will give the orthogonal view we need to come to a decision.
>
> kris: What about you providing a snippet of the API you hate too? just for comparison
sake :P
>
> -- qmx
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
10:02 p.m.
Yep will update.
On Jan 15, 2013, at 2:59 PM, Lucas Holmquist <lholmqui(a)redhat.com> wrote:
For Read all Records
cars.updatePageConfig({
paged: false
});
cars.read({
success: function( data ) {
// do something
},
error: function() {
// handle it
}
});
I think we also want the ability to get all the records with a flag in the read method,
without changing the pipe.
I think that may have been in your original proposal.
On Jan 15, 2013, at 3:50 PM, Kris Borchers <kris(a)redhat.com> wrote:
>
> On Jan 15, 2013, at 1:51 PM, Douglas Campos <qmx(a)qmx.me> wrote:
>
>> As we wrap the day one of API design discussions, what about summarize the API
proposals with usage?
>>
>> JS/iOS/Android:
>>
>> 1) usage example, covering some mentioned usecases like changing the paging
"midflight" - something really straight to the point (no fluff, just stuff)
>
> OK, hopefully this can get us going on #1 https://gist.github.com/4541788
>>
>> 2) API definition
>>
>> I think this will give the orthogonal view we need to come to a decision.
>>
>> kris: What about you providing a snippet of the API you hate too? just for
comparison sake :P
>>
>> -- qmx
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
10:39 p.m.
I'm thinking about dropping the blocking next(), prev(), etc. methods
from the proposal and only keeping the callback driven methods.
WDYT?
On 01/15/2013 11:18 AM, Summers Pittman wrote:
On 01/15/2013 08:45 AM, Sebastien Blanc wrote:
> Just to summarize what have until now :
>
> 1. Kris's proposition: https://gist.github.com/4531575
>
> 2. Summers's proposition: https://gist.github.com/4532661
>
> 3. qmx's propositon: https://gist.github.com/4538709
>
> 4. Sebi's propositionhttps://gist.github.com/4538725
>
>
I've just updated my proposition. PageContext is no longer and thing
and I've replaced it with a PagedList interface.
>
>
> On Tue, Jan 15, 2013 at 2:32 PM, Matthias Wessendorf
> <matzew(a)apache.org <mailto:matzew@apache.org>> wrote:
>
> On Tue, Jan 15, 2013 at 2:25 PM, Matthias Wessendorf
> <matzew(a)apache.org <mailto:matzew@apache.org>> wrote:
> > I was wondering, if the result should be received on every rquest,
>
>
> ideally on the callback..., to not block (at least in iOS land, I
> would pass that "result set" on to the "success" block)
>
> -M
>
> >
> > thx
> >
> > On Tue, Jan 15, 2013 at 2:01 PM, Sebastien Blanc
> <scm.blanc(a)gmail.com <mailto:scm.blanc@gmail.com>> wrote:
> >> In the same spirit (inspired from
> >>
> http://stackoverflow.com/questions/5412059/how-to-implement-general-pagin...)
> >> :
> >>
> >>
> >> public interface PagedResult<T> {
> >>
> >> PagedResult<T> next();
> >>
> >> PagedResult<T> prev();
> >>
> >> PagedResult<T> withOffset(int offset);
> >>
> >> PagedResult<T> withLimit(int limit);
> >>
> >> List<T> result();
> >>
> >> }
> >>
> >>
> >> On Tue, Jan 15, 2013 at 1:38 PM, Douglas Campos <qmx(a)qmx.me
> <mailto:qmx@qmx.me>> wrote:
> >>>
> >>> I'm not a fan of those PageContext objects (remembers me of
> some wild-ass
> >>> ThreadLocals leaking all over)
> >>>
> >>> My proposal for the paging aware APIs would be something like
> this:
> >>>
> >>> public interface PagedResult<T> {
> >>>
> >>> List<T> next();
> >>>
> >>> List<T> prev();
> >>>
> >>> List<T> page(int offset, int limit);
> >>>
> >>> }
> >>>
> >>> and the Async counterpart
> >>>
> >>> public interface AsyncPagedResult<T> {
> >>>
> >>> void next(Callback<List<T>> callback);
> >>>
> >>> void prev(Callback<List<T>> callback);
> >>>
> >>> void page(int offset, int limit, Callback<List<T>>
callback);
> >>>
> >>> public static interface Callback<U> {
> >>> public void onResult(U result);
> >>> }
> >>> }
> >>>
> >>> I don't like the idea of having a companion object for
> holding the
> >>> pagination state.
> >>>
> >>> Thoughts?
> >>>
> >>> -- qmx
> >>>
> >>> On 15/01/2013, at 08:37, Matthias Wessendorf
> <matzew(a)apache.org <mailto:matzew@apache.org>> wrote:
> >>>
> >>> > Hi Summers,
> >>> >
> >>> >
> >>> > https://gist.github.com/4532661
> >>> >
> >>> > That is a way to do paging which keeps Pipes immutable, uses
> >>> > readWithFilter, and doesn't impose any (for convenient
> definitions of any)
> >>> > bookkeeping on the developer.
> >>> >
> >>> >
> >>> > from your Andorid gist:
> >>> >
> >>> > A) Once the response has been received, the Pipe
> implementation will
> >>> > return a List of objects. If this List instance is passed to
> >>> > Pipe.getPageContext the appropriate PageContext will be
> returned
> >>> >
> >>> > Note: There is no 'return' - the readWithFilter is
void,
> instead a
> >>> > Callback is invoked (onSuccess(list)), see Pipe.java
> >>> >
> >>> > B) The developer will receive from readWithFilter() a List
> of object. If
> >>> > she passes this list into Pipe.getPageContext(List result)
> she will receive
> >>> > the PageContext associated with this result.
> >>> >
> >>> > Do you mean like:
> >>> >
> >>> > ...
> >>> > myPipe.readWithFilter(filter, new
Callback<List<Data>>() {
> >>> >
> >>> >
> >>> > @Override
> >>> >
> >>> >
> >>> > public void onSuccess(List<Data> data) {
> >>> >
> >>> >
> >>> >
> >>> > // get the PageContext:
> >>> >
> >>> >
> >>> > PageContext ctx = myPipe.getPageContext(data);
> >>> >
> >>> >
> >>> > ...
> >>> >
> >>> >
> >>> > }
> >>> >
> >>> >
> >>> >
> >>> > @Override
> >>> >
> >>> >
> >>> > public void onFailure(Exception e) {
> >>> >
> >>> >
> >>> > }
> >>> > });
> >>> > Not sure about that.....
> >>> >
> >>> > But for iOS I am thinking about passing in the PageContext
> into the
> >>> > closure/block of the readWithFilter, like:
> >>> >
> >>> > -(void) readWithFilter:(void (^)(id<AGFilterConfig>
> config)) config
> >>> >
> >>> >
> >>> > success:(void (^)(id listOfObjects, id pageContext))success
> >>> >
> >>> >
> >>> > failure:(void (^)(NSError *error))failure;
> >>> > A usage would look like:
> >>> >
> >>> > [pipe readWithFilter:^(id<AGFilterConfig> config) {
> >>> >
> >>> >
> >>> > // set the filter args and override the given defaults
> >>> >
> >>> >
> >>> > } success:^(id listOfObjects, id pageContext) {
> >>> >
> >>> >
> >>> > // work with the listOfObjects reponse.
> >>> >
> >>> >
> >>> > // for paging/query info, access the given pagecontext,
> >>> >
> >>> >
> >>> > // of the CURRENT request
> >>> >
> >>> >
> >>> > ...
> >>> >
> >>> >
> >>> > } failure:^(NSError *error) {
> >>> >
> >>> >
> >>> > // handle errorz
> >>> >
> >>> >
> >>> > }];
> >>> > Any thoughts ?
> >>> >
> >>> > Not sure I like (or understand) the
> Pipe.getPageContext(List result)
> >>> > call. Current mindset is that thePageContext just (and
> only) belongs to the
> >>> > previous (executed) request... Not sure I want to support
> something like
> >>> >
> >>> > // first call:
> >>> > List<SomeType> first;
> >>> > myPipe.readWithFilter(.....) // set first inside of callback
> >>> > ...
> >>> > // second call:
> >>> > List<SomeType> second;
> >>> > myPipe.readWithFilter(.....) // set second inside of callback
> >>> > ...
> >>> > // third call:
> >>> > List<SomeType> third;
> >>> > myPipe.readWithFilter(.....) // set third inside of callback
> >>> > ...
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > /// A BIT LATER ....:
> >>> > myPipe.getPageContext(first);
> >>> >
> >>> >
> >>> > I am not sure if that (myPipe.getPageContext(first);) is
> really desired
> >>> > (or would even easily work, as it would need to store the
> "metadata").....
> >>> >
> >>> >
> >>> > Perhaps I am just wrong.
> >>> >
> >>> >
> >>> > --
> >>> > Matthias Wessendorf
> >>> >
> >>> > blog: http://matthiaswessendorf.wordpress.com/
> >>> > sessions: http://www.slideshare.net/mwessendorf
> >>> > twitter: http://twitter.com/mwessendorf
> >>> > _______________________________________________
> >>> > aerogear-dev mailing list
> >>> > aerogear-dev(a)lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> >>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>
> >>>
> >>> _______________________________________________
> >>> aerogear-dev mailing list
> >>> aerogear-dev(a)lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >>
> >>
> >> _______________________________________________
> >> aerogear-dev mailing list
> >> aerogear-dev(a)lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>
> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > twitter: http://twitter.com/mwessendorf
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
10:54 p.m.
On 15/01/2013, at 19:39, Summers Pittman <supittma(a)redhat.com> wrote:
I'm thinking about dropping the blocking next(), prev(), etc. methods from the
proposal and only keeping the callback driven methods.
WDYT?
Nah, it was only me showing the next() prev() methods on the API, kill'em all
-- qmx
11 p.m.
On 01/15/2013 02:51 PM, Douglas Campos wrote:
As we wrap the day one of API design discussions, what about
summarize the API proposals with usage?
JS/iOS/Android:
1) usage example, covering some mentioned usecases like changing the paging
"midflight" - something really straight to the point (no fluff, just stuff)
I forked Kris's gist and added android stuff using my proposal (sans
blocking methods)
https://gist.github.com/4542125
I went for pedantic in a couple of examples...
2) API definition
I think this will give the orthogonal view we need to come to a decision.
kris: What about you providing a snippet of the API you hate too? just for comparison
sake :P
-- qmx
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
11:12 p.m.
On Tue, Jan 15, 2013 at 10:39 PM, Summers Pittman <supittma(a)redhat.com> wrote:
I'm thinking about dropping the blocking next(), prev(), etc. methods from
the proposal and only keeping the callback driven methods.
I never liked the blocking ones - and the current pipe is callback
driven as well,
so +1 for only that and removing the blocking aspect
-M
WDYT?
On 01/15/2013 11:18 AM, Summers Pittman wrote:
On 01/15/2013 08:45 AM, Sebastien Blanc wrote:
Just to summarize what have until now :
1. Kris's proposition: https://gist.github.com/4531575
2. Summers's proposition: https://gist.github.com/4532661
3. qmx's propositon: https://gist.github.com/4538709
4. Sebi's propositionhttps://gist.github.com/4538725
I've just updated my proposition. PageContext is no longer and thing and
I've replaced it with a PagedList interface.
On Tue, Jan 15, 2013 at 2:32 PM, Matthias Wessendorf <matzew(a)apache.org>
wrote:
>
> On Tue, Jan 15, 2013 at 2:25 PM, Matthias Wessendorf <matzew(a)apache.org>
> wrote:
> > I was wondering, if the result should be received on every rquest,
>
>
> ideally on the callback..., to not block (at least in iOS land, I
> would pass that "result set" on to the "success" block)
>
> -M
>
> >
> > thx
> >
> > On Tue, Jan 15, 2013 at 2:01 PM, Sebastien Blanc <scm.blanc(a)gmail.com>
> > wrote:
> >> In the same spirit (inspired from
> >>
> >>
http://stackoverflow.com/questions/5412059/how-to-implement-general-pagin...)
> >> :
> >>
> >>
> >> public interface PagedResult<T> {
> >>
> >> PagedResult<T> next();
> >>
> >> PagedResult<T> prev();
> >>
> >> PagedResult<T> withOffset(int offset);
> >>
> >> PagedResult<T> withLimit(int limit);
> >>
> >> List<T> result();
> >>
> >> }
> >>
> >>
> >> On Tue, Jan 15, 2013 at 1:38 PM, Douglas Campos <qmx(a)qmx.me> wrote:
> >>>
> >>> I'm not a fan of those PageContext objects (remembers me of some
> >>> wild-ass
> >>> ThreadLocals leaking all over)
> >>>
> >>> My proposal for the paging aware APIs would be something like this:
> >>>
> >>> public interface PagedResult<T> {
> >>>
> >>> List<T> next();
> >>>
> >>> List<T> prev();
> >>>
> >>> List<T> page(int offset, int limit);
> >>>
> >>> }
> >>>
> >>> and the Async counterpart
> >>>
> >>> public interface AsyncPagedResult<T> {
> >>>
> >>> void next(Callback<List<T>> callback);
> >>>
> >>> void prev(Callback<List<T>> callback);
> >>>
> >>> void page(int offset, int limit, Callback<List<T>>
callback);
> >>>
> >>> public static interface Callback<U> {
> >>> public void onResult(U result);
> >>> }
> >>> }
> >>>
> >>> I don't like the idea of having a companion object for holding the
> >>> pagination state.
> >>>
> >>> Thoughts?
> >>>
> >>> -- qmx
> >>>
> >>> On 15/01/2013, at 08:37, Matthias Wessendorf <matzew(a)apache.org>
> >>> wrote:
> >>>
> >>> > Hi Summers,
> >>> >
> >>> >
> >>> > https://gist.github.com/4532661
> >>> >
> >>> > That is a way to do paging which keeps Pipes immutable, uses
> >>> > readWithFilter, and doesn't impose any (for convenient
definitions
> >>> > of any)
> >>> > bookkeeping on the developer.
> >>> >
> >>> >
> >>> > from your Andorid gist:
> >>> >
> >>> > A) Once the response has been received, the Pipe implementation
will
> >>> > return a List of objects. If this List instance is passed to
> >>> > Pipe.getPageContext the appropriate PageContext will be returned
> >>> >
> >>> > Note: There is no 'return' - the readWithFilter is void,
instead a
> >>> > Callback is invoked (onSuccess(list)), see Pipe.java
> >>> >
> >>> > B) The developer will receive from readWithFilter() a List of
> >>> > object. If
> >>> > she passes this list into Pipe.getPageContext(List result) she
will
> >>> > receive
> >>> > the PageContext associated with this result.
> >>> >
> >>> > Do you mean like:
> >>> >
> >>> > ...
> >>> > myPipe.readWithFilter(filter, new
Callback<List<Data>>() {
> >>> >
> >>> >
> >>> > @Override
> >>> >
> >>> >
> >>> > public void onSuccess(List<Data> data) {
> >>> >
> >>> >
> >>> >
> >>> > // get the PageContext:
> >>> >
> >>> >
> >>> > PageContext ctx = myPipe.getPageContext(data);
> >>> >
> >>> >
> >>> > ...
> >>> >
> >>> >
> >>> > }
> >>> >
> >>> >
> >>> >
> >>> > @Override
> >>> >
> >>> >
> >>> > public void onFailure(Exception e) {
> >>> >
> >>> >
> >>> > }
> >>> > });
> >>> > Not sure about that.....
> >>> >
> >>> > But for iOS I am thinking about passing in the PageContext into
the
> >>> > closure/block of the readWithFilter, like:
> >>> >
> >>> > -(void) readWithFilter:(void (^)(id<AGFilterConfig> config))
config
> >>> >
> >>> >
> >>> > success:(void (^)(id listOfObjects, id pageContext))success
> >>> >
> >>> >
> >>> > failure:(void (^)(NSError *error))failure;
> >>> > A usage would look like:
> >>> >
> >>> > [pipe readWithFilter:^(id<AGFilterConfig> config) {
> >>> >
> >>> >
> >>> > // set the filter args and override the given defaults
> >>> >
> >>> >
> >>> > } success:^(id listOfObjects, id pageContext) {
> >>> >
> >>> >
> >>> > // work with the listOfObjects reponse.
> >>> >
> >>> >
> >>> > // for paging/query info, access the given pagecontext,
> >>> >
> >>> >
> >>> > // of the CURRENT request
> >>> >
> >>> >
> >>> > ...
> >>> >
> >>> >
> >>> > } failure:^(NSError *error) {
> >>> >
> >>> >
> >>> > // handle errorz
> >>> >
> >>> >
> >>> > }];
> >>> > Any thoughts ?
> >>> >
> >>> > Not sure I like (or understand) the Pipe.getPageContext(List
result)
> >>> > call. Current mindset is that thePageContext just (and only)
belongs
> >>> > to the
> >>> > previous (executed) request... Not sure I want to support
something
> >>> > like
> >>> >
> >>> > // first call:
> >>> > List<SomeType> first;
> >>> > myPipe.readWithFilter(.....) // set first inside of callback
> >>> > ...
> >>> > // second call:
> >>> > List<SomeType> second;
> >>> > myPipe.readWithFilter(.....) // set second inside of callback
> >>> > ...
> >>> > // third call:
> >>> > List<SomeType> third;
> >>> > myPipe.readWithFilter(.....) // set third inside of callback
> >>> > ...
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > /// A BIT LATER ....:
> >>> > myPipe.getPageContext(first);
> >>> >
> >>> >
> >>> > I am not sure if that (myPipe.getPageContext(first);) is really
> >>> > desired
> >>> > (or would even easily work, as it would need to store the
> >>> > "metadata").....
> >>> >
> >>> >
> >>> > Perhaps I am just wrong.
> >>> >
> >>> >
> >>> > --
> >>> > Matthias Wessendorf
> >>> >
> >>> > blog: http://matthiaswessendorf.wordpress.com/
> >>> > sessions: http://www.slideshare.net/mwessendorf
> >>> > twitter: http://twitter.com/mwessendorf
> >>> > _______________________________________________
> >>> > aerogear-dev mailing list
> >>> > aerogear-dev(a)lists.jboss.org
> >>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>
> >>>
> >>> _______________________________________________
> >>> aerogear-dev mailing list
> >>> aerogear-dev(a)lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >>
> >>
> >> _______________________________________________
> >> aerogear-dev mailing list
> >> aerogear-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > twitter: http://twitter.com/mwessendorf
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
11:25 p.m.
On 01/15/2013 03:50 PM, Kris Borchers wrote:
On Jan 15, 2013, at 1:51 PM, Douglas Campos <qmx(a)qmx.me
<mailto:qmx@qmx.me>> wrote:
> As we wrap the day one of API design discussions, what about
> summarize the API proposals with usage?
>
> JS/iOS/Android:
>
> 1) usage example, covering some mentioned usecases like changing the
> paging "midflight" - something really straight to the point (no
> fluff, just stuff)
OK, hopefully this can get us going on #1 https://gist.github.com/4541788
I've
forked and added mine (Android proposal sans blocking methods)
https://gist.github.com/4542125
I went for pedantic in a couple of examples...
>
> 2) API definition
>
> I think this will give the orthogonal view we need to come to a decision.
>
> kris: What about you providing a snippet of the API you hate too?
> just for comparison sake :P
>
> -- qmx
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
11:30 p.m.
On 15/01/2013, at 20:25, Summers Pittman <supittma(a)redhat.com> wrote:
I've forked and added mine (Android proposal sans blocking
methods)
https://gist.github.com/4542125
I went for pedantic in a couple of examples…
The pedantic part is making this code unreadable - can you get rid of all the latches and
atomic stuff? (no fluff, just stuff)
-- qmx
11:33 p.m.
On 01/15/2013 05:30 PM, Douglas Campos wrote:
On 15/01/2013, at 20:25, Summers Pittman <supittma(a)redhat.com>
wrote:
> I've forked and added mine (Android proposal sans blocking methods)
> https://gist.github.com/4542125
>
> I went for pedantic in a couple of examples…
The pedantic part is making this code unreadable - can you get rid of all the latches and
atomic stuff? (no fluff, just stuff)
Ok, gave it a shot.
-- qmx
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
9:25 a.m.
I already asked this question but didn't really get the answer, why can't
we overload the read() method, readWithFilter(ReadFilter filter, Callback)
?
For the rest, +1 , nice comparison gist, make it a lot clearer.
cars.readWithFilter(filter, new Callback<Car>() {
@Override
void onSuccess(List<Car> data) {
firstPage = data;
}
@Override
void onError(Exception ex) {
//handle error
}});
On Tue, Jan 15, 2013 at 11:00 PM, Summers Pittman <supittma(a)redhat.com>wrote:
On 01/15/2013 02:51 PM, Douglas Campos wrote:
As we wrap the day one of API design discussions, what about summarize the API proposals
with usage?
JS/iOS/Android:
1) usage example, covering some mentioned usecases like changing the paging
"midflight" - something really straight to the point (no fluff, just stuff)
I forked Kris's gist and added android stuff using my proposal (sans
blocking methods)
https://gist.github.com/4542125
I went for pedantic in a couple of examples...
2) API definition
I think this will give the orthogonal view we need to come to a decision.
kris: What about you providing a snippet of the API you hate too? just for comparison
sake :P
-- qmx
_______________________________________________
aerogear-dev mailing
listaerogear-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
10:41 a.m.
On Tue, Jan 15, 2013 at 4:06 PM, Summers Pittman <supittma(a)redhat.com> wrote:
On 01/15/2013 06:17 AM, Sebastien Blanc wrote:
Hi,
Some aditional remarks on Summers gist :
Instead of :
Pipe.readWithFilter(ReadFilter)
Couldn't we just overload the read() method ? i.e :
read(ReadFilter filter)
We can depending on how it interacts with the other implementations of the
library.
Not sure what you mean?
IMO (perhaps I am wrong).,
But wouldn't it be a bit more natural for Java, to really just
overload the read() ?
void read(Callback<List<T>> callback);
void read(ReadFilter filter, Callback<List<T>> callback);
the 'bogus' readWithFilter comes from an iOS / ObjC limitation, I guess
we have already one func. that has "three arguments"
-read:success:failure (usage: [pipe read:MyID success:block
failure:otherBlock];)
So.. I can't really do an overload there.
-Matthias
About the where property in ReadFilter class :
Do we really want to mix paging and querying ?
We do and we don't. The request itself requires both of these properties so
it makes technical sense to pass them in a single wrapper. I agree it makes
more logical sense to keep them as two separate object which you can pass
independently.
About Pipe.getPageContext(List result):
Same remarks as Matthias, not sure to understand how it works (even if I
think I've understand ...)
In Java it's back by a WeakHashMap. Lots of Java specific implementation
magic makes it very easy. As I've said otherwise I'm not in love with the
method but it scratches an itch.
General remarks about Paging:
Even if it's not in scope for 1.0, I think we have to keep in mind that we
will also be able to do pagination "offline" / "only client side"
(maybe we
would do some paging on a Store element ?) , so we have to consider this
when designing our API.
I've been thinking about that as well. The Stores we have right now don't
lend themselves to paging very well because they don't have a concept of
order built in.
Seb
On Tue, Jan 15, 2013 at 11:37 AM, Matthias Wessendorf <matzew(a)apache.org>
wrote:
>
> https://gist.github.com/4532661
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
12:46 p.m.
Hello,
a few quick/simple q's:
<https://gist.github.com/2d75e480500c69993227#javascript>JavaScript
One question on the two gists...
Kris' gist <https://gist.github.com/4539188> uses pipe.next() of scrolling
forward, Summer's comparison gist <https://gist.github.com/4542125> uses
pipe.read(page:"next") for the JS.
I think I do like the 'plain' read overload in JS... - but having a more
explicit next() (and others) is not that bad; but (currently) my vote would
be pipe.read(page:"prev"......
Oh... What happens when I have a *regular* pipe, object (where the
paged setting
is NOT specified on its ctor), and I invoke pipe.read(page:"next") ? I hope
it does not issue a JS/type error :-) but I'd expect to have a straight
read of ALL the "objects" (or "entities")...
<https://gist.github.com/2d75e480500c69993227#android>Android
You have the following:
cars.readWithFilter(filter, new Callback<Car>() {
@Override
void onSuccess(List<Car> data) {
firstPage = data;
}
@Override
void onError(Exception ex) {
//handle error
}
});
firstPage.next(.......);
I am wondering what is the fristPage here (since the data on the onSuccess has
been assigned to it)
<https://gist.github.com/2d75e480500c69993227#change-offset-and-limit>C...
Offset and Limit
I like both (JS and Android) :) The Android solution is similar to what I
had in mind for iOS <https://gist.github.com/cbff741b3b21a50c3b67>...
I will update the comparison gist soon !
-Matthias
On Tue, Jan 15, 2013 at 11:00 PM, Summers Pittman <supittma(a)redhat.com>wrote:
On 01/15/2013 02:51 PM, Douglas Campos wrote:
As we wrap the day one of API design discussions, what about summarize the API proposals
with usage?
JS/iOS/Android:
1) usage example, covering some mentioned usecases like changing the paging
"midflight" - something really straight to the point (no fluff, just stuff)
I forked Kris's gist and added android stuff using my proposal (sans
blocking methods)
https://gist.github.com/4542125
I went for pedantic in a couple of examples...
2) API definition
I think this will give the orthogonal view we need to come to a decision.
kris: What about you providing a snippet of the API you hate too? just for comparison
sake :P
-- qmx
_______________________________________________
aerogear-dev mailing
listaerogear-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
1:19 p.m.
Howdy!
I have forked the gist and added the (current) iOS proposal to it:
https://gist.github.com/4546737
-M
On Wed, Jan 16, 2013 at 12:46 PM, Matthias Wessendorf <matzew(a)apache.org> wrote:
Hello,
a few quick/simple q's:
JavaScript
One question on the two gists...
Kris' gist uses pipe.next() of scrolling forward, Summer's comparison gist
uses pipe.read(page:"next") for the JS.
I think I do like the 'plain' read overload in JS... - but having a more
explicit next() (and others) is not that bad; but (currently) my vote would
be pipe.read(page:"prev"......
Oh... What happens when I have a regular pipe, object (where the paged
setting is NOT specified on its ctor), and I invoke pipe.read(page:"next") ?
I hope it does not issue a JS/type error :-) but I'd expect to have a
straight read of ALL the "objects" (or "entities")...
Android
You have the following:
cars.readWithFilter(filter, new Callback<Car>() {
@Override
void onSuccess(List<Car> data) {
firstPage = data;
}
@Override
void onError(Exception ex) {
//handle error
}
});
firstPage.next(.......);
I am wondering what is the fristPage here (since the data on the onSuccess
has been assigned to it)
Change Offset and Limit
I like both (JS and Android) :) The Android solution is similar to what I
had in mind for iOS...
I will update the comparison gist soon !
-Matthias
On Tue, Jan 15, 2013 at 11:00 PM, Summers Pittman <supittma(a)redhat.com>
wrote:
>
> On 01/15/2013 02:51 PM, Douglas Campos wrote:
>
> As we wrap the day one of API design discussions, what about summarize the
> API proposals with usage?
>
> JS/iOS/Android:
>
> 1) usage example, covering some mentioned usecases like changing the
> paging "midflight" - something really straight to the point (no fluff,
just
> stuff)
>
> I forked Kris's gist and added android stuff using my proposal (sans
> blocking methods)
> https://gist.github.com/4542125
>
> I went for pedantic in a couple of examples...
>
>
> 2) API definition
>
> I think this will give the orthogonal view we need to come to a decision.
>
> kris: What about you providing a snippet of the API you hate too? just for
> comparison sake :P
>
> -- qmx
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
1:38 p.m.
Some new questions :
*JavaScript*
*
*
cars.updatePageConfig({
offset: 2,
limit: 10});
can we also shortcut this way ?
cars.read({
page: "prev",
pageConfig: {
offset: 2,
limit: 10
},
success: function( data ) {
// do something
},
error: function() {
// handle it
}});
Another alternative : What about removing the "page" attribute and include
a "action" attribute inside a "paging" block ? If paging block
isn't
present we implicitly know we don't want paging :
cars.read({
paging: {
action: "prev", //can be "next"
offset: 2, //optional
limit: 10 //optional
},
success: function( data ) {
// do something
},
error: function() {
// handle it
}});
*General remark *
Do we want to describe in the specs the following use cases ?
- Calling previous on the first page
- Calling next on the last page
- Setting an offset > total number of pages
On Wed, Jan 16, 2013 at 1:19 PM, Matthias Wessendorf <matzew(a)apache.org>wrote:
Howdy!
I have forked the gist and added the (current) iOS proposal to it:
https://gist.github.com/4546737
-M
On Wed, Jan 16, 2013 at 12:46 PM, Matthias Wessendorf <matzew(a)apache.org>
wrote:
> Hello,
>
> a few quick/simple q's:
>
> JavaScript
>
> One question on the two gists...
>
> Kris' gist uses pipe.next() of scrolling forward, Summer's comparison
gist
> uses pipe.read(page:"next") for the JS.
>
> I think I do like the 'plain' read overload in JS... - but having a more
> explicit next() (and others) is not that bad; but (currently) my vote
would
> be pipe.read(page:"prev"......
>
> Oh... What happens when I have a regular pipe, object (where the paged
> setting is NOT specified on its ctor), and I invoke
pipe.read(page:"next") ?
> I hope it does not issue a JS/type error :-) but I'd expect to have a
> straight read of ALL the "objects" (or "entities")...
>
> Android
>
> You have the following:
>
> cars.readWithFilter(filter, new Callback<Car>() {
> @Override
> void onSuccess(List<Car> data) {
> firstPage = data;
> }
>
> @Override
> void onError(Exception ex) {
> //handle error
> }
> });
>
>
> firstPage.next(.......);
>
> I am wondering what is the fristPage here (since the data on the
onSuccess
> has been assigned to it)
>
> Change Offset and Limit
>
> I like both (JS and Android) :) The Android solution is similar to what I
> had in mind for iOS...
>
> I will update the comparison gist soon !
>
> -Matthias
>
>
>
>
>
> On Tue, Jan 15, 2013 at 11:00 PM, Summers Pittman <supittma(a)redhat.com>
> wrote:
>>
>> On 01/15/2013 02:51 PM, Douglas Campos wrote:
>>
>> As we wrap the day one of API design discussions, what about summarize
the
>> API proposals with usage?
>>
>> JS/iOS/Android:
>>
>> 1) usage example, covering some mentioned usecases like changing the
>> paging "midflight" - something really straight to the point (no
fluff,
just
>> stuff)
>>
>> I forked Kris's gist and added android stuff using my proposal (sans
>> blocking methods)
>> https://gist.github.com/4542125
>>
>> I went for pedantic in a couple of examples...
>>
>>
>> 2) API definition
>>
>> I think this will give the orthogonal view we need to come to a
decision.
>>
>> kris: What about you providing a snippet of the API you hate too? just
for
>> comparison sake :P
>>
>> -- qmx
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
1:46 p.m.
Another alternative : What about removing the "page" attribute and include
a "action" attribute inside a "paging" block ? If
paging block isn't
present we implicitly know we don't want paging :
cars.read({
paging: {
action: "prev", //can be "next"
offset: 2, //optional
limit: 10 //optional
},
success: function( data ) {
// do something
},
error: function() {
// handle it
}});
But the 'updatePageConfig' would be still around ?
If I "touch" (update) the limit/offset, it is globally stored, and reused,
right ?
I always have to provide a paging block, at least like this, right ?
==> cars.read({
paging: {
action: "prev", //can be "next"
},...........;
BTW. action sounds Struts :)
*General remark *
Do we want to describe in the specs the following use cases ?
- Calling previous on the first page
- Calling next on the last page
- Setting an offset > total number of pages
yeah - would be (more than) nice if that behavior is specified....
On Wed, Jan 16, 2013 at 1:19 PM, Matthias Wessendorf <matzew(a)apache.org>wrote:
> Howdy!
>
> I have forked the gist and added the (current) iOS proposal to it:
> https://gist.github.com/4546737
>
> -M
>
> On Wed, Jan 16, 2013 at 12:46 PM, Matthias Wessendorf <matzew(a)apache.org>
> wrote:
> > Hello,
> >
> > a few quick/simple q's:
> >
> > JavaScript
> >
> > One question on the two gists...
> >
> > Kris' gist uses pipe.next() of scrolling forward, Summer's comparison
> gist
> > uses pipe.read(page:"next") for the JS.
> >
> > I think I do like the 'plain' read overload in JS... - but having a
more
> > explicit next() (and others) is not that bad; but (currently) my vote
> would
> > be pipe.read(page:"prev"......
> >
> > Oh... What happens when I have a regular pipe, object (where the paged
> > setting is NOT specified on its ctor), and I invoke
> pipe.read(page:"next") ?
> > I hope it does not issue a JS/type error :-) but I'd expect to have a
> > straight read of ALL the "objects" (or "entities")...
> >
> > Android
> >
> > You have the following:
> >
> > cars.readWithFilter(filter, new Callback<Car>() {
> > @Override
> > void onSuccess(List<Car> data) {
> > firstPage = data;
> > }
> >
> > @Override
> > void onError(Exception ex) {
> > //handle error
> > }
> > });
> >
> >
> > firstPage.next(.......);
> >
> > I am wondering what is the fristPage here (since the data on the
> onSuccess
> > has been assigned to it)
> >
> > Change Offset and Limit
> >
> > I like both (JS and Android) :) The Android solution is similar to what
> I
> > had in mind for iOS...
> >
> > I will update the comparison gist soon !
> >
> > -Matthias
> >
> >
> >
> >
> >
> > On Tue, Jan 15, 2013 at 11:00 PM, Summers Pittman <supittma(a)redhat.com>
> > wrote:
> >>
> >> On 01/15/2013 02:51 PM, Douglas Campos wrote:
> >>
> >> As we wrap the day one of API design discussions, what about summarize
> the
> >> API proposals with usage?
> >>
> >> JS/iOS/Android:
> >>
> >> 1) usage example, covering some mentioned usecases like changing the
> >> paging "midflight" - something really straight to the point (no
fluff,
> just
> >> stuff)
> >>
> >> I forked Kris's gist and added android stuff using my proposal (sans
> >> blocking methods)
> >> https://gist.github.com/4542125
> >>
> >> I went for pedantic in a couple of examples...
> >>
> >>
> >> 2) API definition
> >>
> >> I think this will give the orthogonal view we need to come to a
> decision.
> >>
> >> kris: What about you providing a snippet of the API you hate too? just
> for
> >> comparison sake :P
> >>
> >> -- qmx
> >> _______________________________________________
> >> aerogear-dev mailing list
> >> aerogear-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >>
> >>
> >> _______________________________________________
> >> aerogear-dev mailing list
> >> aerogear-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > twitter: http://twitter.com/mwessendorf
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
2:08 p.m.
On Jan 16, 2013, at 5:46 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
Hello,
a few quick/simple q's:
JavaScript
One question on the two gists...
Kris' gist uses pipe.next() of scrolling forward, Summer's comparison gist uses
pipe.read(page:"next") for the JS.
Actually, my comparison gist that Summers forked uses
pipe.read({page:"next"}); I very much prefer that and only had next() prev()
methods in my other gists to be in line with the methods the other libraries were
providing. If it were up to me, they wouldn't exist in JS.
I think I do like the 'plain' read overload in JS... - but
having a more explicit next() (and others) is not that bad; but (currently) my vote would
be pipe.read(page:"prev"......
+1 for just overloading read()
Oh... What happens when I have a regular pipe, object (where the
paged setting is NOT specified on its ctor), and I invoke pipe.read(page:"next")
? I hope it does not issue a JS/type error :-) but I'd expect to have a straight read
of ALL the "objects" (or "entities")...
Yes, IMO, all records should be returned in that case and it would just be treated
as a "plain" read()
Android
You have the following:
cars.readWithFilter(filter, new Callback<Car>() {
@Override
void onSuccess(List<Car> data) {
firstPage = data;
}
@Override
void onError(Exception ex) {
//handle error
}
});
firstPage.next(.......);
I am wondering what is the fristPage here (since the data on the onSuccess has been
assigned to it)
Change Offset and Limit
I like both (JS and Android) :) The Android solution is similar to what I had in mind for
iOS...
I will update the comparison gist soon !
-Matthias
On Tue, Jan 15, 2013 at 11:00 PM, Summers Pittman <supittma(a)redhat.com> wrote:
On 01/15/2013 02:51 PM, Douglas Campos wrote:
> As we wrap the day one of API design discussions, what about summarize the API
proposals with usage?
>
> JS/iOS/Android:
>
> 1) usage example, covering some mentioned usecases like changing the paging
"midflight" - something really straight to the point (no fluff, just stuff)
I forked Kris's gist and added android stuff using my proposal (sans blocking
methods)
https://gist.github.com/4542125
I went for pedantic in a couple of examples...
> 2) API definition
>
> I think this will give the orthogonal view we need to come to a decision.
>
> kris: What about you providing a snippet of the API you hate too? just for comparison
sake :P
>
> -- qmx
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf _______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
2:24 p.m.
On Jan 16, 2013, at 6:38 AM, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
Some new questions :
JavaScript
cars.updatePageConfig({
offset: 2,
limit: 10
});
can we also shortcut this way ?
cars.read({
page: "prev",
pageConfig: {
offset: 2,
limit: 10
},
success: function( data ) {
// do something
},
error: function() {
// handle it
}
});
Another alternative : What about removing the "page" attribute and include a
"action" attribute inside a "paging" block ? If paging block isn't
present we implicitly know we don't want paging :
cars.read({
paging: {
action: "prev", //can be "next"
offset: 2, //optional
limit: 10 //optional
},
success: function( data ) {
// do something
},
error: function() {
// handle it
}
});
I think I like this idea but I have a concern. Would this permanently change the
paging context or is this just a temporary change for a single read? I think it could be
useful to have have this for doing things like jumping to a particular page, but I think
it would be confusing if it didn't change that "global" page context. IMO, I
think it would be better to only modify offset and limit in the updatePageConfig method
and only allow a shortcut to turn paging off via read({page: false}); Any other opinions
on that?
General remark
Do we want to describe in the specs the following use cases ?
- Calling previous on the first page
- Calling next on the last page
- Setting an offset > total number of pages
On Wed, Jan 16, 2013 at 1:19 PM, Matthias Wessendorf <matzew(a)apache.org> wrote:
Howdy!
I have forked the gist and added the (current) iOS proposal to it:
https://gist.github.com/4546737
-M
On Wed, Jan 16, 2013 at 12:46 PM, Matthias Wessendorf <matzew(a)apache.org> wrote:
> Hello,
>
> a few quick/simple q's:
>
> JavaScript
>
> One question on the two gists...
>
> Kris' gist uses pipe.next() of scrolling forward, Summer's comparison gist
> uses pipe.read(page:"next") for the JS.
>
> I think I do like the 'plain' read overload in JS... - but having a more
> explicit next() (and others) is not that bad; but (currently) my vote would
> be pipe.read(page:"prev"......
>
> Oh... What happens when I have a regular pipe, object (where the paged
> setting is NOT specified on its ctor), and I invoke pipe.read(page:"next")
?
> I hope it does not issue a JS/type error :-) but I'd expect to have a
> straight read of ALL the "objects" (or "entities")...
>
> Android
>
> You have the following:
>
> cars.readWithFilter(filter, new Callback<Car>() {
> @Override
> void onSuccess(List<Car> data) {
> firstPage = data;
> }
>
> @Override
> void onError(Exception ex) {
> //handle error
> }
> });
>
>
> firstPage.next(.......);
>
> I am wondering what is the fristPage here (since the data on the onSuccess
> has been assigned to it)
>
> Change Offset and Limit
>
> I like both (JS and Android) :) The Android solution is similar to what I
> had in mind for iOS...
>
> I will update the comparison gist soon !
>
> -Matthias
>
>
>
>
>
> On Tue, Jan 15, 2013 at 11:00 PM, Summers Pittman <supittma(a)redhat.com>
> wrote:
>>
>> On 01/15/2013 02:51 PM, Douglas Campos wrote:
>>
>> As we wrap the day one of API design discussions, what about summarize the
>> API proposals with usage?
>>
>> JS/iOS/Android:
>>
>> 1) usage example, covering some mentioned usecases like changing the
>> paging "midflight" - something really straight to the point (no fluff,
just
>> stuff)
>>
>> I forked Kris's gist and added android stuff using my proposal (sans
>> blocking methods)
>> https://gist.github.com/4542125
>>
>> I went for pedantic in a couple of examples...
>>
>>
>> 2) API definition
>>
>> I think this will give the orthogonal view we need to come to a decision.
>>
>> kris: What about you providing a snippet of the API you hate too? just for
>> comparison sake :P
>>
>> -- qmx
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
2:24 p.m.
On Jan 16, 2013, at 6:46 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
Another alternative : What about removing the "page" attribute and include a
"action" attribute inside a "paging" block ? If paging block isn't
present we implicitly know we don't want paging :
cars.read({
paging: {
action: "prev", //can be "next"
offset: 2, //optional
limit: 10 //optional
},
success: function( data ) {
// do something
},
error: function() {
// handle it
}
});
But the 'updatePageConfig' would be still around ?
If I "touch" (update) the limit/offset, it is globally stored, and reused,
right ?
I always have to provide a paging block, at least like this, right ?
==> cars.read({
paging: {
action: "prev", //can be "next"
},...........;
BTW. action sounds Struts :)
General remark
Do we want to describe in the specs the following use cases ?
- Calling previous on the first page
- Calling next on the last page
- Setting an offset > total number of pages
yeah - would be (more than) nice if that behavior is specified….
+1 Anyone want to start putting together a specs doc?
On Wed, Jan 16, 2013 at 1:19 PM, Matthias Wessendorf <matzew(a)apache.org> wrote:
Howdy!
I have forked the gist and added the (current) iOS proposal to it:
https://gist.github.com/4546737
-M
On Wed, Jan 16, 2013 at 12:46 PM, Matthias Wessendorf <matzew(a)apache.org> wrote:
> Hello,
>
> a few quick/simple q's:
>
> JavaScript
>
> One question on the two gists...
>
> Kris' gist uses pipe.next() of scrolling forward, Summer's comparison gist
> uses pipe.read(page:"next") for the JS.
>
> I think I do like the 'plain' read overload in JS... - but having a more
> explicit next() (and others) is not that bad; but (currently) my vote would
> be pipe.read(page:"prev"......
>
> Oh... What happens when I have a regular pipe, object (where the paged
> setting is NOT specified on its ctor), and I invoke pipe.read(page:"next")
?
> I hope it does not issue a JS/type error :-) but I'd expect to have a
> straight read of ALL the "objects" (or "entities")...
>
> Android
>
> You have the following:
>
> cars.readWithFilter(filter, new Callback<Car>() {
> @Override
> void onSuccess(List<Car> data) {
> firstPage = data;
> }
>
> @Override
> void onError(Exception ex) {
> //handle error
> }
> });
>
>
> firstPage.next(.......);
>
> I am wondering what is the fristPage here (since the data on the onSuccess
> has been assigned to it)
>
> Change Offset and Limit
>
> I like both (JS and Android) :) The Android solution is similar to what I
> had in mind for iOS...
>
> I will update the comparison gist soon !
>
> -Matthias
>
>
>
>
>
> On Tue, Jan 15, 2013 at 11:00 PM, Summers Pittman <supittma(a)redhat.com>
> wrote:
>>
>> On 01/15/2013 02:51 PM, Douglas Campos wrote:
>>
>> As we wrap the day one of API design discussions, what about summarize the
>> API proposals with usage?
>>
>> JS/iOS/Android:
>>
>> 1) usage example, covering some mentioned usecases like changing the
>> paging "midflight" - something really straight to the point (no fluff,
just
>> stuff)
>>
>> I forked Kris's gist and added android stuff using my proposal (sans
>> blocking methods)
>> https://gist.github.com/4542125
>>
>> I went for pedantic in a couple of examples...
>>
>>
>> 2) API definition
>>
>> I think this will give the orthogonal view we need to come to a decision.
>>
>> kris: What about you providing a snippet of the API you hate too? just for
>> comparison sake :P
>>
>> -- qmx
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf _______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
2:43 p.m.
On Wed, Jan 16, 2013 at 2:24 PM, Kris Borchers <kris(a)redhat.com> wrote:
On Jan 16, 2013, at 6:46 AM, Matthias Wessendorf <matzew(a)apache.org>
wrote:
Another alternative : What about removing the "page" attribute and include
> a "action" attribute inside a "paging" block ? If paging block
isn't
> present we implicitly know we don't want paging :
>
> cars.read({
> paging: {
> action: "prev", //can be "next"
> offset: 2, //optional
> limit: 10 //optional
>
> },
> success: function( data ) {
> // do something
> },
> error: function() {
> // handle it
> }});
>
>
>
But the 'updatePageConfig' would be still around ?
If I "touch" (update) the limit/offset, it is globally stored, and reused,
right ?
I always have to provide a paging block, at least like this, right ?
==> cars.read({
paging: {
action: "prev", //can be "next"
},...........;
BTW. action sounds Struts :)
> *General remark *
> Do we want to describe in the specs the following use cases ?
>
> - Calling previous on the first page
> - Calling next on the last page
> - Setting an offset > total number of pages
>
yeah - would be (more than) nice if that behavior is specified….
+1 Anyone want to start putting together a specs doc?
Before starting the specs doc, let's first discuss here what for behaviour
we want for these specific use cases :
When prev / next does not exist :
- throwing an exception ?
- returning null ?
- returning the current page ?
For offset > totalNbPages :
- throwing an exception ?
- returning null ?
- returning last page ?
>
>
> On Wed, Jan 16, 2013 at 1:19 PM, Matthias Wessendorf <matzew(a)apache.org>wrote:
>
>> Howdy!
>>
>> I have forked the gist and added the (current) iOS proposal to it:
>> https://gist.github.com/4546737
>>
>> -M
>>
>> On Wed, Jan 16, 2013 at 12:46 PM, Matthias Wessendorf <matzew(a)apache.org>
>> wrote:
>> > Hello,
>> >
>> > a few quick/simple q's:
>> >
>> > JavaScript
>> >
>> > One question on the two gists...
>> >
>> > Kris' gist uses pipe.next() of scrolling forward, Summer's
comparison
>> gist
>> > uses pipe.read(page:"next") for the JS.
>> >
>> > I think I do like the 'plain' read overload in JS... - but having a
>> more
>> > explicit next() (and others) is not that bad; but (currently) my vote
>> would
>> > be pipe.read(page:"prev"......
>> >
>> > Oh... What happens when I have a regular pipe, object (where the paged
>> > setting is NOT specified on its ctor), and I invoke
>> pipe.read(page:"next") ?
>> > I hope it does not issue a JS/type error :-) but I'd expect to have a
>> > straight read of ALL the "objects" (or "entities")...
>> >
>> > Android
>> >
>> > You have the following:
>> >
>> > cars.readWithFilter(filter, new Callback<Car>() {
>> > @Override
>> > void onSuccess(List<Car> data) {
>> > firstPage = data;
>> > }
>> >
>> > @Override
>> > void onError(Exception ex) {
>> > //handle error
>> > }
>> > });
>> >
>> >
>> > firstPage.next(.......);
>> >
>> > I am wondering what is the fristPage here (since the data on the
>> onSuccess
>> > has been assigned to it)
>> >
>> > Change Offset and Limit
>> >
>> > I like both (JS and Android) :) The Android solution is similar to
>> what I
>> > had in mind for iOS...
>> >
>> > I will update the comparison gist soon !
>> >
>> > -Matthias
>> >
>> >
>> >
>> >
>> >
>> > On Tue, Jan 15, 2013 at 11:00 PM, Summers Pittman <supittma(a)redhat.com
>> >
>> > wrote:
>> >>
>> >> On 01/15/2013 02:51 PM, Douglas Campos wrote:
>> >>
>> >> As we wrap the day one of API design discussions, what about
>> summarize the
>> >> API proposals with usage?
>> >>
>> >> JS/iOS/Android:
>> >>
>> >> 1) usage example, covering some mentioned usecases like changing the
>> >> paging "midflight" - something really straight to the point
(no
>> fluff, just
>> >> stuff)
>> >>
>> >> I forked Kris's gist and added android stuff using my proposal
(sans
>> >> blocking methods)
>> >> https://gist.github.com/4542125
>> >>
>> >> I went for pedantic in a couple of examples...
>> >>
>> >>
>> >> 2) API definition
>> >>
>> >> I think this will give the orthogonal view we need to come to a
>> decision.
>> >>
>> >> kris: What about you providing a snippet of the API you hate too?
>> just for
>> >> comparison sake :P
>> >>
>> >> -- qmx
>> >> _______________________________________________
>> >> aerogear-dev mailing list
>> >> aerogear-dev(a)lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> aerogear-dev mailing list
>> >> aerogear-dev(a)lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> >>
>> >
>> >
>> >
>> > --
>> > Matthias Wessendorf
>> >
>> > blog: http://matthiaswessendorf.wordpress.com/
>> > sessions: http://www.slideshare.net/mwessendorf
>> > twitter: http://twitter.com/mwessendorf
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf___________________________________________...
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
2:48 p.m.
On Jan 16, 2013, at 7:43 AM, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
On Wed, Jan 16, 2013 at 2:24 PM, Kris Borchers
<kris(a)redhat.com> wrote:
On Jan 16, 2013, at 6:46 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
>
>
> Another alternative : What about removing the "page" attribute and include
a "action" attribute inside a "paging" block ? If paging block
isn't present we implicitly know we don't want paging :
>
> cars.read({
> paging: {
> action: "prev", //can be "next"
> offset: 2, //optional
> limit: 10 //optional
>
> },
> success: function( data ) {
> // do something
> },
> error: function() {
> // handle it
> }
> });
>
>
>
> But the 'updatePageConfig' would be still around ?
>
> If I "touch" (update) the limit/offset, it is globally stored, and reused,
right ?
>
> I always have to provide a paging block, at least like this, right ?
> ==> cars.read({
> paging: {
> action: "prev", //can be "next"
> },...........;
>
>
> BTW. action sounds Struts :)
>
>
>
> General remark
> Do we want to describe in the specs the following use cases ?
>
> - Calling previous on the first page
> - Calling next on the last page
> - Setting an offset > total number of pages
>
>
> yeah - would be (more than) nice if that behavior is specified….
+1 Anyone want to start putting together a specs doc?
Before starting the specs doc, let's first discuss here what for behaviour we want
for these specific use cases :
When prev / next does not exist :
- throwing an exception ?
- returning null ?
- returning the current page ?
I would say returning the current page would be confusing. I would be fine with an
exception or returning null as both can be handled pretty easily by a dev. I would say an
exception may be more useful since it will tell the dev exactly what was wrong instead of
their app choking in a null return but I am open to both.
For offset > totalNbPages :
- throwing an exception ?
- returning null ?
- returning last page ?
I would say same as above. Returning last page may be confusing but others are acceptable
with a preference toward an exception.
>
>
>
>
> On Wed, Jan 16, 2013 at 1:19 PM, Matthias Wessendorf <matzew(a)apache.org>
wrote:
> Howdy!
>
> I have forked the gist and added the (current) iOS proposal to it:
> https://gist.github.com/4546737
>
> -M
>
> On Wed, Jan 16, 2013 at 12:46 PM, Matthias Wessendorf <matzew(a)apache.org>
wrote:
> > Hello,
> >
> > a few quick/simple q's:
> >
> > JavaScript
> >
> > One question on the two gists...
> >
> > Kris' gist uses pipe.next() of scrolling forward, Summer's comparison
gist
> > uses pipe.read(page:"next") for the JS.
> >
> > I think I do like the 'plain' read overload in JS... - but having a
more
> > explicit next() (and others) is not that bad; but (currently) my vote would
> > be pipe.read(page:"prev"......
> >
> > Oh... What happens when I have a regular pipe, object (where the paged
> > setting is NOT specified on its ctor), and I invoke
pipe.read(page:"next") ?
> > I hope it does not issue a JS/type error :-) but I'd expect to have a
> > straight read of ALL the "objects" (or "entities")...
> >
> > Android
> >
> > You have the following:
> >
> > cars.readWithFilter(filter, new Callback<Car>() {
> > @Override
> > void onSuccess(List<Car> data) {
> > firstPage = data;
> > }
> >
> > @Override
> > void onError(Exception ex) {
> > //handle error
> > }
> > });
> >
> >
> > firstPage.next(.......);
> >
> > I am wondering what is the fristPage here (since the data on the onSuccess
> > has been assigned to it)
> >
> > Change Offset and Limit
> >
> > I like both (JS and Android) :) The Android solution is similar to what I
> > had in mind for iOS...
> >
> > I will update the comparison gist soon !
> >
> > -Matthias
> >
> >
> >
> >
> >
> > On Tue, Jan 15, 2013 at 11:00 PM, Summers Pittman <supittma(a)redhat.com>
> > wrote:
> >>
> >> On 01/15/2013 02:51 PM, Douglas Campos wrote:
> >>
> >> As we wrap the day one of API design discussions, what about summarize the
> >> API proposals with usage?
> >>
> >> JS/iOS/Android:
> >>
> >> 1) usage example, covering some mentioned usecases like changing the
> >> paging "midflight" - something really straight to the point (no
fluff, just
> >> stuff)
> >>
> >> I forked Kris's gist and added android stuff using my proposal (sans
> >> blocking methods)
> >> https://gist.github.com/4542125
> >>
> >> I went for pedantic in a couple of examples...
> >>
> >>
> >> 2) API definition
> >>
> >> I think this will give the orthogonal view we need to come to a decision.
> >>
> >> kris: What about you providing a snippet of the API you hate too? just for
> >> comparison sake :P
> >>
> >> -- qmx
> >> _______________________________________________
> >> aerogear-dev mailing list
> >> aerogear-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >>
> >>
> >> _______________________________________________
> >> aerogear-dev mailing list
> >> aerogear-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > twitter: http://twitter.com/mwessendorf
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
_______________________________________________
>
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
2:52 p.m.
On Wed, Jan 16, 2013 at 2:48 PM, Kris Borchers <kris(a)redhat.com> wrote:
I would say returning the current page would be confusing. I would be
fine
with an exception or returning null as both can be handled pretty easily by
a dev. I would say an exception may be more useful since it will tell the
dev exactly what was wrong instead of their app choking in a null return
but I am open to both.
For offset > totalNbPages :
- throwing an exception ?
- returning null ?
- returning last page ?
I would say same as above. Returning last page may be confusing but others
are acceptable with a preference toward an exception.
+1 on an exception
-M
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
2:58 p.m.
If the data doesn't exist HTTP 204 is a good fit. Just don't understand why we
need to interrupt the app workflow, because the data doesn't exist.
--
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile
On Wednesday, January 16, 2013 at 11:52 AM, Matthias Wessendorf wrote:
On Wed, Jan 16, 2013 at 2:48 PM, Kris Borchers <kris(a)redhat.com
(mailto:kris@redhat.com)> wrote:
> I would say returning the current page would be confusing. I would be fine with an
exception or returning null as both can be handled pretty easily by a dev. I would say an
exception may be more useful since it will tell the dev exactly what was wrong instead of
their app choking in a null return but I am open to both.
>
> >
> > For offset > totalNbPages :
> > - throwing an exception ?
> > - returning null ?
> > - returning last page ?
>
>
>
> I would say same as above. Returning last page may be confusing but others are
acceptable with a preference toward an exception.
+1 on an exception
-M
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org (mailto:aerogear-dev@lists.jboss.org)
https://lists.jboss.org/mailman/listinfo/aerogear-dev
3:01 p.m.
On Jan 16, 2013, at 7:58 AM, Bruno Oliveira <bruno(a)abstractj.org> wrote:
If the data doesn't exist HTTP 204 is a good fit. Just don't
understand why we need to interrupt the app workflow, because the data doesn't exist.
I would prefer that an exception is thrown client side before a request is ever sent to
the server. That way we save the http request which is important on mobile.
That being said, then the issue becomes what if that page does exist but we don't
allow the request because the data was updated since our last read? Then we wouldn't
know without another read happening.
Hmmm, interested in other opinions since relying on a 204 or any status from the server
couples the client to the server impl but if we don't allow the request, that could
also cause issues.
--
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile
On Wednesday, January 16, 2013 at 11:52 AM, Matthias Wessendorf wrote:
>
> On Wed, Jan 16, 2013 at 2:48 PM, Kris Borchers <kris(a)redhat.com
(mailto:kris@redhat.com)> wrote:
>> I would say returning the current page would be confusing. I would be fine with
an exception or returning null as both can be handled pretty easily by a dev. I would say
an exception may be more useful since it will tell the dev exactly what was wrong instead
of their app choking in a null return but I am open to both.
>>
>>>
>>> For offset > totalNbPages :
>>> - throwing an exception ?
>>> - returning null ?
>>> - returning last page ?
>>
>>
>>
>> I would say same as above. Returning last page may be confusing but others are
acceptable with a preference toward an exception.
>
>
> +1 on an exception
>
> -M
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org (mailto:aerogear-dev@lists.jboss.org)
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
3:13 p.m.
I agreed on not interrupt the workflow (although if exception are meant to
be handelt in order to maintain the flow under some conditions).
HTTP 204 is a good option but is maybe more an impl details ? Because, in
the future, when we will have offline/native paging, http status won't make
a lot of sense, no ?
On Wed, Jan 16, 2013 at 2:58 PM, Bruno Oliveira <bruno(a)abstractj.org> wrote:
If the data doesn't exist HTTP 204 is a good fit. Just don't
understand
why we need to interrupt the app workflow, because the data doesn't exist.
--
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile
On Wednesday, January 16, 2013 at 11:52 AM, Matthias Wessendorf wrote:
>
> On Wed, Jan 16, 2013 at 2:48 PM, Kris Borchers <kris(a)redhat.com (mailto:
kris(a)redhat.com)> wrote:
> > I would say returning the current page would be confusing. I would be
fine with an exception or returning null as both can be handled pretty
easily by a dev. I would say an exception may be more useful since it will
tell the dev exactly what was wrong instead of their app choking in a null
return but I am open to both.
> >
> > >
> > > For offset > totalNbPages :
> > > - throwing an exception ?
> > > - returning null ?
> > > - returning last page ?
> >
> >
> >
> > I would say same as above. Returning last page may be confusing but
others are acceptable with a preference toward an exception.
>
>
> +1 on an exception
>
> -M
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org (mailto:aerogear-dev@lists.jboss.org)
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
3:15 p.m.
Once it affects 3 projects, I would go with impl details ;)
--
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile
On Wednesday, January 16, 2013 at 12:13 PM, Sebastien Blanc wrote:
HTTP 204 is a good option but is maybe more an impl details ?
3:16 p.m.
On Wed, Jan 16, 2013 at 2:58 PM, Bruno Oliveira <bruno(a)abstractj.org> wrote:
If the data doesn't exist HTTP 204 is a good fit. Just don't
understand
why we need to interrupt the app workflow, because the data doesn't exist.
Interesting idea, but I am not sure… if we want to "expose" the 204… since
the idea of a pipe was/is to encapsulate some of the underlying bits.
--
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile
On Wednesday, January 16, 2013 at 11:52 AM, Matthias Wessendorf wrote:
>
> On Wed, Jan 16, 2013 at 2:48 PM, Kris Borchers <kris(a)redhat.com (mailto:
kris(a)redhat.com)> wrote:
> > I would say returning the current page would be confusing. I would be
fine with an exception or returning null as both can be handled pretty
easily by a dev. I would say an exception may be more useful since it will
tell the dev exactly what was wrong instead of their app choking in a null
return but I am open to both.
> >
> > >
> > > For offset > totalNbPages :
> > > - throwing an exception ?
> > > - returning null ?
> > > - returning last page ?
> >
> >
> >
> > I would say same as above. Returning last page may be confusing but
others are acceptable with a preference toward an exception.
>
>
> +1 on an exception
>
> -M
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org (mailto:aerogear-dev@lists.jboss.org)
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
3:17 p.m.
HTTP 204 - Server response
No data - client API
--
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile
On Wednesday, January 16, 2013 at 12:16 PM, Matthias Wessendorf wrote:
On Wed, Jan 16, 2013 at 2:58 PM, Bruno Oliveira <bruno(a)abstractj.org
(mailto:bruno@abstractj.org)> wrote:
> If the data doesn't exist HTTP 204 is a good fit. Just don't understand why
we need to interrupt the app workflow, because the data doesn't exist.
Interesting idea, but I am not sure… if we want to "expose" the 204… since the
idea of a pipe was/is to encapsulate some of the underlying bits.
>
>
> --
> "The measure of a man is what he does with power" - Plato
> -
> @abstractj
> -
> Volenti Nihil Difficile
>
>
>
> On Wednesday, January 16, 2013 at 11:52 AM, Matthias Wessendorf wrote:
>
> >
> > On Wed, Jan 16, 2013 at 2:48 PM, Kris Borchers <kris(a)redhat.com
(mailto:kris@redhat.com) (mailto:kris@redhat.com)> wrote:
> > > I would say returning the current page would be confusing. I would be fine
with an exception or returning null as both can be handled pretty easily by a dev. I would
say an exception may be more useful since it will tell the dev exactly what was wrong
instead of their app choking in a null return but I am open to both.
> > >
> > > >
> > > > For offset > totalNbPages :
> > > > - throwing an exception ?
> > > > - returning null ?
> > > > - returning last page ?
> > >
> > >
> > >
> > >
> > > I would say same as above. Returning last page may be confusing but others
are acceptable with a preference toward an exception.
> >
> >
> > +1 on an exception
> >
> > -M
> >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > twitter: http://twitter.com/mwessendorf
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev(a)lists.jboss.org (mailto:aerogear-dev@lists.jboss.org)
(mailto:aerogear-dev@lists.jboss.org)
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org (mailto:aerogear-dev@lists.jboss.org)
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org (mailto:aerogear-dev@lists.jboss.org)
https://lists.jboss.org/mailman/listinfo/aerogear-dev
3:18 p.m.
On Wed, Jan 16, 2013 at 3:13 PM, Sebastien Blanc <scm.blanc(a)gmail.com>wrote:
I agreed on not interrupt the workflow (although if exception are
meant to
be handelt in order to maintain the flow under some conditions).
HTTP 204 is a good option but is maybe more an impl details ? Because, in
the future, when we will have offline/native paging, http status won't make
a lot of sense, no ?
well, the server (for pipe based paging) would sent the 204 - I like that
idea. The client would use that, to "indicate" -> no data
(it COULD throw an execption (or invoke the failure callback (Android/iOS).
Offline, yeah - 204 makes no sense there, but the underlying storage would
indicate differently, there is no "previous", and the "offline
paging"
could trhow an exception (or invoke a failure callback)
-M
On Wed, Jan 16, 2013 at 2:58 PM, Bruno Oliveira <bruno(a)abstractj.org>wrote:
> If the data doesn't exist HTTP 204 is a good fit. Just don't understand
> why we need to interrupt the app workflow, because the data doesn't exist.
>
>
> --
> "The measure of a man is what he does with power" - Plato
> -
> @abstractj
> -
> Volenti Nihil Difficile
>
>
>
> On Wednesday, January 16, 2013 at 11:52 AM, Matthias Wessendorf wrote:
>
> >
> > On Wed, Jan 16, 2013 at 2:48 PM, Kris Borchers <kris(a)redhat.com(mailto:
> kris(a)redhat.com)> wrote:
> > > I would say returning the current page would be confusing. I would be
> fine with an exception or returning null as both can be handled pretty
> easily by a dev. I would say an exception may be more useful since it will
> tell the dev exactly what was wrong instead of their app choking in a null
> return but I am open to both.
> > >
> > > >
> > > > For offset > totalNbPages :
> > > > - throwing an exception ?
> > > > - returning null ?
> > > > - returning last page ?
> > >
> > >
> > >
> > > I would say same as above. Returning last page may be confusing but
> others are acceptable with a preference toward an exception.
> >
> >
> > +1 on an exception
> >
> > -M
> >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > twitter: http://twitter.com/mwessendorf
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev(a)lists.jboss.org (mailto:aerogear-dev@lists.jboss.org)
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
3:21 p.m.
On Wed, Jan 16, 2013 at 3:01 PM, Kris Borchers <kris(a)redhat.com> wrote:
On Jan 16, 2013, at 7:58 AM, Bruno Oliveira <bruno(a)abstractj.org> wrote:
If the data doesn't exist HTTP 204 is a good fit. Just don't understand
why we need to interrupt the app workflow, because the data doesn't exist.
I would prefer that an exception is thrown client side before a request is
ever sent to the server. That way we save the http request which is
important on mobile.
Ah! yeah - good point -> since the "paging API" knows there is no
"next"
(for instance)
That being said, then the issue becomes what if that page does exist but
we don't allow the request because the data was updated since our last
read? Then we wouldn't know without another read happening.
yeah - here could the 2.x targeted feature of 'sync' come in...
Hmmm, interested in other opinions since relying on a 204 or any status
from the server couples the client to the server impl but if we don't allow
the request, that could also cause issues.
true :)
--
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile
On Wednesday, January 16, 2013 at 11:52 AM, Matthias Wessendorf wrote:
On Wed, Jan 16, 2013 at 2:48 PM, Kris Borchers <kris(a)redhat.com (
mailto:kris@redhat.com <kris(a)redhat.com>)> wrote:
I would say returning the current page would be confusing. I would be fine
with an exception or returning null as both can be handled pretty easily by
a dev. I would say an exception may be more useful since it will tell the
dev exactly what was wrong instead of their app choking in a null return
but I am open to both.
For offset > totalNbPages :
- throwing an exception ?
- returning null ?
- returning last page ?
I would say same as above. Returning last page may be confusing but others
are acceptable with a preference toward an exception.
+1 on an exception
-M
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
(mailto:aerogear-dev@lists.jboss.org<aerogear-dev@lists.jboss.org>
)
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
4:05 p.m.
On 01/16/2013 08:43 AM, Sebastien Blanc wrote:
On Wed, Jan 16, 2013 at 2:24 PM, Kris Borchers <kris(a)redhat.com
<mailto:kris@redhat.com>> wrote:
On Jan 16, 2013, at 6:46 AM, Matthias Wessendorf
<matzew(a)apache.org <mailto:matzew@apache.org>> wrote:
>
>
> Another alternative : What about removing the "page"
> attribute and include a "action" attribute inside a
"paging"
> block ? If paging block isn't present we implicitly know we
> don't want paging :
>
> cars.read({
> paging: {
> action: "prev", //can be "next"
> offset: 2, //optional
> limit: 10 //optional
> }, success: function( data ) { // do something }, error:
> function() { // handle it } });
>
>
>
>
> But the 'updatePageConfig' would be still around ?
>
> If I "touch" (update) the limit/offset, it is globally stored,
> and reused, right ?
>
> I always have to provide a paging block, at least like this, right ?
> ==> cars.read({
> paging: {
> action: "prev", //can be "next"
> },...........;
>
>
> BTW. action sounds Struts :)
>
>
> *General remark *
> Do we want to describe in the specs the following use cases ?
>
> - Calling previous on the first page
> - Calling next on the last page
> - Setting an offset > total number of pages
>
>
>
> yeah - would be (more than) nice if that behavior is specified....
+1 Anyone want to start putting together a specs doc?
Before starting the specs doc, let's first discuss here what for
behaviour we want for these specific use cases :
When prev / next does not exist :
- throwing an exception ?
+1
- returning null ?
Return is really the wrong word for this
since we are all using callbacks.
- returning the current page ?
-1
For offset > totalNbPages :
- throwing an exception ?
-1
- returning null ?
-1, but I could see an argument for
returning an EMPTY set
- returning last page ?
+1 It is possible data will change
>
>
>
> On Wed, Jan 16, 2013 at 1:19 PM, Matthias Wessendorf
> <matzew(a)apache.org <mailto:matzew@apache.org>> wrote:
>
> Howdy!
>
> I have forked the gist and added the (current) iOS
> proposal to it:
> https://gist.github.com/4546737
>
> -M
>
> On Wed, Jan 16, 2013 at 12:46 PM, Matthias Wessendorf
> <matzew(a)apache.org <mailto:matzew@apache.org>> wrote:
> > Hello,
> >
> > a few quick/simple q's:
> >
> > JavaScript
> >
> > One question on the two gists...
> >
> > Kris' gist uses pipe.next() of scrolling forward,
> Summer's comparison gist
> > uses pipe.read(page:"next") for the JS.
> >
> > I think I do like the 'plain' read overload in JS... -
> but having a more
> > explicit next() (and others) is not that bad; but
> (currently) my vote would
> > be pipe.read(page:"prev"......
> >
> > Oh... What happens when I have a regular pipe, object
> (where the paged
> > setting is NOT specified on its ctor), and I invoke
> pipe.read(page:"next") ?
> > I hope it does not issue a JS/type error :-) but I'd
> expect to have a
> > straight read of ALL the "objects" (or
"entities")...
> >
> > Android
> >
> > You have the following:
> >
> > cars.readWithFilter(filter, new Callback<Car>() {
> > @Override
> > void onSuccess(List<Car> data) {
> > firstPage = data;
> > }
> >
> > @Override
> > void onError(Exception ex) {
> > //handle error
> > }
> > });
> >
> >
> > firstPage.next(.......);
> >
> > I am wondering what is the fristPage here (since the
> data on the onSuccess
> > has been assigned to it)
> >
> > Change Offset and Limit
> >
> > I like both (JS and Android) :) The Android solution is
> similar to what I
> > had in mind for iOS...
> >
> > I will update the comparison gist soon !
> >
> > -Matthias
> >
> >
> >
> >
> >
> > On Tue, Jan 15, 2013 at 11:00 PM, Summers Pittman
> <supittma(a)redhat.com <mailto:supittma@redhat.com>>
> > wrote:
> >>
> >> On 01/15/2013 02:51 PM, Douglas Campos wrote:
> >>
> >> As we wrap the day one of API design discussions, what
> about summarize the
> >> API proposals with usage?
> >>
> >> JS/iOS/Android:
> >>
> >> 1) usage example, covering some mentioned usecases
> like changing the
> >> paging "midflight" - something really straight to the
> point (no fluff, just
> >> stuff)
> >>
> >> I forked Kris's gist and added android stuff using my
> proposal (sans
> >> blocking methods)
> >> https://gist.github.com/4542125
> >>
> >> I went for pedantic in a couple of examples...
> >>
> >>
> >> 2) API definition
> >>
> >> I think this will give the orthogonal view we need to
> come to a decision.
> >>
> >> kris: What about you providing a snippet of the API
> you hate too? just for
> >> comparison sake :P
> >>
> >> -- qmx
> >> _______________________________________________
> >> aerogear-dev mailing list
> >> aerogear-dev(a)lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >>
> >>
> >> _______________________________________________
> >> aerogear-dev mailing list
> >> aerogear-dev(a)lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > twitter: http://twitter.com/mwessendorf
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
>
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
4:11 p.m.
On 01/16/2013 08:58 AM, Bruno Oliveira wrote:
If the data doesn't exist HTTP 204 is a good fit. Just don't
understand why we need to interrupt the app workflow, because the data doesn't exist.
But this way the application won't know there is something amiss until
the http request returns which could be a long time.
4:15 p.m.
On 01/16/2013 04:41 AM, Matthias Wessendorf wrote:
On Tue, Jan 15, 2013 at 4:06 PM, Summers Pittman
<supittma(a)redhat.com> wrote:
> On 01/15/2013 06:17 AM, Sebastien Blanc wrote:
>
> Hi,
> Some aditional remarks on Summers gist :
>
> Instead of :
> Pipe.readWithFilter(ReadFilter)
> Couldn't we just overload the read() method ? i.e :
> read(ReadFilter filter)
>
> We can depending on how it interacts with the other implementations of the
> library.
Not sure what you mean?
IMO (perhaps I am wrong).,
But wouldn't it be a bit more natural for Java, to really just
overload the read() ?
Yep. But it doesn't HURT anything to keep the method
names the same on
all the platforms. (Unless fun things can be done with ObjectiveC's
typing so iOS can overload as well)
void read(Callback<List<T>> callback);
void read(ReadFilter filter, Callback<List<T>> callback);
the 'bogus' readWithFilter comes from an iOS / ObjC limitation, I guess
we have already one func. that has "three arguments"
-read:success:failure (usage: [pipe read:MyID success:block
failure:otherBlock];)
So.. I can't really do an overload there.
-Matthias
> About the where property in ReadFilter class :
> Do we really want to mix paging and querying ?
>
> We do and we don't. The request itself requires both of these properties so
> it makes technical sense to pass them in a single wrapper. I agree it makes
> more logical sense to keep them as two separate object which you can pass
> independently.
>
> About Pipe.getPageContext(List result):
> Same remarks as Matthias, not sure to understand how it works (even if I
> think I've understand ...)
>
> In Java it's back by a WeakHashMap. Lots of Java specific implementation
> magic makes it very easy. As I've said otherwise I'm not in love with the
> method but it scratches an itch.
>
>
> General remarks about Paging:
> Even if it's not in scope for 1.0, I think we have to keep in mind that we
> will also be able to do pagination "offline" / "only client side"
(maybe we
> would do some paging on a Store element ?) , so we have to consider this
> when designing our API.
>
> I've been thinking about that as well. The Stores we have right now don't
> lend themselves to paging very well because they don't have a concept of
> order built in.
>
> Seb
>
>
>
>
>
>
> On Tue, Jan 15, 2013 at 11:37 AM, Matthias Wessendorf <matzew(a)apache.org>
> wrote:
>> https://gist.github.com/4532661
>
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
4:23 p.m.
Good point Summers. Might be an obvious question, but there we go. Are we planning to
include timeout as parameter? For example: I want to retrieve a list of a bazilion users,
and I want to specify the timeout acceptable to wait.
I didn't get the chance to look at each API, just double checking here.
--
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile
On Wednesday, January 16, 2013 at 1:11 PM, Summers Pittman wrote:
But this way the application won't know there is something amiss
until
the http request returns which could be a long time.
4:24 p.m.
good point!
I think we forgot about that. nice catch !
On Wed, Jan 16, 2013 at 4:23 PM, Bruno Oliveira <bruno(a)abstractj.org> wrote:
Good point Summers. Might be an obvious question, but there we go.
Are we
planning to include timeout as parameter? For example: I want to retrieve a
list of a bazilion users, and I want to specify the timeout acceptable to
wait.
I didn't get the chance to look at each API, just double checking here.
--
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile
On Wednesday, January 16, 2013 at 1:11 PM, Summers Pittman wrote:
> But this way the application won't know there is something amiss until
> the http request returns which could be a long time.
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
4:25 p.m.
On 01/16/2013 10:23 AM, Bruno Oliveira wrote:
Good point Summers. Might be an obvious question, but there we go.
Are we planning to include timeout as parameter? For example: I want to retrieve a list of
a bazilion users, and I want to specify the timeout acceptable to wait.
I didn't get the chance to look at each API, just double checking here.
+1
I was thinking about this yesterday. I want to but was hoping we could
get the "shape" of the API nailed down first before we started hammering
on specifics.
4:27 p.m.
and for slow/mobile networks! :-)
invoke failure() when timeout occurs, but the value should be cfgurable on
pipe level - since not related to paging.
good find!
On Wednesday, January 16, 2013, Matthias Wessendorf wrote:
good point!
I think we forgot about that. nice catch !
On Wed, Jan 16, 2013 at 4:23 PM, Bruno Oliveira
<bruno@abstractj.org<javascript:_e({}, 'cvml',
'bruno(a)abstractj.org');>
> wrote:
> Good point Summers. Might be an obvious question, but there we go. Are we
> planning to include timeout as parameter? For example: I want to retrieve a
> list of a bazilion users, and I want to specify the timeout acceptable to
> wait.
>
> I didn't get the chance to look at each API, just double checking here.
>
>
> --
> "The measure of a man is what he does with power" - Plato
> -
> @abstractj
> -
> Volenti Nihil Difficile
>
>
>
> On Wednesday, January 16, 2013 at 1:11 PM, Summers Pittman wrote:
>
> > But this way the application won't know there is something amiss until
> > the http request returns which could be a long time.
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org <javascript:_e({}, 'cvml',
> 'aerogear-dev(a)lists.jboss.org');>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
--
Sent from Gmail Mobile
4:28 p.m.
the timeout parameter would be a general property of read() and not related
to Paging ?
On Wed, Jan 16, 2013 at 4:25 PM, Summers Pittman <supittma(a)redhat.com>wrote:
On 01/16/2013 10:23 AM, Bruno Oliveira wrote:
> Good point Summers. Might be an obvious question, but there we go. Are
we planning to include timeout as parameter? For example: I want to
retrieve a list of a bazilion users, and I want to specify the timeout
acceptable to wait.
>
> I didn't get the chance to look at each API, just double checking here.
>
+1
I was thinking about this yesterday. I want to but was hoping we could
get the "shape" of the API nailed down first before we started hammering
on specifics.
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
4:29 p.m.
On Jan 16, 2013, at 9:25 AM, Summers Pittman <supittma(a)redhat.com> wrote:
On 01/16/2013 10:23 AM, Bruno Oliveira wrote:
> Good point Summers. Might be an obvious question, but there we go. Are we planning to
include timeout as parameter? For example: I want to retrieve a list of a bazilion users,
and I want to specify the timeout acceptable to wait.
>
> I didn't get the chance to look at each API, just double checking here.
>
+1
I was thinking about this yesterday. I want to but was hoping we could
get the "shape" of the API nailed down first before we started hammering
on specifics.
+1 Bruno, maybe create a JIRA so we don't lose this but since it is not specific to
paging we should not get side tracked on this.
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
4:30 p.m.
pipe level. POST can timeout too ;-)
On Wednesday, January 16, 2013, Sebastien Blanc wrote:
the timeout parameter would be a general property of read() and not
related to Paging ?
On Wed, Jan 16, 2013 at 4:25 PM, Summers Pittman
<supittma@redhat.com<javascript:_e({}, 'cvml',
'supittma(a)redhat.com');>
> wrote:
> On 01/16/2013 10:23 AM, Bruno Oliveira wrote:
> > Good point Summers. Might be an obvious question, but there we go. Are
> we planning to include timeout as parameter? For example: I want to
> retrieve a list of a bazilion users, and I want to specify the timeout
> acceptable to wait.
> >
> > I didn't get the chance to look at each API, just double checking here.
> >
> +1
>
> I was thinking about this yesterday. I want to but was hoping we could
> get the "shape" of the API nailed down first before we started hammering
> on specifics.
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org <javascript:_e({}, 'cvml',
> 'aerogear-dev(a)lists.jboss.org');>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
--
Sent from Gmail Mobile
4:31 p.m.
On 01/16/2013 10:30 AM, Matthias Wessendorf wrote:
pipe level. POST can timeout too ;-)
+1
On Wednesday, January 16, 2013, Sebastien Blanc wrote:
the timeout parameter would be a general property of read() and
not related to Paging ?
On Wed, Jan 16, 2013 at 4:25 PM, Summers Pittman
<supittma(a)redhat.com <javascript:_e({}, 'cvml',
'supittma(a)redhat.com');>> wrote:
On 01/16/2013 10:23 AM, Bruno Oliveira wrote:
> Good point Summers. Might be an obvious question, but there
we go. Are we planning to include timeout as parameter? For
example: I want to retrieve a list of a bazilion users, and I
want to specify the timeout acceptable to wait.
>
> I didn't get the chance to look at each API, just double
checking here.
>
+1
I was thinking about this yesterday. I want to but was
hoping we could
get the "shape" of the API nailed down first before we started
hammering
on specifics.
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org <javascript:_e({}, 'cvml',
'aerogear-dev(a)lists.jboss.org');>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Sent from Gmail Mobile
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
4:31 p.m.
But maybe we don't want the same timeout for a GET than for a POST ?
On Wed, Jan 16, 2013 at 4:30 PM, Matthias Wessendorf <matzew(a)apache.org>wrote:
pipe level. POST can timeout too ;-)
On Wednesday, January 16, 2013, Sebastien Blanc wrote:
> the timeout parameter would be a general property of read() and not
> related to Paging ?
>
>
> On Wed, Jan 16, 2013 at 4:25 PM, Summers Pittman <supittma(a)redhat.com>wrote:
>
>> On 01/16/2013 10:23 AM, Bruno Oliveira wrote:
>> > Good point Summers. Might be an obvious question, but there we go. Are
>> we planning to include timeout as parameter? For example: I want to
>> retrieve a list of a bazilion users, and I want to specify the timeout
>> acceptable to wait.
>> >
>> > I didn't get the chance to look at each API, just double checking here.
>> >
>> +1
>>
>> I was thinking about this yesterday. I want to but was hoping we could
>> get the "shape" of the API nailed down first before we started
hammering
>> on specifics.
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
--
Sent from Gmail Mobile
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
4:33 p.m.
On 01/16/2013 10:31 AM, Sebastien Blanc wrote:
But maybe we don't want the same timeout for a GET than for a
POST ?
Maybe we don't, but I think this may fall under KISS.
And if it ends up people need it we can add it in later.
On Wed, Jan 16, 2013 at 4:30 PM, Matthias Wessendorf
<matzew(a)apache.org <mailto:matzew@apache.org>> wrote:
pipe level. POST can timeout too ;-)
On Wednesday, January 16, 2013, Sebastien Blanc wrote:
the timeout parameter would be a general property of read()
and not related to Paging ?
On Wed, Jan 16, 2013 at 4:25 PM, Summers Pittman
<supittma(a)redhat.com> wrote:
On 01/16/2013 10:23 AM, Bruno Oliveira wrote:
> Good point Summers. Might be an obvious question, but
there we go. Are we planning to include timeout as
parameter? For example: I want to retrieve a list of a
bazilion users, and I want to specify the timeout
acceptable to wait.
>
> I didn't get the chance to look at each API, just double
checking here.
>
+1
I was thinking about this yesterday. I want to but was
hoping we could
get the "shape" of the API nailed down first before we
started hammering
on specifics.
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Sent from Gmail Mobile
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
4:35 p.m.
On 16/01/2013, at 13:23, Bruno Oliveira <bruno(a)abstractj.org> wrote:
Good point Summers. Might be an obvious question, but there we go.
Are we planning to include timeout as parameter? For example: I want to retrieve a list of
a bazilion users, and I want to specify the timeout acceptable to wait.
nice catch!
-- qmx
4:35 p.m.
Seriously guys, paging and timeout are two separate issues. Let's create a JIRA for
timeout on all libs, keep our focus on paging and move on.
On Jan 16, 2013, at 9:33 AM, Summers Pittman <supittma(a)redhat.com> wrote:
On 01/16/2013 10:31 AM, Sebastien Blanc wrote:
> But maybe we don't want the same timeout for a GET than for a POST ?
>
Maybe we don't, but I think this may fall under KISS.
And if it ends up people need it we can add it in later.
>
> On Wed, Jan 16, 2013 at 4:30 PM, Matthias Wessendorf <matzew(a)apache.org>
wrote:
> pipe level. POST can timeout too ;-)
>
>
> On Wednesday, January 16, 2013, Sebastien Blanc wrote:
> the timeout parameter would be a general property of read() and not related to Paging
?
>
>
> On Wed, Jan 16, 2013 at 4:25 PM, Summers Pittman <supittma(a)redhat.com> wrote:
> On 01/16/2013 10:23 AM, Bruno Oliveira wrote:
> > Good point Summers. Might be an obvious question, but there we go. Are we
planning to include timeout as parameter? For example: I want to retrieve a list of a
bazilion users, and I want to specify the timeout acceptable to wait.
> >
> > I didn't get the chance to look at each API, just double checking here.
> >
> +1
>
> I was thinking about this yesterday. I want to but was hoping we could
> get the "shape" of the API nailed down first before we started hammering
> on specifics.
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> --
> Sent from Gmail Mobile
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
4:41 p.m.
On 01/16/2013 06:46 AM, Matthias Wessendorf wrote:
Hello,
a few quick/simple q's:
<https://gist.github.com/2d75e480500c69993227#javascript>JavaScript
One question on the two gists...
Kris' gist <https://gist.github.com/4539188> uses |pipe.next()| of
scrolling forward, Summer's comparison gist
<https://gist.github.com/4542125> uses |pipe.read(page:"next")| for
the JS.
I think I do like the 'plain' read overload in JS... - but having a
more explicit next() (and others) is not that bad; but (currently) my
vote would be |pipe.read(page:"prev".....|.
Oh... What happens when I have a /regular/ pipe, object (where the
|paged| setting is NOT specified on its ctor), and I invoke
|pipe.read(page:"next")| ? I hope it does not issue a JS/type error
:-) but I'd expect to have a straight read of ALL the "objects" (or
"entities")...
<https://gist.github.com/2d75e480500c69993227#android>Android
You have the following:
|cars.readWithFilter(filter, new Callback<Car>() {
@Override
void onSuccess(List<Car> data) {
firstPage = data;
}
@Override
void onError(Exception ex) {
//handle error
}
});
firstPage.next(.......);
|
I am wondering what is the |fristPage| here (since the |data| on the
|onSuccess| has been assigned to it)
firstPage is a field with a type of PagedList
<https://gist.github.com/2d75e480500c69993227#change-offset-and-limit>C...
Offset and Limit
I like both (JS and Android) :) The Android solution is similar to
what I had in mind for iOS
<https://gist.github.com/cbff741b3b21a50c3b67>...
I will update the comparison gist soon !
-Matthias
On Tue, Jan 15, 2013 at 11:00 PM, Summers Pittman <supittma(a)redhat.com
<mailto:supittma@redhat.com>> wrote:
On 01/15/2013 02:51 PM, Douglas Campos wrote:
> As we wrap the day one of API design discussions, what about summarize the API
proposals with usage?
>
> JS/iOS/Android:
>
> 1) usage example, covering some mentioned usecases like changing the paging
"midflight" - something really straight to the point (no fluff, just stuff)
I forked Kris's gist and added android stuff using my proposal
(sans blocking methods)
https://gist.github.com/4542125
I went for pedantic in a couple of examples...
> 2) API definition
>
> I think this will give the orthogonal view we need to come to a decision.
>
> kris: What about you providing a snippet of the API you hate too? just for
comparison sake :P
>
> -- qmx
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
4:44 p.m.
On Wed, Jan 16, 2013 at 4:41 PM, Summers Pittman <supittma(a)redhat.com>wrote:
firstPage is a field with a type of PagedList
Did you 'gist' that API as well ?
-M
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
4:45 p.m.
On Wed, Jan 16, 2013 at 4:44 PM, Matthias Wessendorf <matzew(a)apache.org>wrote:
On Wed, Jan 16, 2013 at 4:41 PM, Summers Pittman <supittma(a)redhat.com>wrote:
> firstPage is a field with a type of PagedList
Did you 'gist' that API as well ?
Got it:
https://gist.github.com/4532661#the-pagedlist-interface
Thx!
-M
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
4:45 p.m.
On 01/16/2013 10:44 AM, Matthias Wessendorf wrote:
On Wed, Jan 16, 2013 at 4:41 PM, Summers Pittman <supittma(a)redhat.com
<mailto:supittma@redhat.com>> wrote:
firstPage is a field with a type of PagedList
Did you 'gist' that API as well ?
It is in my Strawman: https://gist.github.com/4532661
-M
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
4:50 p.m.
I think we have enough material for drafting a spec on aerogear.org repo - any takers?
-- qmx, the thread hijacker
6:44 p.m.
I tweaked the iOS API a bit more:
https://gist.github.com/cbff741b3b21a50c3b67
I also updated the "comparison" gist:
https://gist.github.com/4546737
Feedback welcome....
On Wed, Jan 16, 2013 at 4:28 PM, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
the timeout parameter would be a general property of read() and not
related
to Paging ?
On Wed, Jan 16, 2013 at 4:25 PM, Summers Pittman <supittma(a)redhat.com>
wrote:
>
> On 01/16/2013 10:23 AM, Bruno Oliveira wrote:
> > Good point Summers. Might be an obvious question, but there we go. Are
> > we planning to include timeout as parameter? For example: I want to retrieve
> > a list of a bazilion users, and I want to specify the timeout acceptable to
> > wait.
> >
> > I didn't get the chance to look at each API, just double checking here.
> >
> +1
>
> I was thinking about this yesterday. I want to but was hoping we could
> get the "shape" of the API nailed down first before we started hammering
> on specifics.
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
6:48 p.m.
On 01/16/2013 12:44 PM, Matthias Wessendorf wrote:
I tweaked the iOS API a bit more:
https://gist.github.com/cbff741b3b21a50c3b67
Should AGFilterConfig.
scrollingMetaDataLocation perhaps be a Pipe level
thing (like encoding or authentication) instead of a request level
thing? I don't imagine it changing during the lifetime of a Pipe?
Otherwise looks really good!
I also updated the "comparison" gist:
https://gist.github.com/4546737
Feedback welcome....
On Wed, Jan 16, 2013 at 4:28 PM, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
> the timeout parameter would be a general property of read() and not related
> to Paging ?
>
>
> On Wed, Jan 16, 2013 at 4:25 PM, Summers Pittman <supittma(a)redhat.com>
> wrote:
>> On 01/16/2013 10:23 AM, Bruno Oliveira wrote:
>>> Good point Summers. Might be an obvious question, but there we go. Are
>>> we planning to include timeout as parameter? For example: I want to retrieve
>>> a list of a bazilion users, and I want to specify the timeout acceptable to
>>> wait.
>>>
>>> I didn't get the chance to look at each API, just double checking here.
>>>
>> +1
>>
>> I was thinking about this yesterday. I want to but was hoping we could
>> get the "shape" of the API nailed down first before we started
hammering
>> on specifics.
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
10:29 p.m.
Maybe this is a server implementation thing or maybe a non-issue and I'm just being
dense but how would I get the last page as soon as my app loads without doing two read()
requests? I can get the first page by just adding a firstPage (just and example name)
config param to my paged pipe but I have no idea what the last page would be at that
point. Thoughts?
On Jan 16, 2013, at 11:48 AM, Summers Pittman <supittma(a)redhat.com> wrote:
On 01/16/2013 12:44 PM, Matthias Wessendorf wrote:
> I tweaked the iOS API a bit more:
> https://gist.github.com/cbff741b3b21a50c3b67
Should AGFilterConfig. scrollingMetaDataLocation perhaps be a Pipe level thing (like
encoding or authentication) instead of a request level thing? I don't imagine it
changing during the lifetime of a Pipe?
Otherwise looks really good!
> I also updated the "comparison" gist:
> https://gist.github.com/4546737
>
> Feedback welcome....
>
> On Wed, Jan 16, 2013 at 4:28 PM, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
>> the timeout parameter would be a general property of read() and not related
>> to Paging ?
>>
>>
>> On Wed, Jan 16, 2013 at 4:25 PM, Summers Pittman <supittma(a)redhat.com>
>> wrote:
>>> On 01/16/2013 10:23 AM, Bruno Oliveira wrote:
>>>> Good point Summers. Might be an obvious question, but there we go. Are
>>>> we planning to include timeout as parameter? For example: I want to
retrieve
>>>> a list of a bazilion users, and I want to specify the timeout acceptable
to
>>>> wait.
>>>>
>>>> I didn't get the chance to look at each API, just double checking
here.
>>>>
>>> +1
>>>
>>> I was thinking about this yesterday. I want to but was hoping we could
>>> get the "shape" of the API nailed down first before we started
hammering
>>> on specifics.
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
10:40 p.m.
On Wed, Jan 16, 2013 at 03:29:13PM -0600, Kris Borchers wrote:
Maybe this is a server implementation thing or maybe a non-issue and
I'm just being dense but how would I get the last page as soon as my app loads without
doing two read() requests? I can get the first page by just adding a firstPage (just and
example name) config param to my paged pipe but I have no idea what the last page would be
at that point. Thoughts?
One thing that we need to keep in mind (and one of the reasons I've been avoiding
putting first and last) is that sometimes the server isn't that efficient on returning
the size of the target collection - or you can even get an API that paginates in an
"endless" fashion. That said, I would avoid trying to put shorthands to the last
page.
-- qmx
10:43 p.m.
----- Original Message -----
| From: "Kris Borchers" <kris(a)redhat.com>
| To: "AeroGear Developer Mailing List" <aerogear-dev(a)lists.jboss.org>
| Sent: Wednesday, January 16, 2013 4:29:13 PM
| Subject: Re: [aerogear-dev] Client Paging Strawman
|
|
| Maybe this is a server implementation thing or maybe a non-issue and
| I'm just being dense but how would I get the last page as soon as my
| app loads without doing two read() requests? I can get the first
| page by just adding a firstPage (just and example name) config param
| to my paged pipe but I have no idea what the last page would be at
| that point. Thoughts?
|
On the one hand, -1 is often used for the last element in many APIs.
On the other hand, to qmx's point, What happens if we are paging digits of PI?
|
|
| On Jan 16, 2013, at 11:48 AM, Summers Pittman < supittma(a)redhat.com >
| wrote:
|
|
|
|
| On 01/16/2013 12:44 PM, Matthias Wessendorf wrote:
|
|
| I tweaked the iOS API a bit more:
| https://gist.github.com/cbff741b3b21a50c3b67 Should AGFilterConfig.
| scrollingMetaDataLocation perhaps be a Pipe level thing (like
| encoding or authentication) instead of a request level thing? I
| don't imagine it changing during the lifetime of a Pipe?
|
| Otherwise looks really good!
|
|
| I also updated the "comparison" gist: https://gist.github.com/4546737
| Feedback welcome....
|
| On Wed, Jan 16, 2013 at 4:28 PM, Sebastien Blanc
| <scm.blanc(a)gmail.com> wrote:
|
| the timeout parameter would be a general property of read() and not
| related
| to Paging ?
|
|
| On Wed, Jan 16, 2013 at 4:25 PM, Summers Pittman
| <supittma(a)redhat.com> wrote:
|
| On 01/16/2013 10:23 AM, Bruno Oliveira wrote:
|
| Good point Summers. Might be an obvious question, but there we go.
| Are
| we planning to include timeout as parameter? For example: I want to
| retrieve
| a list of a bazilion users, and I want to specify the timeout
| acceptable to
| wait.
|
| I didn't get the chance to look at each API, just double checking
| here. +1
|
| I was thinking about this yesterday. I want to but was hoping we
| could
| get the "shape" of the API nailed down first before we started
| hammering
| on specifics.
| _______________________________________________
| aerogear-dev mailing list aerogear-dev(a)lists.jboss.org
| https://lists.jboss.org/mailman/listinfo/aerogear-dev
| _______________________________________________
| aerogear-dev mailing list aerogear-dev(a)lists.jboss.org
| https://lists.jboss.org/mailman/listinfo/aerogear-dev
| _______________________________________________
| aerogear-dev mailing list
| aerogear-dev(a)lists.jboss.org
| https://lists.jboss.org/mailman/listinfo/aerogear-dev
|
|
| _______________________________________________
| aerogear-dev mailing list
| aerogear-dev(a)lists.jboss.org
| https://lists.jboss.org/mailman/listinfo/aerogear-dev
|
10:51 p.m.
On Wed, Jan 16, 2013 at 04:43:55PM -0500, Summers Pittman wrote:
On the one hand, -1 is often used for the last element in many APIs.
BREAKING: magic numbers considered harmful ;) (couldn't resist, sorry)
On the other hand, to qmx's point, What happens if we are paging
digits of PI?
This is one of the best examples for endless paging I've ever seen
:)
-- qmx
11 a.m.
Hi,
continue on with what Summers said about the "scrollingMetaDataLocation" in
iOS[1] I have a question.
I believe these are the parameters that can override the behaviour for paging (taken by
the JS gist here [2]):
a) "scrollingMetaDataLocation(iOS) or paged(js) // "headers" or
"content" to describe where to find the paging metadata,
b) "offset": {String} // override the name of the "offset" param
either in the header or in the content, default is "AG-Paging-Offset" for header
and "paging.offset" for content
c) "limit": {String} // override the name of the "limit" param either
in the header or in the content, default is "AG-Paging-Limit" for header and
"paging.limit" for content
d)"total":{String} // override the name of the "total" param either in
the header or in the content, default is "AG-Paging-Total" for header and
"paging.total" for content
e)"next":{String} // override the name for the "next" link either in
the header or in the content. Default is undefined
f) "prev":{String} // override the name for the "prev" link either in
the header or in the content. Default is undefined
So, as Summers said, I believe all these params must be set upfront, instead of passing
the possible overridable params when we create a readWithFilter. That is, it is fine when
we do the first "readWithFilter", but it will become cumbersome when afterwards
need to change the limit offset param and we need to pass along again these params.
So my question, where should we add these config parameters? In a separate object (e.g.
PageConfig) that will hold these params and then be set on the PipesConfig object during
the creation of the pipe?
I believe that is what JS does now. On android[3] I see that these parameters were added
in the existing PipesConfig object
Any thoughts?
Thanks,
Christos
[1]https://gist.github.com/cbff741b3b21a50c3b67
[2] https://gist.github.com/4531575
[3]
On Jan 16, 2013, at 7:48 PM, Summers Pittman <supittma(a)redhat.com> wrote:
On 01/16/2013 12:44 PM, Matthias Wessendorf wrote:
> I tweaked the iOS API a bit more:
> https://gist.github.com/cbff741b3b21a50c3b67
Should AGFilterConfig. scrollingMetaDataLocation perhaps be a Pipe level thing (like
encoding or authentication) instead of a request level thing? I don't imagine it
changing during the lifetime of a Pipe?
Otherwise looks really good!
> I also updated the "comparison" gist:
> https://gist.github.com/4546737
>
> Feedback welcome....
>
> On Wed, Jan 16, 2013 at 4:28 PM, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
>> the timeout parameter would be a general property of read() and not related
>> to Paging ?
>>
>>
>> On Wed, Jan 16, 2013 at 4:25 PM, Summers Pittman <supittma(a)redhat.com>
>> wrote:
>>> On 01/16/2013 10:23 AM, Bruno Oliveira wrote:
>>>> Good point Summers. Might be an obvious question, but there we go. Are
>>>> we planning to include timeout as parameter? For example: I want to
retrieve
>>>> a list of a bazilion users, and I want to specify the timeout acceptable
to
>>>> wait.
>>>>
>>>> I didn't get the chance to look at each API, just double checking
here.
>>>>
>>> +1
>>>
>>> I was thinking about this yesterday. I want to but was hoping we could
>>> get the "shape" of the API nailed down first before we started
hammering
>>> on specifics.
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
11:07 a.m.
-"send again corrected with the link to android spec"-
Hi,
continue on with what Summers said about the "scrollingMetaDataLocation" in
iOS[1] I have a question.
I believe these are the parameters that can override the behaviour for paging (taken by
the JS gist here [2]):
a) "scrollingMetaDataLocation(iOS) or paged(js) // "headers" or
"content" to describe where to find the paging metadata,
b) "offset": {String} // override the name of the "offset" param
either in the header or in the content, default is "AG-Paging-Offset" for header
and "paging.offset" for content
c) "limit": {String} // override the name of the "limit" param either
in the header or in the content, default is "AG-Paging-Limit" for header and
"paging.limit" for content
d)"total":{String} // override the name of the "total" param either in
the header or in the content, default is "AG-Paging-Total" for header and
"paging.total" for content
e)"next":{String} // override the name for the "next" link either in
the header or in the content. Default is undefined
f) "prev":{String} // override the name for the "prev" link either in
the header or in the content. Default is undefined
So, as Summers said, I believe all these params must be set upfront, instead of passing
the possible overridable params when we create a readWithFilter. That is, it is fine when
we do the first "readWithFilter", but it will become cumbersome when afterwards
need to change the limit offset param and we need to pass along again these params.
So my question, where should we add these config parameters? In a separate object (e.g.
PageConfig) that will hold these params and then be set on the PipesConfig object during
the creation of the pipe?
I believe that is what JS does now. On android[3] I see that these parameters were added
in the existing PipesConfig object
Any thoughts?
Thanks,
Christos
[1] https://gist.github.com/cbff741b3b21a50c3b67
[2] https://gist.github.com/4531575
[3]
https://github.com/aerogear/aerogear.org/blob/6c811413be17976913eaaa3498e...
On Jan 16, 2013, at 7:48 PM, Summers Pittman <supittma(a)redhat.com> wrote:
On 01/16/2013 12:44 PM, Matthias Wessendorf wrote:
> I tweaked the iOS API a bit more:
> https://gist.github.com/cbff741b3b21a50c3b67
Should AGFilterConfig. scrollingMetaDataLocation perhaps be a Pipe level thing (like
encoding or authentication) instead of a request level thing? I don't imagine it
changing during the lifetime of a Pipe?
Otherwise looks really good!
> I also updated the "comparison" gist:
> https://gist.github.com/4546737
>
> Feedback welcome....
>
> On Wed, Jan 16, 2013 at 4:28 PM, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
>> the timeout parameter would be a general property of read() and not related
>> to Paging ?
>>
>>
>> On Wed, Jan 16, 2013 at 4:25 PM, Summers Pittman <supittma(a)redhat.com>
>> wrote:
>>> On 01/16/2013 10:23 AM, Bruno Oliveira wrote:
>>>> Good point Summers. Might be an obvious question, but there we go. Are
>>>> we planning to include timeout as parameter? For example: I want to
retrieve
>>>> a list of a bazilion users, and I want to specify the timeout acceptable
to
>>>> wait.
>>>>
>>>> I didn't get the chance to look at each API, just double checking
here.
>>>>
>>> +1
>>>
>>> I was thinking about this yesterday. I want to but was hoping we could
>>> get the "shape" of the API nailed down first before we started
hammering
>>> on specifics.
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
11:10 a.m.
On Thu, Jan 17, 2013 at 11:07 AM, Christos Vasilakis <cvasilak(a)gmail.com> wrote:
-"send again corrected with the link to android spec"-
Hi,
continue on with what Summers said about the "scrollingMetaDataLocation" in
iOS[1] I have a question.
I believe these are the parameters that can override the behaviour for
paging (taken by the JS gist here [2]):
a) "scrollingMetaDataLocation(iOS) or paged(js) // "headers" or
"content"
to describe where to find the paging metadata,
b) "offset": {String} // override the name of the "offset" param
either in
the header or in the content, default is "AG-Paging-Offset" for header and
"paging.offset" for content
c) "limit": {String} // override the name of the "limit" param either
in the
header or in the content, default is "AG-Paging-Limit" for header and
"paging.limit" for content
d)"total":{String} // override the name of the "total" param either
in the
header or in the content, default is "AG-Paging-Total" for header and
"paging.total" for content
e)"next":{String} // override the name for the "next" link either in
the
header or in the content. Default is undefined
Nope, there is a"header" value for next/previous:
https://gist.github.com/4537431
-M
f) "prev":{String} // override the name for the "prev" link either in
the
header or in the content. Default is undefined
So, as Summers said, I believe all these params must be set upfront, instead
of passing the possible overridable params when we create a readWithFilter.
That is, it is fine when we do the first "readWithFilter", but it will
become cumbersome when afterwards need to change the limit offset param and
we need to pass along again these params.
So my question, where should we add these config parameters? In a separate
object (e.g. PageConfig) that will hold these params and then be set on the
PipesConfig object during the creation of the pipe?
I believe that is what JS does now. On android[3] I see that these
parameters were added in the existing PipesConfig object
Any thoughts?
Thanks,
Christos
[1] https://gist.github.com/cbff741b3b21a50c3b67
[2] https://gist.github.com/4531575
[3]
https://github.com/aerogear/aerogear.org/blob/6c811413be17976913eaaa3498e...
On Jan 16, 2013, at 7:48 PM, Summers Pittman <supittma(a)redhat.com> wrote:
On 01/16/2013 12:44 PM, Matthias Wessendorf wrote:
I tweaked the iOS API a bit more:
https://gist.github.com/cbff741b3b21a50c3b67
Should AGFilterConfig. scrollingMetaDataLocation perhaps be a Pipe level
thing (like encoding or authentication) instead of a request level thing? I
don't imagine it changing during the lifetime of a Pipe?
Otherwise looks really good!
I also updated the "comparison" gist:
https://gist.github.com/4546737
Feedback welcome....
On Wed, Jan 16, 2013 at 4:28 PM, Sebastien Blanc <scm.blanc(a)gmail.com>
wrote:
the timeout parameter would be a general property of read() and not related
to Paging ?
On Wed, Jan 16, 2013 at 4:25 PM, Summers Pittman <supittma(a)redhat.com>
wrote:
On 01/16/2013 10:23 AM, Bruno Oliveira wrote:
Good point Summers. Might be an obvious question, but there we go. Are
we planning to include timeout as parameter? For example: I want to retrieve
a list of a bazilion users, and I want to specify the timeout acceptable to
wait.
I didn't get the chance to look at each API, just double checking here.
+1
I was thinking about this yesterday. I want to but was hoping we could
get the "shape" of the API nailed down first before we started hammering
on specifics.
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
3:24 p.m.
a little late to the party, but
On Jan 16, 2013, at 9:21 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
On Wed, Jan 16, 2013 at 3:01 PM, Kris Borchers <kris(a)redhat.com> wrote:
On Jan 16, 2013, at 7:58 AM, Bruno Oliveira <bruno(a)abstractj.org> wrote:
> If the data doesn't exist HTTP 204 is a good fit. Just don't understand why
we need to interrupt the app workflow, because the data doesn't exist.
I would prefer that an exception is thrown client side before a request is ever sent to
the server. That way we save the http request which is important on mobile.
Ah! yeah - good point -> since the "paging API" knows there is no
"next" (for instance)
That being said, then the issue becomes what if that page does exist but we don't
allow the request because the data was updated since our last read? Then we wouldn't
know without another read happening.
yeah - here could the 2.x targeted feature of 'sync' come in…
"sync" is probably going to be the option here but ,
what about a setting to say don't go to the server if there is no next/prev, defaults
to always "refresh"
If they are using our data manager stuff also, the paging could be based off that,
probably a whole other discussion(offline?). I guess i'm thinking of an app where the
data doesn't change often and the user gets it all up front first.
Hmmm, interested in other opinions since relying on a 204 or any status from the server
couples the client to the server impl but if we don't allow the request, that could
also cause issues.
true :)
>
>
> --
> "The measure of a man is what he does with power" - Plato
> -
> @abstractj
> -
> Volenti Nihil Difficile
>
>
>
> On Wednesday, January 16, 2013 at 11:52 AM, Matthias Wessendorf wrote:
>
>>
>> On Wed, Jan 16, 2013 at 2:48 PM, Kris Borchers <kris(a)redhat.com
(mailto:kris@redhat.com)> wrote:
>>> I would say returning the current page would be confusing. I would be fine
with an exception or returning null as both can be handled pretty easily by a dev. I would
say an exception may be more useful since it will tell the dev exactly what was wrong
instead of their app choking in a null return but I am open to both.
>>>
>>>>
>>>> For offset > totalNbPages :
>>>> - throwing an exception ?
>>>> - returning null ?
>>>> - returning last page ?
>>>
>>>
>>>
>>> I would say same as above. Returning last page may be confusing but others
are acceptable with a preference toward an exception.
>>
>>
>> +1 on an exception
>>
>> -M
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org (mailto:aerogear-dev@lists.jboss.org)
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf _______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
3:41 p.m.
On Thu, Jan 17, 2013 at 3:24 PM, Lucas Holmquist <lholmqui(a)redhat.com> wrote:
"sync" is probably going to be the option here but ,
what about a setting to say don't go to the server if there is no next/prev,
defaults to always "refresh"
If they are using our data manager stuff also, the paging could be based
off that, probably a whole other discussion(offline?). I guess i'm
thinking of an app where the data doesn't change often and the user gets it
all up front first.
I don't see this being part of 1.0.0. BUT the general paging APIs
(e.g. 'next', previous etc) would work on a data store as well, right
?
-M
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
3:45 p.m.
On Jan 17, 2013, at 9:41 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
On Thu, Jan 17, 2013 at 3:24 PM, Lucas Holmquist
<lholmqui(a)redhat.com> wrote:
> "sync" is probably going to be the option here but ,
> what about a setting to say don't go to the server if there is no next/prev,
> defaults to always "refresh"
>
> If they are using our data manager stuff also, the paging could be based
> off that, probably a whole other discussion(offline?). I guess i'm
> thinking of an app where the data doesn't change often and the user gets it
> all up front first.
I don't see this being part of 1.0.0. BUT the general paging APIs
(e.g. 'next', previous etc) would work on a data store as well, right
?
definitely not at 1.0.0, i think this will go with the offline discussion
-M
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
3:56 p.m.
On Jan 17, 2013, at 8:41 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
On Thu, Jan 17, 2013 at 3:24 PM, Lucas Holmquist
<lholmqui(a)redhat.com> wrote:
> "sync" is probably going to be the option here but ,
> what about a setting to say don't go to the server if there is no next/prev,
> defaults to always "refresh"
>
> If they are using our data manager stuff also, the paging could be based
> off that, probably a whole other discussion(offline?). I guess i'm
> thinking of an app where the data doesn't change often and the user gets it
> all up front first.
I don't see this being part of 1.0.0. BUT the general paging APIs
(e.g. 'next', previous etc) would work on a data store as well, right
?
This will have to be a bigger discussion as keeping things in a particular order in
conjunction with things like localStorage or JS objects in general is not trivial.
-M
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
4:03 p.m.
On Thu, Jan 17, 2013 at 3:56 PM, Kris Borchers <kris(a)redhat.com> wrote:
On Jan 17, 2013, at 8:41 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
> On Thu, Jan 17, 2013 at 3:24 PM, Lucas Holmquist <lholmqui(a)redhat.com> wrote:
>> "sync" is probably going to be the option here but ,
>> what about a setting to say don't go to the server if there is no next/prev,
>> defaults to always "refresh"
>>
>> If they are using our data manager stuff also, the paging could be based
>> off that, probably a whole other discussion(offline?). I guess i'm
>> thinking of an app where the data doesn't change often and the user gets it
>> all up front first.
>
>
> I don't see this being part of 1.0.0. BUT the general paging APIs
> (e.g. 'next', previous etc) would work on a data store as well, right
> ?
This will have to be a bigger discussion as keeping things in a particular order in
conjunction with things like localStorage or JS objects in general is not trivial.
indexed list ? :)
>
> -M
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
4:27 p.m.
On Jan 17, 2013, at 9:03 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
On Thu, Jan 17, 2013 at 3:56 PM, Kris Borchers
<kris(a)redhat.com> wrote:
>
> On Jan 17, 2013, at 8:41 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
>
>> On Thu, Jan 17, 2013 at 3:24 PM, Lucas Holmquist <lholmqui(a)redhat.com>
wrote:
>>> "sync" is probably going to be the option here but ,
>>> what about a setting to say don't go to the server if there is no
next/prev,
>>> defaults to always "refresh"
>>>
>>> If they are using our data manager stuff also, the paging could be based
>>> off that, probably a whole other discussion(offline?). I guess i'm
>>> thinking of an app where the data doesn't change often and the user gets
it
>>> all up front first.
>>
>>
>> I don't see this being part of 1.0.0. BUT the general paging APIs
>> (e.g. 'next', previous etc) would work on a data store as well, right
>> ?
>
> This will have to be a bigger discussion as keeping things in a particular order in
conjunction with things like localStorage or JS objects in general is not trivial.
indexed list ? :)
Maybe. I just need to devote more brain time/power to this and don't want to distract
from the Pipeline paging right now.
>>
>> -M
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
4125
days inactive
4128
days old
127 comments
9 participants
participants (9)
-
Bruno Oliveira -
Christos Vasilakis -
Douglas Campos -
Kris Borchers -
Lucas Holmquist -
Matthias Wessendorf -
qmx＠qmx.me
-
Sebastien Blanc -
Summers Pittman