On 01/15/2013 05:37 AM, Matthias Wessendorf wrote:

Hi Summers,

 
https://gist.github.com/4532661

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.


from your Andorid gist:

A) Once the response has been received, the Pipe implementation will return a List of objects. If this List instance is passed to Pipe.getPageContext the appropriate PageContext will be returned

Note: There is no 'return' - the readWithFilter is void, instead a Callback is invoked (onSuccess(list)), see Pipe.java

Yeah I totally fubarred that when I was putting together the gist.

B) The developer will receive from readWithFilter() a List of object. If she passes this list into Pipe.getPageContext(List result) she will receive the PageContext associated with this result.

Do you mean like:

...
myPipe.readWithFilter(filter, new Callback<List<Data>>() {
    @Override
    public void onSuccess(List<Data> data) {

        // get the PageContext:
    PageContext ctx = myPipe.getPageContext(data);
        ...
    }

    @Override
    public void onFailure(Exception e) {
    }
});

Not sure about that.....

But for iOS I am thinking about passing in the PageContext into the closure/block of the readWithFilter, like:

-(void) readWithFilter:(void (^)(id<AGFilterConf!
 ig<
span class="o" style="font-weight:bold">> config)) config
               success:(void (^)(id listOfObjects, id pageContext))success
               failure:(void (^)(NSError *error))failure;

A usage would look like:

    [pipe readWithFilter:^(id<AGFilterConfig> config) {
        // set the filter args and override the given defaults
    } success:^(id listOfObjects, id pageContext) {
        // work with the listOfObjects reponse.
        // for paging/query info, access the given pagecontext,
        // of the CURRENT request
        ...
    } failure:^(NSError *error) {
        // handle errorz
    }];

Any thoughts ?

I don't hate it.  I don't love it but I don't hate it.  On the one hand it makes where the pageContext comes from explicit and you get it with your request.  On the other hand you don't always a PageContext for a request so it will be something devs always have to drag around.

Not sure I like (or understand) the Pipe.getPageContext(List result) call. Current mindset is that thePageContext just (and only) belongs to the previous (executed) request... Not sure I want to support something like

// first call:
List<SomeType> first;
myPipe.readWithFilter(.....) // set first inside of callback
...
// second call:
List<SomeType> second;
myPipe.readWithFilter(.....) // set second inside of callback
...
// third call:
List<SomeType> third;
myPipe.readWithFilter(.....) // set third inside of callback
...


/// A BIT LATER ....:
myPipe.getPageContext(first); 

I am not sure if that (myPipe.getPageContext(first);) is really desired (or would even easily work, as it would need to store the "metadata").....

It easily works in Java land.  (To leak some implementation here look at WeakHashMap, the entries die when the keys die).

I'm open to suggestions because I am not in love with this method either.



Perhaps I am just wrong.


You are not wrong at all.

--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev