<br><br><div class="gmail_quote">On Mon, Jan 14, 2013 at 8:28 PM, Summers Pittman <span dir="ltr"><<a href="mailto:supittma@redhat.com" target="_blank">supittma@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div><div class="h5">
<div>On 01/14/2013 02:21 PM, Matthias
Wessendorf wrote:<br>
</div>
<blockquote type="cite"><br>
<br>
<div class="gmail_quote">On Mon, Jan 14, 2013 at 8:17 PM, Summers
Pittman <span dir="ltr"><<a href="mailto:supittma@redhat.com" target="_blank">supittma@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>
<div>
<div>On 01/14/2013 01:00 PM, Kris Borchers wrote:<br>
</div>
</div>
</div>
<blockquote type="cite">
<div>
<div> OK folks, below is the contents of this
gist <a href="https://gist.github.com/4531575" target="_blank">https://gist.github.com/4531575</a>.
I may have missed a number of things, gotten too
specific in places or not specific enough in others.
This should hopefully get a good discussion going on
how we want to handle paging across all of the client
libraries. Let's keep all comments on the list and not
the gist as much as possible to avoid breaking up the
conversation.
<div><br>
</div>
<div>
<div>Below is a pipe configuration showing the
different paging options. Defaults are just
suggestions and are up for discussion as much as
the rest of it</div>
<div><br>
</div>
<div> var pagedPipe = AeroGear.Pipeline({</div>
<div> name: "pager",</div>
<div> settings: {</div>
<div> paged: {String}, // Default is
"headers", can also be "content", or undefined for
no paging</div>
<div> pageConfig: { // Only required if
paged is not undefined</div>
<div> // which page, header default
is "AG-Paging-Offset", content default is
"paging.offset"</div>
<div> offset: {String},</div>
<div> offsetVal: {Number}, // Default
0 for first page</div>
<div> </div>
<div> // items per page, header
default is "AG-Paging-Limit", content default is
"paging.limit"</div>
<div> limit: {String},</div>
<div> limitVal: {Number}, // Default
5 items per page</div>
<div> </div>
<div> // total number of items,
header default is "AG-Paging-Total", content
default is "paging.total"</div>
<div> total: {String},</div>
<div> </div>
<div> // link to next page, default
in both cases is undefined</div>
<div> next: {String},</div>
<div> </div>
<div> // link to previous page,
default in both cases is undefined</div>
<div> prev: {String}</div>
<div> }</div>
<div> } </div>
<div> }).pipes.pager;</div>
<div><br>
</div>
<div>Getter/Setter methods should be provided for
getting and updating the offsetVal and limitVal
defaults</div>
<div><br>
</div>
<div> var defaultOffset =
pagedPipe.getOffsetVal();</div>
<div> pagedPipe.setOffsetVal( defaultOffset + 1
); // by default the second page would be returned</div>
<div> </div>
<div> var defaultLimit = pagedPipe.getLimitVal();</div>
<div> pagedPipe.setLimitVal( defaultLimit + 5 );
// by default, 10 items would be returned per page</div>
<div><br>
</div>
<div>## read()</div>
<div>By default, a read() against a paged pipe will
return the first page based on the default
offsetVal and limitVal. We could possible add an
option that doesn't effect unpaged pipes but on a
paged pipe, it can be used to turn off paging for
that read() and get all data</div>
<div><br>
</div>
<div> // Get first page</div>
<div> pagedPipe.read({success callback handles
data});</div>
<div> </div>
<div> // Get all data from paged pipe</div>
<div> pagedPipe.read({</div>
<div> page: false,</div>
<div> success: handle the data</div>
<div> });</div>
<div> </div>
<div>To avoid code duplication, **next**, **prev**,
**first** and **last** pages can be retrieved by
passing an option to the read method of a paged
pipe since other than some paging housekeeping,
the code would be the same. We can also use that
same option as above that was used to get all data
from a paged pipe. One question, when requesting
prev from first page or next from last page,
should it throw an error that needs to be handled
or just return and empty data set? I see
advantages and disadvantages of both.</div>
<div><br>
</div>
<div> // Get next page</div>
<div> pagedPipe.read({</div>
<div> page: "next",</div>
<div> success: handle the data</div>
<div> });</div>
<div> </div>
<div> // Get previous page</div>
<div> pagedPipe.read({</div>
<div> page: "prev",</div>
<div> success: handle the data</div>
<div> });</div>
<div> </div>
<div> // Get first page</div>
<div> pagedPipe.read({</div>
<div> page: "first",</div>
<div> success: handle the data</div>
<div> });</div>
<div> </div>
<div> // Get last page</div>
<div> pagedPipe.read({</div>
<div> page: "last",</div>
<div> success: handle the data</div>
<div> });</div>
</div>
<br>
<fieldset></fieldset>
<br>
</div>
</div>
<div>
<pre>_______________________________________________
aerogear-dev mailing list
<a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a>
</pre>
</div>
</blockquote>
At first glance I don't like having the distinction between
a "Pipe" and a "PagedPipe". In Java land PagedPipe will be
an interface which extends Pipe (this is no big deal) and
PagedRestAdatper would extend RestAdapted and implement
PagedPipe. This isn't too bad but it makes reusing paging
logic a bit harder. (And also this is at first glance).<br>
</div>
</blockquote>
<div><br>
</div>
<div>haven't thought about typing, but a subclass (in iOS / Java
land) sounds reasonable.</div>
</div>
</blockquote></div></div>
I say it makes reusing the paging logic harder because the thing
which can page is a subclass of RestAdapter. If we could somehow
composite Paging into rest adapter it would work out better.
Composition is a bit more work to get "right" than inheritance. (I
say "right" because if it is done wrong the classes end up being too
tightly coupled and you might as well have used inheritance to begin
with).<br></div></blockquote><div><br></div><div><br></div><div>+1 on composition</div><div><br></div><div>Also, "previous" name "PagedPipe" would be wrong, as the composition could be handy for other query requests, instead of just plain paging</div>
<div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<blockquote type="cite"><div class="im">
<div class="gmail_quote">
<div><br>
</div>
<div>Will post something 2morrow</div>
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> <br>
The biggest issue I see with a PagedPipe is it means a
developer can't change his paging preferences without
creating a new Pipe. <br>
</div>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div>oh, I could not update the settings? That's a -1 </div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> <br>
</div>
<br>
_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
Matthias Wessendorf <br>
<br>
blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a>
<br>
<fieldset></fieldset>
<br>
</div><div class="im"><pre>_______________________________________________
aerogear-dev mailing list
<a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a>
</pre>
</div></blockquote>
<br>
</div>
<br>_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Matthias Wessendorf <br><br>blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a>