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