On Tue, Jan 15, 2013 at 4:06 PM, Summers Pittman <supittma(a)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() ?
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(a)apache.org>
wrote:
>
>
https://gist.github.com/4532661
_______________________________________________
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