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