<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 1, 2013 at 8:39 PM, Summers Pittman <span dir="ltr"><<a href="mailto:supittma@redhat.com" target="_blank">supittma@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">So the old thread was getting a bit long windy.<br>
<br>
Here are the current issues that are being discussed on nested endpoints<br>
(and things which we need to discuss before we move ahead on putting<br>
them in the Pipe spec)<br>
<br>
1. Saving and removing look really weird.<br>
pipe.remove(2,'/child/3', callback)<br>
vs<br>
pipe.remove(2, callback)<br>
<br>
The first removes an element in the child collection with an id 3 of<br>
parent with id 2. The second removes the parent with id 2. This really<br>
isn't THAT weird but it is a bit ugly.<br></blockquote><div><br></div><div><br></div><div style>Yeah, ugly and (a bit) weird (perhaps because it's ugly I think it's weird :))</div><div><br></div><div><br></div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
pipe.save(new Parent(), callback)<br>
vs<br>
pipe.save(new Child(), '2/child', callback)<br>
<br>
The first saves a new parent object but the second saves a new child<br>
under the parent with an id of 2.<br>
<br>
2. The type of Pipe breaks with nested resources as they are.<br>
<br>
In Android Pipe is parameterized with a type which correlates to the<br>
resource it represents. This type is serialized into an instance of the<br>
resource and the serialization mechanism does not change. For example<br>
<br>
Pipe<Parent> pipe = new RestAdapter<Parent>(URL, Parent.class);<br>
pipe.read(callback);<br>
<br>
Passes a instance of List<Parent> to the callback. With nested<br>
resources<br>
<br>
pipe.read('/child/2', callback);<br>
<br>
SHOULD pass a List<Child> to the callback. There are two ways to do<br>
this and both feel quite hackey.<br>
<br>
1) Use reflection to find the type of child and then use that class.<br>
The obvious problem with this is that a service may not return<br>
all of the children attached to a Parent if you ask for just the Parent<br>
(or all of the Parents) but the Parent class on Android would have to<br>
include it.<br>
2) Pass a type to the read operation.<br>
This is LESS hackey and possibly OK, except that we will have<br>
to add more configuration to the GSONdeserialization. The side effect<br>
of this means now we have to include serialization information about<br>
child types in the configuration of the Parent Pipe. At this point the<br>
user might as well just make a Child Pipe.<br></blockquote><div><br></div><div><br></div><div style>Ha!</div><div style>Good point!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
The same comments apply for save.<br>
<br>
Thoughts?<br></blockquote><div><br></div><div><br></div><div style>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 :-) )?</div>
<div style><br></div><div style>"Nested Resources" work already today, but it's perhaps (I am not really sure) a bit ugly (odd):</div><div style><br></div><div style><a href="https://gist.github.com/matzew/6ab432e437b9a017a21d">https://gist.github.com/matzew/6ab432e437b9a017a21d</a><br>
</div><div style><br></div><div style>-Matthias</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Summers<br>
<br>
_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Matthias Wessendorf <br><br>blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a>
</div></div>