[aerogear-dev] Nested endpoints (cont.)

[Matthias Wessendorf]

On Wed, May 1, 2013 at 8:39 PM, Summers Pittman <supittma at redhat.com> wrote:

> So the old thread was getting a bit long windy.
>
> Here are the current issues that are being discussed on nested endpoints
> (and things which we need to discuss before we move ahead on putting
> them in the Pipe spec)
>
> 1.  Saving and removing look really weird.
>      pipe.remove(2,'/child/3', callback)
>          vs
>      pipe.remove(2, callback)
>
>     The first removes an element in the child collection with an id 3 of
> parent with id 2.  The second removes the parent with id 2.  This really
> isn't THAT weird but it is a bit ugly.
>


Yeah, ugly and (a bit) weird (perhaps because it's ugly I think it's weird
:))




>
>     pipe.save(new Parent(), callback)
>      vs
>     pipe.save(new Child(), '2/child', callback)
>
>     The first saves a new parent object but the second saves a new child
> under the parent with an id of 2.
>
> 2. The type of Pipe breaks with nested resources as they are.
>
>    In Android Pipe is parameterized with a type which correlates to the
> resource it represents.  This type is serialized into an instance of the
> resource and the serialization mechanism does not change.  For example
>
>     Pipe<Parent> pipe = new RestAdapter<Parent>(URL, Parent.class);
>     pipe.read(callback);
>
>     Passes a instance of List<Parent> to the callback.  With nested
> resources
>
>     pipe.read('/child/2', callback);
>
>     SHOULD pass a List<Child> to the callback.  There are two ways to do
> this and both feel quite hackey.
>
>     1) Use reflection to find the type of child and then use that class.
>         The obvious problem with this is that a service may not return
> all of the children attached to a Parent if you ask for just the Parent
> (or all of the Parents) but the Parent class on Android would have to
> include it.
>     2) Pass a type to the read operation.
>          This is LESS hackey and possibly OK, except that we will have
> to add more configuration to the GSONdeserialization.  The side effect
> of this means now we have to include serialization information about
> child types in the configuration of the Parent Pipe.  At this point the
> user might as well just make a Child Pipe.
>


Ha!
Good point!


>
>    The same comments apply for save.
>
> Thoughts?
>


Not sure, but ... do we really need "nested endpoint" support on a pipe?
What do we gain, if it works? Is it worth it (already talking about this,
since quite a while  :-) )?

"Nested Resources" work already today, but it's perhaps (I am not really
sure) a bit ugly (odd):

https://gist.github.com/matzew/6ab432e437b9a017a21d

-Matthias



>
> Summers
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130501/75308752/attachment.html