On Tue, Jan 15, 2013 at 2:25 PM, Matthias Wessendorf <matzew(a)apache.org> wrote:
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