<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 02:45 PM, Kris Borchers
wrote:<br>
</div>
<blockquote
cite="mid:03FAA9F1-A5BD-48ED-8718-40EE2817C72F@redhat.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<br>
<div>
<div>On Jan 14, 2013, at 1:36 PM, Summers Pittman <<a
moz-do-not-send="true" href="mailto:supittma@redhat.com">supittma@redhat.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 01/14/2013 02:34 PM, Kris
Borchers wrote:<br>
</div>
<blockquote
cite="mid:64B2619B-CE43-4686-8415-EE40BD707729@redhat.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<br>
<div>
<div>On Jan 14, 2013, at 1:29 PM, Summers Pittman <<a
moz-do-not-send="true"
href="mailto:supittma@redhat.com">supittma@redhat.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 01/14/2013 02:27 PM,
Kris Borchers wrote:<br>
</div>
<blockquote
cite="mid:B5853352-6DCD-4042-AAFB-48A214692514@redhat.com"
type="cite">
<meta http-equiv="Content-Type"
content="text/html; charset=ISO-8859-1">
<br>
<div>
<div>On Jan 14, 2013, at 1:17 PM, Summers
Pittman <<a moz-do-not-send="true"
href="mailto:supittma@redhat.com">supittma@redhat.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div 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 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>
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>
No because I think fundamentally paging is part of
the query and not part of the pipe.<br>
</div>
</blockquote>
<div><br>
</div>
OK, but then this is where I don't see the value in
adding next/prev/first/last methods if I have to pass
parameters (that aren't already stored on the pipe) with
every use. Then as a developer, I might as well just use
the basic query option in JS's read method, specify my
parameters and call it a day and have less stuff to sort
through in the docs on how to do paging.</div>
</blockquote>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a moz-do-not-send="true"
href="https://gist.github.com/4532661">https://gist.github.com/4532661</a><br>
<br>
That is a way to do paging which keeps Pipes immutable, uses
readWithFilter, and doesn't impose any (for convenient
definitions of any) bookkeeping on the developer.<br>
</div>
</blockquote>
<div><br>
</div>
This just feels like we're killing the dynamic nature of JS. :)</div>
</blockquote>
Well this is a an description of a Java implementation.<br>
<br>
Instead of a separate PageContext what if readWithFilter() returns
a PagedList which has next() and prev() as methods on it? In java
this can implement a list and be cast at runtime. The only question
is does next() return a new PagedList or return void and update the
current pagedlist?<br>
<blockquote
cite="mid:03FAA9F1-A5BD-48ED-8718-40EE2817C72F@redhat.com"
type="cite">
<div>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000">
<blockquote
cite="mid:64B2619B-CE43-4686-8415-EE40BD707729@redhat.com"
type="cite">
<div><br>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000">
<blockquote
cite="mid:B5853352-6DCD-4042-AAFB-48A214692514@redhat.com"
type="cite">
<div>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000"> <br>
</div>
_______________________________________________<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"
class="moz-txt-link-freetext"
href="https://lists.jboss.org/mailman/listinfo/aerogear-dev">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
</blockquote>
</div>
<br>
<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>
</div>
_______________________________________________<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"
class="moz-txt-link-freetext"
href="https://lists.jboss.org/mailman/listinfo/aerogear-dev">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
</blockquote>
</div>
<br>
<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>
</div>
_______________________________________________<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 class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/aerogear-dev">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
</blockquote>
</div>
<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>