[aerogear-dev] Client Paging Strawman

[Summers Pittman]

On 01/16/2013 04:41 AM, Matthias Wessendorf wrote:
> On Tue, Jan 15, 2013 at 4:06 PM, Summers Pittman <supittma at redhat.com> wrote:
>> On 01/15/2013 06:17 AM, Sebastien Blanc wrote:
>>
>> Hi,
>> Some aditional remarks on Summers gist :
>>
>> Instead of :
>> Pipe.readWithFilter(ReadFilter)
>> Couldn't we just overload the read() method ? i.e :
>> read(ReadFilter filter)
>>
>> We can depending on how it interacts with the other implementations of the
>> library.
>
> Not sure what you mean?
>
> IMO (perhaps I am wrong).,
>
> But wouldn't it be a bit more natural for Java, to really just
> overload the read() ?
Yep.  But it doesn't HURT anything to keep the method names the same on 
all the platforms.  (Unless fun things can be done with ObjectiveC's 
typing so iOS can overload as well)
>
> void read(Callback<List<T>> callback);
> void read(ReadFilter filter, Callback<List<T>> callback);
>
> the 'bogus' readWithFilter comes from an iOS / ObjC limitation, I guess
>
>
> we have already one func. that has "three arguments"
> -read:success:failure  (usage: [pipe read:MyID success:block
> failure:otherBlock];)
>
> So.. I can't really do an overload there.
>
>
> -Matthias
>
>
>> About the where property in ReadFilter class :
>> Do we really want to mix paging and querying ?
>>
>> We do and we don't.  The request itself requires both of these properties so
>> it makes technical sense to pass them in a single wrapper.  I agree it makes
>> more logical sense to keep them as two separate object which you can pass
>> independently.
>>
>> About Pipe.getPageContext(List result):
>> Same remarks as Matthias, not sure to understand how it works (even if I
>> think I've understand ...)
>>
>> In Java it's back by a WeakHashMap.  Lots of Java specific implementation
>> magic makes it very easy.  As I've said otherwise I'm not in love with the
>> method but it scratches an itch.
>>
>>
>> General remarks about Paging:
>> Even if it's not in scope for 1.0, I think we have to keep in mind that we
>> will also be able to do pagination "offline" / "only client side" (maybe we
>> would do some paging on a Store element ?) , so we have to consider this
>> when designing our  API.
>>
>> I've been thinking about that as well.  The Stores we have right now don't
>> lend themselves to paging very well because they don't have a concept of
>> order built in.
>>
>> Seb
>>
>>
>>
>>
>>
>>
>> On Tue, Jan 15, 2013 at 11:37 AM, Matthias Wessendorf <matzew at apache.org>
>> wrote:
>>> https://gist.github.com/4532661
>>
>>
>>
>>
>> _______________________________________________
>> 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
>>
>
>