<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix"><br>
I'm thinking about dropping the blocking next(), prev(), etc.
methods from the proposal and only keeping the callback driven
methods.<br>
<br>
WDYT?<br>
<br>
On 01/15/2013 11:18 AM, Summers Pittman wrote:<br>
</div>
<blockquote cite="mid:50F58163.9030301@redhat.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 01/15/2013 08:45 AM, Sebastien
Blanc wrote:<br>
</div>
<blockquote
cite="mid:CAD_dpu0dZceRqzoUWeOqQX2v_QfopR_2yQz7Zhmbv7qnSbhDqg@mail.gmail.com"
type="cite">
<div>Just to summarize what have until now :</div>
<div><br>
</div>
<div>1. Kris's proposition: <a moz-do-not-send="true"
href="https://gist.github.com/4531575">https://gist.github.com/4531575</a></div>
<div><br>
</div>
<div>2. Summers's proposition: <a moz-do-not-send="true"
href="https://gist.github.com/4532661">https://gist.github.com/4532661</a></div>
<div><br>
</div>
<div>3. qmx's propositon: <a moz-do-not-send="true"
href="https://gist.github.com/4538709">https://gist.github.com/4538709</a></div>
<div><br>
</div>
<div>4. Sebi's proposition<a moz-do-not-send="true"
href="https://gist.github.com/4538725">https://gist.github.com/4538725</a></div>
<div><br>
</div>
<div><br>
</div>
</blockquote>
I've just updated my proposition. PageContext is no longer and
thing and I've replaced it with a PagedList interface.<br>
<blockquote
cite="mid:CAD_dpu0dZceRqzoUWeOqQX2v_QfopR_2yQz7Zhmbv7qnSbhDqg@mail.gmail.com"
type="cite">
<div><br>
<br>
<div class="gmail_quote">On Tue, Jan 15, 2013 at 2:32 PM,
Matthias Wessendorf <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:matzew@apache.org"
target="_blank">matzew@apache.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Tue, Jan 15, 2013 at 2:25 PM, Matthias
Wessendorf <<a moz-do-not-send="true"
href="mailto:matzew@apache.org">matzew@apache.org</a>>
wrote:<br>
> I was wondering, if the result should be received
on every rquest,<br>
<br>
<br>
</div>
ideally on the callback..., to not block (at least in iOS
land, I<br>
would pass that "result set" on to the "success" block)<br>
<span class="HOEnZb"><font color="#888888"><br>
-M<br>
</font></span>
<div class="HOEnZb">
<div class="h5"><br>
><br>
> thx<br>
><br>
> On Tue, Jan 15, 2013 at 2:01 PM, Sebastien Blanc
<<a moz-do-not-send="true"
href="mailto:scm.blanc@gmail.com">scm.blanc@gmail.com</a>>
wrote:<br>
>> In the same spirit (inspired from<br>
>> <a moz-do-not-send="true"
href="http://stackoverflow.com/questions/5412059/how-to-implement-general-pagination"
target="_blank">http://stackoverflow.com/questions/5412059/how-to-implement-general-pagination</a>)<br>
>> :<br>
>><br>
>><br>
>> public interface PagedResult<T> {<br>
>><br>
>> PagedResult<T> next();<br>
>><br>
>> PagedResult<T> prev();<br>
>><br>
>> PagedResult<T> withOffset(int
offset);<br>
>><br>
>> PagedResult<T> withLimit(int
limit);<br>
>><br>
>> List<T> result();<br>
>><br>
>> }<br>
>><br>
>><br>
>> On Tue, Jan 15, 2013 at 1:38 PM, Douglas
Campos <<a moz-do-not-send="true"
href="mailto:qmx@qmx.me">qmx@qmx.me</a>> wrote:<br>
>>><br>
>>> I'm not a fan of those PageContext
objects (remembers me of some wild-ass<br>
>>> ThreadLocals leaking all over)<br>
>>><br>
>>> My proposal for the paging aware APIs
would be something like this:<br>
>>><br>
>>> public interface PagedResult<T> {<br>
>>><br>
>>> List<T> next();<br>
>>><br>
>>> List<T> prev();<br>
>>><br>
>>> List<T> page(int offset, int
limit);<br>
>>><br>
>>> }<br>
>>><br>
>>> and the Async counterpart<br>
>>><br>
>>> public interface
AsyncPagedResult<T> {<br>
>>><br>
>>> void
next(Callback<List<T>> callback);<br>
>>><br>
>>> void
prev(Callback<List<T>> callback);<br>
>>><br>
>>> void page(int offset, int limit,
Callback<List<T>> callback);<br>
>>><br>
>>> public static interface
Callback<U> {<br>
>>> public void onResult(U result);<br>
>>> }<br>
>>> }<br>
>>><br>
>>> I don't like the idea of having a
companion object for holding the<br>
>>> pagination state.<br>
>>><br>
>>> Thoughts?<br>
>>><br>
>>> -- qmx<br>
>>><br>
>>> On 15/01/2013, at 08:37, Matthias
Wessendorf <<a moz-do-not-send="true"
href="mailto:matzew@apache.org">matzew@apache.org</a>>
wrote:<br>
>>><br>
>>> > Hi Summers,<br>
>>> ><br>
>>> ><br>
>>> > <a moz-do-not-send="true"
href="https://gist.github.com/4532661"
target="_blank">https://gist.github.com/4532661</a><br>
>>> ><br>
>>> > That is a way to do paging which
keeps Pipes immutable, uses<br>
>>> > readWithFilter, and doesn't impose
any (for convenient definitions of any)<br>
>>> > bookkeeping on the developer.<br>
>>> ><br>
>>> ><br>
>>> > from your Andorid gist:<br>
>>> ><br>
>>> > A) Once the response has been
received, the Pipe implementation will<br>
>>> > return a List of objects. If this
List instance is passed to<br>
>>> > Pipe.getPageContext the appropriate
PageContext will be returned<br>
>>> ><br>
>>> > Note: There is no 'return' - the
readWithFilter is void, instead a<br>
>>> > Callback is invoked
(onSuccess(list)), see Pipe.java<br>
>>> ><br>
>>> > B) The developer will receive from
readWithFilter() a List of object. If<br>
>>> > she passes this list into
Pipe.getPageContext(List result) she will receive<br>
>>> > the PageContext associated with this
result.<br>
>>> ><br>
>>> > Do you mean like:<br>
>>> ><br>
>>> > ...<br>
>>> > myPipe.readWithFilter(filter, new
Callback<List<Data>>() {<br>
>>> ><br>
>>> ><br>
>>> > @Override<br>
>>> ><br>
>>> ><br>
>>> > public void
onSuccess(List<Data> data) {<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > // get the PageContext:<br>
>>> ><br>
>>> ><br>
>>> > PageContext ctx =
myPipe.getPageContext(data);<br>
>>> ><br>
>>> ><br>
>>> > ...<br>
>>> ><br>
>>> ><br>
>>> > }<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > @Override<br>
>>> ><br>
>>> ><br>
>>> > public void onFailure(Exception e) {<br>
>>> ><br>
>>> ><br>
>>> > }<br>
>>> > });<br>
>>> > Not sure about that.....<br>
>>> ><br>
>>> > But for iOS I am thinking about
passing in the PageContext into the<br>
>>> > closure/block of the readWithFilter,
like:<br>
>>> ><br>
>>> > -(void) readWithFilter:(void
(^)(id<AGFilterConfig> config)) config<br>
>>> ><br>
>>> ><br>
>>> > success:(void (^)(id listOfObjects,
id pageContext))success<br>
>>> ><br>
>>> ><br>
>>> > failure:(void (^)(NSError
*error))failure;<br>
>>> > A usage would look like:<br>
>>> ><br>
>>> > [pipe
readWithFilter:^(id<AGFilterConfig> config) {<br>
>>> ><br>
>>> ><br>
>>> > // set the filter args and override
the given defaults<br>
>>> ><br>
>>> ><br>
>>> > } success:^(id listOfObjects, id
pageContext) {<br>
>>> ><br>
>>> ><br>
>>> > // work with the listOfObjects
reponse.<br>
>>> ><br>
>>> ><br>
>>> > // for paging/query info, access the
given pagecontext,<br>
>>> ><br>
>>> ><br>
>>> > // of the CURRENT request<br>
>>> ><br>
>>> ><br>
>>> > ...<br>
>>> ><br>
>>> ><br>
>>> > } failure:^(NSError *error) {<br>
>>> ><br>
>>> ><br>
>>> > // handle errorz<br>
>>> ><br>
>>> ><br>
>>> > }];<br>
>>> > Any thoughts ?<br>
>>> ><br>
>>> > Not sure I like (or understand) the
Pipe.getPageContext(List result)<br>
>>> > call. Current mindset is that
thePageContext just (and only) belongs to the<br>
>>> > previous (executed) request... Not
sure I want to support something like<br>
>>> ><br>
>>> > // first call:<br>
>>> > List<SomeType> first;<br>
>>> > myPipe.readWithFilter(.....) // set
first inside of callback<br>
>>> > ...<br>
>>> > // second call:<br>
>>> > List<SomeType> second;<br>
>>> > myPipe.readWithFilter(.....) // set
second inside of callback<br>
>>> > ...<br>
>>> > // third call:<br>
>>> > List<SomeType> third;<br>
>>> > myPipe.readWithFilter(.....) // set
third inside of callback<br>
>>> > ...<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > /// A BIT LATER ....:<br>
>>> > myPipe.getPageContext(first);<br>
>>> ><br>
>>> ><br>
>>> > I am not sure if that
(myPipe.getPageContext(first);) is really desired<br>
>>> > (or would even easily work, as it
would need to store the "metadata").....<br>
>>> ><br>
>>> ><br>
>>> > Perhaps I am just wrong.<br>
>>> ><br>
>>> ><br>
>>> > --<br>
>>> > Matthias Wessendorf<br>
>>> ><br>
>>> > blog: <a moz-do-not-send="true"
href="http://matthiaswessendorf.wordpress.com/"
target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
>>> > sessions: <a moz-do-not-send="true"
href="http://www.slideshare.net/mwessendorf"
target="_blank">http://www.slideshare.net/mwessendorf</a><br>
>>> > twitter: <a moz-do-not-send="true"
href="http://twitter.com/mwessendorf"
target="_blank">http://twitter.com/mwessendorf</a><br>
>>> >
_______________________________________________<br>
>>> > aerogear-dev mailing list<br>
>>> > <a moz-do-not-send="true"
href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>>> > <a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/aerogear-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>>><br>
>>><br>
>>>
_______________________________________________<br>
>>> aerogear-dev mailing list<br>
>>> <a moz-do-not-send="true"
href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>>> <a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/aerogear-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>><br>
>><br>
>><br>
>>
_______________________________________________<br>
>> aerogear-dev mailing list<br>
>> <a moz-do-not-send="true"
href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>> <a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/aerogear-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>><br>
><br>
><br>
><br>
> --<br>
> Matthias Wessendorf<br>
><br>
> blog: <a moz-do-not-send="true"
href="http://matthiaswessendorf.wordpress.com/"
target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
> sessions: <a moz-do-not-send="true"
href="http://www.slideshare.net/mwessendorf"
target="_blank">http://www.slideshare.net/mwessendorf</a><br>
> twitter: <a moz-do-not-send="true"
href="http://twitter.com/mwessendorf"
target="_blank">http://twitter.com/mwessendorf</a><br>
<br>
<br>
<br>
--<br>
Matthias Wessendorf<br>
<br>
blog: <a moz-do-not-send="true"
href="http://matthiaswessendorf.wordpress.com/"
target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
sessions: <a moz-do-not-send="true"
href="http://www.slideshare.net/mwessendorf"
target="_blank">http://www.slideshare.net/mwessendorf</a><br>
twitter: <a moz-do-not-send="true"
href="http://twitter.com/mwessendorf"
target="_blank">http://twitter.com/mwessendorf</a><br>
_______________________________________________<br>
aerogear-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/aerogear-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
aerogear-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/aerogear-dev">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a>
</pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
aerogear-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/aerogear-dev">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>