[aerogear-dev] Client Paging Strawman

[Matthias Wessendorf]

On Tue, Jan 15, 2013 at 2:25 PM, Matthias Wessendorf <matzew at 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 at gmail.com> wrote:
>> In the same spirit (inspired from
>> http://stackoverflow.com/questions/5412059/how-to-implement-general-pagination)
>> :
>>
>>
>> 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 at 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 at 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 at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at 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