<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">The nested endpoint/pipe idea is dead. It worked well for reading nested endpoints but save and delete on nested endpoints got too messy and can be accomplished with pipes the way they exist today.<div><br><div><div>On May 1, 2013, at 2:40 PM, Matthias Wessendorf <<a href="mailto:matzew@apache.org">matzew@apache.org</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><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>
_______________________________________________<br>aerogear-dev mailing list<br><a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/aerogear-dev</blockquote></div><br></div></body></html>