<br><br><div class="gmail_quote">On Mon, Jan 14, 2013 at 8:29 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:27 PM, Kris Borchers
wrote:<br>
</div>
<blockquote type="cite">
<br>
<div>
<div>On Jan 14, 2013, at 1:17 PM, Summers Pittman <<a href="mailto:supittma@redhat.com" target="_blank">supittma@redhat.com</a>>
wrote:</div>
<br>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000">
<div>On 01/14/2013 01:00 PM, Kris
Borchers wrote:<br>
</div>
<blockquote type="cite">
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>
<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>
</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>
<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>
If I add a setter for "paged" that would effectively fix that on
the JS side since offset and limit are already updatable. Does
that work for you?<br>
</div>
</blockquote></div></div>
No because I think fundamentally paging is part of the query and not
part of the pipe.</div></blockquote><div><br></div><div><br></div><div>+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">
<div class="im"><br>
<blockquote type="cite">
<div>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000"> <br>
</div>
_______________________________________________<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>
</blockquote>
</div>
<br>
<br>
<fieldset></fieldset>
<br>
<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>
</blockquote>
<br>
</div></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>