<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">On 01/14/2013 01:00 PM, Kris Borchers
wrote:<br>
</div>
<blockquote
cite="mid:93FA652C-7CD0-4504-B22D-0754A6269825@redhat.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
OK folks, below is the contents of this gist <a
moz-do-not-send="true" href="https://gist.github.com/4531575">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 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>
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>
<br>
</body>
</html>