Kris Borchers kborchers

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 undefined, can also be "headers" or "content" to describe where to find the paging metadata, or undefined/false 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

Pipe uses default offset and limit so no need to define those, just tell it that it's paged via headers.

var pagedPipe = AeroGear.Pipeline({
    name: "cars",
    settings: {
        paged: "headers"
    }
}).pipes.cars;

Below is a comparison of the method usage proposed by each lib for handling paged resources.


	//FightCode can only understand your robot
	//if its class is called Robot
	var cloneId,
	Robot = function(robot) {
	var robot2 = robot.clone();
	cloneId = robot2.id;
	};

	Robot.prototype.onIdle = function(ev) {

	$.mockjax({
	url: "jsonpTest",
	type: "GET",
	response: function( settings ) {
	this.responseText = "{callback:\"" + settings.data.callback + "\"}";
	// or for custom callback
	this.responseText = "{jsonpOrWhatEverYouCallIt:\"" + settings.data.callback + "\"}";
	}
	});

	==> jbosseap-6.0/logs/server.log <==
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.6.0_24]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.6.0_24]
	at java.lang.reflect.Method.invoke(Method.java:616) [rt.jar:1.6.0_24]
	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167) [resteasy-jaxrs.jar:2.3.3.Final-redhat-1]
	at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:257) [resteasy-jaxrs.jar:2.3.3.Final-redhat-1]
	at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:222) [resteasy-jaxrs.jar:2.3.3.Final-redhat-1]
	at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:211) [resteasy-jaxrs.jar:2.3.3.Final-redhat-1]
	at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:525) [resteasy-jaxrs.jar:2.3.3.Final-redhat-1]
	... 26 more

	[14:06:02] <+sblanc>41 kborchers: is your biggest concern that read({some filters_options}) will return a "decorated" object containing next(), prev() etc functions ?
	[14:08:21] <@qmx> kborchers: I don't have any problems on diverging APIs
	[14:08:40] <@qmx> kborchers: but the spirit should be the same, bourbon & whisky don't mix well
	[14:08:46] <@qmx> :P
	[14:09:00] qmx always wanted to use this sentence
	[14:09:52] <+kborchers> sblanc: yes … basically. since a read is async, i am returning the deferred containing my callbacks which handle the different results of that deferred. i have no need to hang on to this but this change would require me to hang onto this and drag it around with me. then i effectively issue reads (next(), prev(), etc.) against that object instead of my pipe which seems wrong
	[14:09:55] <+abstractj> qmx++
	[14:09:56] <aerobot> qmx is on the rise! (Karma: 109)
	[14:10:18] <+kborchers> qmx: i also don't mind diverging APIs when necessary
	[14:10:21] <+kborchers> qmx: bourbon is whis


	This file contains a shell for the changelog, followed by a list of every commit for this release.

	Choose the appropriate line for the Summary section.

	Move all commit notes to the appropriate section.
	- Each line should be in the following format:
	[Fixed\|Added]: The ticket description. ([Ticket link], [Commit link])
	- If the commit is not related to a bug or feature, e.g., whitepsace cleanup, remove it.
	- If there is no ticket number, search Trac for the relevant ticket.

Kris Borchers kborchers

Read Next Page

Android

iOS

AG-Controller Pipe Setup

Android

iOS

	I'm pulling the conversation from IRC to this thread as I'm not sure if I'm explaining my issue with offset/limit properly.

	Basically, my concern is we can not choose one between offset/limit and page/perPage. The client libraries need to support both as both are popular server-side paging implementations. We also can't just use one of those names and have it work both ways since that would be confusing to developers.

	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"