I think this all makes sense for JS. The impl might be slightly different, especially
since we won't have anything like readWithFilter but the spirit will be the same.
On Jan 18, 2013, at 8:54 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
On Fri, Jan 18, 2013 at 3:47 PM, Sebastien Blanc
<scm.blanc(a)gmail.com> wrote:
> +1 to 1) and 2) under the Pipe creation but also 3) , because if one has a
> custom impl for a pipe , he probably needs it for each read
Actually.... since NEXT does change the offset (from
https://gist.github.com/4537431):
My current "page" is
"https://localhost/demo/cars?offset=20&limit=10"
This means I get something like for next/prev:
<
https://localhost/demo/cars?offset=10&limit=10>; rel="previous",
<
https://localhost/demo/cars?offset=30&limit=10>; rel="next",
So... for iOS... the [next]; (or previous) would INTERNALLY do this:
[_pipe readWithFilter:^(id<AGFilterConfig> config) {
[config setLimit:_limit];
[config setOffset:_offset]; // got increased before
} success:success failure:failure];
So... I think this is already impl detail, but when there ARE no
meta-information for NEXT/PREV available,
the user has to maintain that himself.... so passing the (updated)
parameter provider on the read is nice....
Christos and I tend to do that for iOS. I guess Summers will be on the
same page (haha) with his Android code
-M
>
> Okay for PipeConfig.updateParameterProvider() but he should also be able to
> pass anytime through the read() to reconfigure , no ? doesn't hurt to have
> many options to reconfigure IMO
>
> Just a last remark on the "locations" name : metadataLocation and
> pagingLocation are not enough clear to me to see what's coming in and out,
> as suggested on IRC : metadataLocationResponse and metadataLocationRequest ?
>
>
>
>
> On Fri, Jan 18, 2013 at 3:38 PM, Matthias Wessendorf <matzew(a)apache.org>
> wrote:
>>
>> Looking at [1]
>>
>>
>> There is ONE detail left...
>>
>> The paging "config" contains the following settings:
>> 1) locations:
>> - metadataLocation
>> - pagingLocation
>> 2) param provider:
>> - my custom impl (like in
https://gist.github.com/4564403#comment-732025)
>> OR
>> - default (limit + offset)
>> 3) web linking:
>> - nextIdentifier
>> - previousIdentifier
>>
>>
>> Now... where to put these options? On the pipe, or on the actual
>> "paging read" (e.g. readWithFilter....).
>>
>> I can see that 1) and 3) are nice on the umbrella Pipe
>> definiton/creation. I can also see that it's OK to "install" a
"param
>> provider" on the pipe as well...
>>
>> If the "params" changes (for whatever reason), there could be a
>> "PipeConfig.updateParameterProvider()" hook....
>>
>> I also think..... the parameter provider can be defined on the actual
>> read (get request)....
>>
>> thoughts?
>>
>> -M
>>
>> [1]
>>
https://github.com/aerogear/aerogear.org/blob/client_paging_spec/docs/spe...
>>
>>
>>
>>
>> On Fri, Jan 18, 2013 at 2:53 PM, Matthias Wessendorf <matzew(a)apache.org>
>> wrote:
>>> solved... updating the spec
>>>
>>> On Fri, Jan 18, 2013 at 1:40 PM, Kris Borchers <kris(a)redhat.com>
wrote:
>>>>
>>>> On Jan 18, 2013, at 2:25 AM, Matthias Wessendorf
<matzew(a)apache.org>
>>>> wrote:
>>>>
>>>>> On Fri, Jan 18, 2013 at 6:33 AM, Matthias Wessendorf
>>>>> <matzew(a)apache.org> wrote:
>>>>>>> My suggestion is to name these two parameters something more
generic
>>>>>>> like locator/count where locator=page/offset and
count=limit/perPage. Then
>>>>>>> in our configs we would provide these options:
>>>>>>>
>>>>>>> pagingType {String} - determines the paging method to be used
in
>>>>>>> calculating next page, etc. and could be either
"offset" or "page", default
>>>>>>> "offset"
>>>>>>> locatorParam {String} - locator parameter name, default
"offset"
>>>>>>> locatorValue {Number} - page index or offset
>>>>>>> locatorIdentifier {String} - the locator identifier name,
default
>>>>>>> "AG-Paging-Offset"
>>>>>>> countParam {String} - count parameter name, default
"limit"
>>>>>>> countValue {Number} - items per page
>>>>>>> countIdentifier {String} - the count identifier name,
default
>>>>>>> "AG-Paging-Limit"
>>>>>>>
>>>>>>> Thoughts?
>>>>>
>>>>>
>>>>> OK.... I agree that you raised a valid concern, regarding that the
>>>>> client needs to indicate whether paging information is sent as
>>>>> headers, as query parameters, or as body data.
>>>>>
>>>>>
>>>>> But I still am not so sure if the above args are all really needed,
a
>>>>> ton of cfg params make it a bit fishy.
>>>>> How about, using the following as a default "parameter
provider"
>>>>> - offset (which sets the offset of the first element that should be
>>>>> included in the returned collection)
>>>>> - limit (the number of results that should be listed on a page)
>>>>>
>>>>> OK.
>>>>>
>>>>> Now if a user wants/needs to provide a different parameter schema
>>>>> (imagine his/her lame server requires/supports "page",
"perPage" and
>>>>> "sorting"):
>>>>> The developer could just create a custom impl (iOS: block, Java:
>>>>> anonymus class impl of an interface, JS: callback function) and pass
>>>>> it to the "paging request".
>>>>>
>>>>> that way the dev. could even add a ton of more params (if the lame
>>>>> backend requires that).
>>>>>
>>>>> since the pipe (or the paging request) knows whether the paging
>>>>> information is sent as headers, as query parameters, or as body
data,
>>>>> it would just "serialize" the give "param
provider" into the actual
>>>>> location.
>>>>
>>>> This is the part I don't understand so sorry if I'm the only one
being
>>>> dense here. I believe that is basically what we decided to do yesterday,
>>>> but, without that initial config, how do I make the initial request for
the
>>>> first page? Since the callback that the dev would provide isn't
triggered
>>>> until a successful read so that it can "build" the next/prev
methods based
>>>> on the response, how do I make that first request?
>>>>
>>>>>
>>>>> Any thoughts?
>>>>>
>>>>> -M
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> Any news on this ?
>>>>>>
>>>>>> -Matthias
>>>>>>
>>>>>>>
>>>>>>> On Jan 17, 2013, at 12:23 PM, Summers Pittman
<supittma(a)redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On 01/17/2013 11:37 AM, Matthias Wessendorf wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> based on today's IRC and mailing list
discussions, I have polished
>>>>>>>>> the
>>>>>>>>> client side paging spec:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
https://github.com/aerogear/aerogear.org/blob/client_paging_spec/docs/spe...
>>>>>>>>>
>>>>>>>>> Please review the document!
>>>>>>>>>
>>>>>>>>> Cheers!
>>>>>>>>> Matthias
>>>>>>>>>
>>>>>>>> +1, let's see how it works in actual implementation!
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>> _______________________________________________
>>>>> 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
>>
>> _______________________________________________
>> 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