[aerogear-dev] Client Paging Strawman

[Summers Pittman]

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 <https://gist.github.com/4532661>:
>
> 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 
> <https://github.com/aerogear/aerogear-android/blob/master/src/org/jboss/aerogear/android/pipeline/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<AGFilterConfig>  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 the|PageContext| 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130115/6bccb217/attachment-0001.html