We can depending on how it interacts with the other implementations of the library.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 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 the where property in ReadFilter class :Do we really want to mix paging and querying ?
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.About Pipe.getPageContext(List result):Same remarks as Matthias, not sure to understand how it works (even if I think I've understand ...)
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.
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.
Seb
On Tue, Jan 15, 2013 at 11:37 AM, Matthias Wessendorf <matzew@apache.org> wrote:
https://gist.github.com/4532661
_______________________________________________ aerogear-dev mailing list aerogear-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev