Client Paging Strawman
by Kris Borchers
OK folks, below is the contents of this gist https://gist.github.com/4531575. 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.
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
var pagedPipe = AeroGear.Pipeline({
name: "pager",
settings: {
paged: {String}, // Default is "headers", can also be "content", or undefined for no paging
pageConfig: { // Only required if paged is not undefined
// which page, header default is "AG-Paging-Offset", content default is "paging.offset"
offset: {String},
offsetVal: {Number}, // Default 0 for first page
// items per page, header default is "AG-Paging-Limit", content default is "paging.limit"
limit: {String},
limitVal: {Number}, // Default 5 items per page
// total number of items, header default is "AG-Paging-Total", content default is "paging.total"
total: {String},
// link to next page, default in both cases is undefined
next: {String},
// link to previous page, default in both cases is undefined
prev: {String}
}
}
}).pipes.pager;
Getter/Setter methods should be provided for getting and updating the offsetVal and limitVal defaults
var defaultOffset = pagedPipe.getOffsetVal();
pagedPipe.setOffsetVal( defaultOffset + 1 ); // by default the second page would be returned
var defaultLimit = pagedPipe.getLimitVal();
pagedPipe.setLimitVal( defaultLimit + 5 ); // by default, 10 items would be returned per page
## read()
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
// Get first page
pagedPipe.read({success callback handles data});
// Get all data from paged pipe
pagedPipe.read({
page: false,
success: handle the data
});
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.
// Get next page
pagedPipe.read({
page: "next",
success: handle the data
});
// Get previous page
pagedPipe.read({
page: "prev",
success: handle the data
});
// Get first page
pagedPipe.read({
page: "first",
success: handle the data
});
// Get last page
pagedPipe.read({
page: "last",
success: handle the data
});
10 years, 2 months
iOS 'spec' (or API proposal) (was: Re: Paging PR)
by Matthias Wessendorf
Based on that 'generic' spec ([1]), something like this would be the
_concrete_ iOS API:
https://gist.github.com/cbff741b3b21a50c3b67
-Matthias
[1] https://github.com/aerogear/aerogear.org/blob/client_paging_spec/docs/spe...
On Thu, Jan 17, 2013 at 11:32 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
> Hello!
>
> I have update the PR as well.
>
> I added a more generic/abstract spec, that does not talk about
> specific implementations details of a certain SDK.
>
> -Matthias
>
> On Thu, Jan 17, 2013 at 10:28 AM, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
>> I've just updated the PR with a new "usage" page based on the comparison
>> gist we had.
>> I
>>
>>
>> On Wed, Jan 16, 2013 at 11:24 PM, Summers Pittman <supittma(a)redhat.com>
>> wrote:
>>>
>>> https://github.com/aerogear/aerogear.org/pull/27
>>>
>>> I am sure we will have lots of discussion about this too, but it is a
>>> distillation of all our ideas that worked out.
>>>
>>> I contributed it to the aerogear repo so feel free to poke it.
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
10 years, 2 months
Client Paging Spec: 'where' parameter
by Daniel Bevenius
Hi,
I've been reading through the client side spec and it looks great!
I was a litte confused about the 'where' property in the spec.
I think this came from one of the earlier gists, where the example was
passing a request query parameter named 'brand'. Now, there is nothing
wrong in doing this, but it would be an implementation specific detail for
the endpoint in question and nothing related to paging.
Perhaps we should remove this from the paging spec to avoid confusion?
/Dan
10 years, 2 months
Re: [aerogear-dev] Client Paging Strawman
by Kris Borchers
-----Original Message-----
From: qmx(a)qmx.me
Received: Wednesday, 16 Jan 2013, 3:40pm
To: AeroGear Developer Mailing List [aerogear-dev(a)lists.jboss.org]
Subject: Re: [aerogear-dev] Client Paging Strawman
On Wed, Jan 16, 2013 at 03:29:13PM -0600, Kris Borchers wrote:
> Maybe this is a server implementation thing or maybe a non-issue and I'm just being dense but how would I get the last page as soon as my app loads without doing two read() requests? I can get the first page by just adding a firstPage (just and example name) config param to my paged pipe but I have no idea what the last page would be at that point. Thoughts?
One thing that we need to keep in mind (and one of the reasons I've been avoiding putting first and last) is that sometimes the server isn't that efficient on returning the size of the target collection - or you can even get an API that paginates in an "endless" fashion. That said, I would avoid trying to put shorthands to the last page.
Agreed. Also, I would say if we're leaving out last we should leave out first.
-- qmx
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
10 years, 2 months
JS pipe ctor for paging (was: Re: Client Paging Strawman)
by Matthias Wessendorf
on the IRC I asked this:
MW: https://gist.github.com/4539188 - when creating a pipe, with the
'paged' settings - I could apply the offset/limit there too, or "just" via
updatePageConfig() invocation ?
KB: the point of that gist was to sort out the differences in read()
between the libs so i left it out.
MW: thanks
-M
On Wed, Jan 16, 2013 at 3:21 PM, Matthias Wessendorf <matzew(a)apache.org>wrote:
>
>
> On Wed, Jan 16, 2013 at 3:01 PM, Kris Borchers <kris(a)redhat.com> wrote:
>
>>
>> On Jan 16, 2013, at 7:58 AM, Bruno Oliveira <bruno(a)abstractj.org> wrote:
>>
>> If the data doesn't exist HTTP 204 is a good fit. Just don't understand
>> why we need to interrupt the app workflow, because the data doesn't exist.
>>
>>
>> I would prefer that an exception is thrown client side before a request
>> is ever sent to the server. That way we save the http request which is
>> important on mobile.
>>
>
> Ah! yeah - good point -> since the "paging API" knows there is no "next"
> (for instance)
>
>
>>
>> That being said, then the issue becomes what if that page does exist but
>> we don't allow the request because the data was updated since our last
>> read? Then we wouldn't know without another read happening.
>>
>
> yeah - here could the 2.x targeted feature of 'sync' come in...
>
>
>>
>> Hmmm, interested in other opinions since relying on a 204 or any status
>> from the server couples the client to the server impl but if we don't allow
>> the request, that could also cause issues.
>>
>
> true :)
>
>
>>
>>
>> --
>> "The measure of a man is what he does with power" - Plato
>> -
>> @abstractj
>> -
>> Volenti Nihil Difficile
>>
>>
>>
>> On Wednesday, January 16, 2013 at 11:52 AM, Matthias Wessendorf wrote:
>>
>>
>> On Wed, Jan 16, 2013 at 2:48 PM, Kris Borchers <kris(a)redhat.com (
>> mailto:kris@redhat.com <kris(a)redhat.com>)> wrote:
>>
>> I would say returning the current page would be confusing. I would be
>> fine with an exception or returning null as both can be handled pretty
>> easily by a dev. I would say an exception may be more useful since it will
>> tell the dev exactly what was wrong instead of their app choking in a null
>> return but I am open to both.
>>
>>
>> For offset > totalNbPages :
>> - throwing an exception ?
>> - returning null ?
>> - returning last page ?
>>
>>
>>
>>
>> I would say same as above. Returning last page may be confusing but
>> others are acceptable with a preference toward an exception.
>>
>>
>>
>> +1 on an exception
>>
>> -M
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org (mailto:aerogear-dev@lists.jboss.org<aerogear-dev(a)lists.jboss.org>
>> )
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
10 years, 2 months
Client Paging API Unificaiton thread
by Summers Pittman
We agree:
The Pipe Implementation will have a read(<ConfigObject> , CallBack) method
Config Object will include pagining information
The biggest difference between our current proposals that I can see is
where and how are the calculations for Paging done and provided to the
developer.
In iOS and JS (from the examples) the User provides and updated
configObject with an "action" param to the read method. In Android the
response dataSet includes convenience methods which call the pipe using
the appropriate parameters.
Is that there actually is keeping us from having this thing nailed down?
10 years, 2 months
Proposal - Re: REST: auth: user registration endpoint
by Matthias Wessendorf
It was brought while discussing the "old" thread.
1) keep the clients to use "auth/enroll"
2) change the _library_ (ag-security) to follow the same pattern
3) keep the TODO (auth/register) and show that the clients can override the
default (shows the flexible API)
If we are all OK with this, I will file a JIRA for the ag-security change
and will move on with it.
-M
On Tue, Jan 15, 2013 at 7:21 AM, Daniel Bevenius
<daniel.bevenius(a)gmail.com>wrote:
> >So if a user wants to use our server-side bits, he always has to
> override for the registration - which is weird, IMO
> Yeah, that is true. And also we could simply provide examples in a user
> guide, so my point in the first post is not really valid.
> I'm changing my mind to +1 :)
>
>
>
>
>
> On 15 January 2013 07:15, Matthias Wessendorf <matzew(a)apache.org> wrote:
>
>> but aren't two different defaults an odd API ?
>>
>> So if a user wants to use our server-side bits, he always has to override
>> for the registration - which is weird, IMO
>>
>> -M
>>
>>
>> On Tue, Jan 15, 2013 at 6:57 AM, Daniel Bevenius <
>> daniel.bevenius(a)gmail.com> wrote:
>>
>>> >is your -1 only for the TODO demo app, or also for the ag-security
>>> library?
>>> I think we could keep the server side in the both the TODO app and
>>> ag-security as is, and have overrides in the client examples which might be
>>> useful for users to see examples of.
>>>
>>>
>>> On 15 January 2013 06:45, Matthias Wessendorf <matzew(a)apache.org> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Jan 15, 2013 at 6:09 AM, Daniel Bevenius <
>>>> daniel.bevenius(a)gmail.com> wrote:
>>>>
>>>>> -1 Let the client override this. I think it might be nice to show that
>>>>> this can be overriden and have an example to point users to.
>>>>>
>>>>
>>>>
>>>> is your -1 only for the TODO demo app, or also for the ag-security
>>>> library?
>>>>
>>>> -M
>>>>
>>>>
>>>>
>>>>>
>>>>> I've created https://issues.jboss.org/browse/AEROGEAR-816 so that we
>>>>> can track this.
>>>>>
>>>>>
>>>>>
>>>>> On 14 January 2013 20:39, Douglas Campos <qmx(a)qmx.me> wrote:
>>>>>
>>>>>> nice idea
>>>>>>
>>>>>> -1 to TODO changing
>>>>>>
>>>>>> On 14/01/2013, at 16:54, Summers Pittman <supittma(a)redhat.com> wrote:
>>>>>>
>>>>>> > +1 on having security be enroll.
>>>>>> >
>>>>>> > -1 on having TODO be enroll. This is because the TODO app should
>>>>>> > demonstrate that there is the ability to change things.
>>>>>> >
>>>>>> > On 01/14/2013 01:50 PM, Kris Borchers wrote:
>>>>>> >> +1
>>>>>> >>
>>>>>> >> On Jan 14, 2013, at 12:49 PM, Matthias Wessendorf <
>>>>>> matzew(a)apache.org> wrote:
>>>>>> >>
>>>>>> >>> Hi,
>>>>>> >>>
>>>>>> >>> our client libries are using the "auth/enroll" value for the
>>>>>> actual
>>>>>> >>> registration request, examples:
>>>>>> >>> -
>>>>>> https://github.com/aerogear/aerogear-ios/blob/master/AeroGear-iOS/AeroGea...
>>>>>> >>> -
>>>>>> https://github.com/aerogear/aerogear-js/blob/master/src/authentication/ad...
>>>>>> >>> -
>>>>>> https://github.com/aerogear/aerogear-android/blob/master/src/org/jboss/ae...
>>>>>> >>>
>>>>>> >>> However, the server uses a different default ("auth/register"):
>>>>>> >>> -
>>>>>> https://github.com/aerogear/aerogear-security/blob/master/src/main/java/o...
>>>>>> >>> -
>>>>>> https://github.com/aerogear/TODO/blob/master/server/src/main/java/org/aer...
>>>>>> >>>
>>>>>> >>> It was a decision from the past, that we have this "model",
>>>>>> however -
>>>>>> >>> rethinking causes some concerns... Is that really ideal? Wouldn't
>>>>>> it
>>>>>> >>> be just
>>>>>> >>> better to have matching default, on the client AND the server ?
>>>>>> >>>
>>>>>> >>> Please vote:
>>>>>> >>> [+1] let's change the server default to match the "enroll" setting
>>>>>> >>> from the client libraries
>>>>>> >>> [0] I don't care
>>>>>> >>> [-1] nah, let's keep all as is, since the client can override
>>>>>> everything
>>>>>> >>>
>>>>>> >>>
>>>>>> >>> Cheers!
>>>>>> >>> Matthias
>>>>>> >>>
>>>>>> >>> --
>>>>>> >>> Matthias Wessendorf
>>>>>> >>>
>>>>>> >>> blog: http://matthiaswessendorf.wordpress.com/
>>>>>> >>> sessions: http://www.slideshare.net/mwessendorf
>>>>>> >>> twitter: http://twitter.com/mwessendorf
>>>>>> >>> _______________________________________________
>>>>>> >>> aerogear-dev mailing list
>>>>>> >>> aerogear-dev(a)lists.jboss.org
>>>>>> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>> >>
>>>>>> >> _______________________________________________
>>>>>> >> aerogear-dev mailing list
>>>>>> >> aerogear-dev(a)lists.jboss.org
>>>>>> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>> >
>>>>>> > _______________________________________________
>>>>>> > aerogear-dev mailing list
>>>>>> > aerogear-dev(a)lists.jboss.org
>>>>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> aerogear-dev mailing list
>>>>>> aerogear-dev(a)lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Matthias Wessendorf
>>>>
>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>> sessions: http://www.slideshare.net/mwessendorf
>>>> twitter: http://twitter.com/mwessendorf
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
10 years, 2 months
