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