<div dir="ltr"><div style><div>OK, with the following server API:</div><div><br></div><div><a href="http://some.server.com/posts/1">http://some.server.com/posts/1</a></div><div><a href="http://some.server.com/posts/1/comments">http://some.server.com/posts/1/comments</a></div>
<div>(and NO &#39;comments&#39; collection on the &#39;<a href="http://some.server.com/posts/1">http://some.server.com/posts/1</a>&#39; response)</div><div><br></div><div>Does this (today) &#39;myPipe.read(1)&#39; already read the specific comments (<a href="http://some.server.com/posts/1/comments">http://some.server.com/posts/1/comments</a>) ??</div>
<div><br></div><div>======= JAVA API =======</div><div>Class Post:</div><div>- string: id;</div><div>- string: title;</div><div>- string: postContent;</div><div>- List&lt;Comment&gt; comments;</div><div>Class Comment:</div>
<div>- string username;</div><div>- string comment;</div><div><br></div><div>Or would the IMPL expect an &#39;embedded&#39; _comments_ collection on the response of &quot;GET <a href="http://some.server.com/posts/1">http://some.server.com/posts/1</a>&quot; ?</div>
<div><br></div></div><div><div><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 8, 2013 at 7:05 PM, Summers Pittman <span dir="ltr">&lt;<a href="mailto:supittma@redhat.com" target="_blank">supittma@redhat.com</a>&gt;</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">No. The get of pipe 1 would have to include the comments for get comments to work<br>

<br>
Sent from my Android phone using TouchDown (<a href="http://www.nitrodesk.com" target="_blank">www.nitrodesk.com</a>)<br>
<div class=""><div class="h5"><br>
<br>
-----Original Message-----<br>
From: Matthias Wessendorf [<a href="mailto:matzew@apache.org">matzew@apache.org</a>]<br>
Received: Monday, 08 Apr 2013, 12:04PM<br>
To: AeroGear Developer Mailing List [<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a>]<br>
Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for nested endpoints<br>
<br>
<br>
On Mon, Apr 8, 2013 at 5:57 PM, Summers Pittman &lt;<a href="mailto:supittma@redhat.com">supittma@redhat.com</a>&gt; wrote:<br>
<br>
&gt;<br>
&gt;<br>
&gt; ----- Original Message -----<br>
&gt; | From: &quot;Matthias Wessendorf&quot; &lt;<a href="mailto:matzew@apache.org">matzew@apache.org</a>&gt;<br>
&gt; | To: &quot;AeroGear Developer Mailing List&quot; &lt;<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a>&gt;<br>
&gt; | Sent: Monday, April 8, 2013 10:28:46 AM<br>
&gt; | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for nested<br>
&gt; endpoints<br>
&gt; |<br>
&gt; | or, like before said - reading &quot;lists&quot; (e.g. all the comments for<br>
&gt; specific<br>
&gt; | blog post):<br>
&gt; | <a href="https://gist.github.com/matzew/04f069dfbed2cc77a8b4" target="_blank">https://gist.github.com/matzew/04f069dfbed2cc77a8b4</a><br>
&gt; |<br>
&gt; |<br>
&gt; | For Java.... I guess...... resolving this URL:<br>
&gt; | <a href="http://some.server.com/posts/1/comments" target="_blank">http://some.server.com/posts/1/comments</a><br>
&gt; |<br>
&gt; | could be done with this - right ?<br>
&gt; |<br>
&gt; | =======<br>
&gt; | Class Post:<br>
&gt; | - string: title;<br>
&gt; | - string: postContent;<br>
&gt; | - List&lt;Comment&gt; comments;<br>
&gt; | Class Comment:<br>
&gt; | - string username;<br>
&gt; | - string comment;<br>
&gt; |<br>
&gt; |<br>
&gt; | // get all the comments for 1:<br>
&gt; | Post myPostOne = postPipe.read(&quot;1&quot;);<br>
&gt; | myPostOne.getComments();<br>
&gt; |<br>
&gt; | // get all the comments for 2:<br>
&gt; | Post myPostTwo = postPipe.read(&quot;2&quot;);<br>
&gt; | myPostTwo.getComments();<br>
&gt; | =======<br>
&gt;<br>
&gt; It can be done with that yes.  My concern was more when we had a Pipe of<br>
&gt; type &lt;Post&gt; and a readForResource(String property)  method.<br>
<br>
<br>
Ok - one more question<br>
<br>
<br>
So... when doing: myPipe.read(1); does that &quot;only&quot; issue a GET against the &#39;<br>
 <a href="http://some.server.com/posts/1" target="_blank">http://some.server.com/posts/1</a>&#39; resource?<br>
<br>
A second get, for the comments collection is than issued when calling<br>
myPostOne.getComments();?<br>
(GET against &#39; <a href="http://some.server.com/posts/1/comments&#39;" target="_blank">http://some.server.com/posts/1/comments&#39;</a>)?<br>
<br>
<br>
<br>
<br>
&gt;  The type information of the property isn&#39;t available unless we can infer<br>
&gt; it from the Post object.<br>
&gt;<br>
<br>
<br>
<br>
<br>
<br>
&gt;<br>
&gt;<br>
&gt; |<br>
&gt; |<br>
&gt; | Greetings,<br>
&gt; | Matthias<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; | On Fri, Apr 5, 2013 at 2:37 PM, Matthias Wessendorf &lt; <a href="mailto:matzew@apache.org">matzew@apache.org</a>&gt;<br>
&gt; | wrote:<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; | Thought a bit more about it and chatted with friends,<br>
&gt; |<br>
&gt; | the issue with the sub pipes is: it adds state and is perhaps an API<br>
&gt; | construct that is a bit hard to understand (see all the discussions here)<br>
&gt; |<br>
&gt; | Not sure - but currently we can access &quot;kid resources&quot;, with our API -<br>
&gt; right<br>
&gt; | ?<br>
&gt; |<br>
&gt; | <a href="https://gist.github.com/matzew/6ab432e437b9a017a21d" target="_blank">https://gist.github.com/matzew/6ab432e437b9a017a21d</a><br>
&gt; |<br>
&gt; |<br>
&gt; | Perhaps it&#39;s better to just keep it that way? This has the benefit of<br>
&gt; using<br>
&gt; | an established and know API, the different pipes are accessible via the<br>
&gt; | pipeline object;<br>
&gt; |<br>
&gt; | And the code is not too much code; it&#39;s simply an explicit pipe ...<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; | On Fri, Apr 5, 2013 at 10:56 AM, Matthias Wessendorf &lt; <a href="mailto:matzew@apache.org">matzew@apache.org</a>&gt;<br>
&gt; | wrote:<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; | On Fri, Apr 5, 2013 at 10:52 AM, Sebastien Blanc &lt; <a href="mailto:scm.blanc@gmail.com">scm.blanc@gmail.com</a> &gt;<br>
&gt; | wrote:<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; | On Fri, Apr 5, 2013 at 10:36 AM, Matthias Wessendorf &lt; <a href="mailto:matzew@apache.org">matzew@apache.org</a>&gt;<br>
&gt; | wrote:<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; | On Fri, Apr 5, 2013 at 10:14 AM, Christos Vasilakis &lt; <a href="mailto:cvasilak@gmail.com">cvasilak@gmail.com</a>&gt;<br>
&gt; | wrote:<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; | Hi<br>
&gt; |<br>
&gt; | some comments<br>
&gt; |<br>
&gt; | I believe the method can&#39;t be used since you don&#39;t know the team for the<br>
&gt; | players so you can&#39;t retrieve the pipe directly..right?<br>
&gt; |<br>
&gt; | Isn&#39;t that really up to the impl of the rest service?<br>
&gt; | They could return a list of teamsHePlayed for;<br>
&gt; |<br>
&gt; | So, let&#39;s not tie this API to a specific, not existing RESTful service;<br>
&gt; |<br>
&gt; | +1, we don&#39;t need to care about that, we must just focus on how we can<br>
&gt; | declare and call nested pipes.<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; | yep<br>
&gt; |<br>
&gt; | I guess this is perhaps the closest we can come to :<br>
&gt; |<br>
&gt; | id&lt;AGPipe&gt; allOwnersInNewYorkPipe = [leaguesPipe subPipe:@&quot;owners&quot;<br>
&gt; | for:@&quot;newyork&quot;];<br>
&gt; |<br>
&gt; | and than.... on the &#39;leaguesPipe&#39; you can access its kids with something<br>
&gt; like<br>
&gt; | :<br>
&gt; |<br>
&gt; | NSArray* kids = [leaguesPipe subPipes];<br>
&gt; |<br>
&gt; |<br>
&gt; | However, that adds some state to a specific pipe object<br>
&gt; |<br>
&gt; |<br>
&gt; | -M<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; | getPlayers ( Callback &lt; List &lt; Player &gt;&gt; callback ) {<br>
&gt; | pipe . get ( &quot;player&quot; ). read ( callback );<br>
&gt; | }<br>
&gt; |<br>
&gt; | Further my questions is, how is a third (or arbitrary) nested resources<br>
&gt; are<br>
&gt; | supported? I mean for a url schema like this<br>
&gt; |<br>
&gt; | <a href="http://soccer.org/leagues/" target="_blank">soccer.org/leagues/</a> {id}/teams/{id}/players/{id}<br>
&gt; |<br>
&gt; | first we access the leagues:<br>
&gt; | ---<br>
&gt; | getLeagues(Callback&lt;List&lt;Leagues&gt;&gt; callback) {<br>
&gt; | pipe.get(&quot;leagues&quot;).read(callback);<br>
&gt; | }<br>
&gt; | ---<br>
&gt; | then the teams for this league:<br>
&gt; | ---<br>
&gt; | getTeamsOnLeaque(Leaque league, Callback&lt;List&lt;Team&gt;&gt; callback) {<br>
&gt; | pipe.junction(&quot;league&quot;,&quot;team&quot;).read(leaque, callback);<br>
&gt; | }<br>
&gt; | ---<br>
&gt; | ..and then we access the &quot;Players&quot; for a &quot;Team&quot;:<br>
&gt; | ---<br>
&gt; | getPlayersOnTeam(Team team, Callback&lt;List&lt;Player&gt;&gt; callback) {<br>
&gt; | pipe.junction(&quot;team&quot;,&quot;player&quot;).read(team, callback);<br>
&gt; | }<br>
&gt; | ---<br>
&gt; | But where is the &quot;League&quot; information to fill the &quot;/leagues/{id}...&quot;<br>
&gt; path?<br>
&gt; |<br>
&gt; |<br>
&gt; | I&#39;d assume the information is &#39;inherited&#39; out of a given pipe, when<br>
&gt; doing the<br>
&gt; | &#39;join&#39;<br>
&gt; |<br>
&gt; | e.g. like<br>
&gt; | myTeamsForLeaguePipe = leaguePipe.junction(&quot;team&quot;);<br>
&gt; |<br>
&gt; | not sure...<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; | Unless you mean something like:<br>
&gt; | ---<br>
&gt; | getPlayersOnTeam(Leaque league, Team team, Callback&lt;List&lt;Player&gt;&gt;<br>
&gt; callback) {<br>
&gt; | pipe.junction(&quot;league&quot;, &quot;team&quot;,&quot;player&quot;).read(league, team, callback);<br>
&gt; | }<br>
&gt; |<br>
&gt; | I am not sure if that is really easy to understand/use<br>
&gt; |<br>
&gt; | Yes and the term &quot;junction&quot; is a bit confusing as it don&#39;t express<br>
&gt; explicitly<br>
&gt; | a parent/child relation.<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; | ---<br>
&gt; |<br>
&gt; | probably I am missing sth..<br>
&gt; |<br>
&gt; | Thanks,<br>
&gt; | Christos<br>
&gt; |<br>
&gt; | On Apr 4, 2013, at 5:52 PM, Summers Pittman &lt; <a href="mailto:supittma@redhat.com">supittma@redhat.com</a> &gt;<br>
&gt; wrote:<br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; | What if we create a new metaphor, a Junction.<br>
&gt; |<br>
&gt; | <a href="https://gist.github.com/secondsun/dcf5682b6ff17c729d9a" target="_blank">https://gist.github.com/secondsun/dcf5682b6ff17c729d9a</a><br>
&gt; |<br>
&gt; | It joins two pipes together and can be used over and over again with<br>
&gt; | different data?<br>
&gt; | It isn&#39;t a Pipe though, but perhaps that could be changed to look more<br>
&gt; like<br>
&gt; | Christos&#39;s previous example.<br>
&gt; |<br>
&gt; | At the very least I like the words &quot;junction&quot; or &quot;join&quot; more than &quot;of&quot;<br>
&gt; |<br>
&gt; | ----- Original Message -----<br>
&gt; | | From: &quot;Christos Vasilakis&quot; &lt; <a href="mailto:cvasilak@gmail.com">cvasilak@gmail.com</a> &gt;<br>
&gt; | | To: &quot;AeroGear Developer Mailing List&quot; &lt; <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a> &gt;<br>
&gt; | | Sent: Wednesday, April 3, 2013 3:03:02 AM<br>
&gt; | | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for nested<br>
&gt; | | endpoints<br>
&gt; | |<br>
&gt; | |<br>
&gt; | | On Apr 2, 2013, at 4:03 PM, Matthias Wessendorf &lt; <a href="mailto:matzew@apache.org">matzew@apache.org</a> &gt;<br>
&gt; | | wrote:<br>
&gt; | |<br>
&gt; | |<br>
&gt; | |<br>
&gt; | |<br>
&gt; | | Two thoughts....<br>
&gt; | |<br>
&gt; | | 1) the &#39;original&#39; leaguesPipe has no clue about the subpipes, right ?<br>
&gt; | | 2) should a pipe offer a &#39;getter&#39; for all it&#39;s sub pipes ?<br>
&gt; | |<br>
&gt; | |<br>
&gt; | | Just a thought is instead of using Pipe, to continue using Pipeline<br>
&gt; adding<br>
&gt; | | an<br>
&gt; | | extra parameter &quot; of&quot; for specifying the parent : E.g.:<br>
&gt; | |<br>
&gt; | | …..<br>
&gt; | | id&lt;AGPipe&gt; leaguesPipe = [pipeline pipe@&quot;leagues&quot;];<br>
&gt; | |<br>
&gt; | | id&lt;AGPipe&gt; allTeamsInSeattlePipe = [pipeline subPipe@&quot;teams&quot; of<br>
&gt; | | :leaguesPipe<br>
&gt; | | for:@&quot;seattle&quot;]<br>
&gt; | |<br>
&gt; | | id&lt;AGPipe&gt; allPlayersInTrebuchetPipe = [pipeline subPipe:@&quot;players&quot;<br>
&gt; of:<br>
&gt; | | allTeamsInSeattlePipe for:@&quot;trebuchet&quot;];<br>
&gt; | | …..<br>
&gt; | |<br>
&gt; | |<br>
&gt; | | Wdyt?<br>
&gt; | |<br>
&gt; | |<br>
&gt; | |<br>
&gt; | |<br>
&gt; | |<br>
&gt; | |<br>
&gt; | |<br>
&gt; | | -M<br>
&gt; | |<br>
&gt; | |<br>
&gt; | |<br>
&gt; | |<br>
&gt; | |<br>
&gt; | | Thanks,<br>
&gt; | | Christos<br>
&gt; | |<br>
&gt; | |<br>
&gt; | |<br>
&gt; | |<br>
&gt; | |<br>
&gt; | |<br>
&gt; | |<br>
&gt; | |<br>
&gt; | |<br>
&gt; | |<br>
&gt; | |<br>
&gt; | |<br>
&gt; | |<br>
&gt; | |<br>
&gt; | | <a href="http://soccer.org/leagues/seattle/teams/trebuchet/players/foo" target="_blank">soccer.org/leagues/seattle/teams/trebuchet/players/foo</a> - &gt;<br>
&gt; | | [[pipeline pipe:@&quot;players&quot; pathParams:@[@&quot;seattle&quot;, @&quot;trebuchet&quot;]]<br>
&gt; read<br>
&gt; | | :@&quot;foo&quot;] ..<br>
&gt; | | -----<br>
&gt; | |<br>
&gt; | |<br>
&gt; | | Wdyt?<br>
&gt; | |<br>
&gt; | | Thanks<br>
&gt; | | Christos<br>
&gt; | |<br>
&gt; | | On Mar 18, 2013, at 1:12 PM, Sebastien Blanc &lt; <a href="mailto:scm.blanc@gmail.com">scm.blanc@gmail.com</a> &gt;<br>
&gt; wrote:<br>
&gt; | |<br>
&gt; | |<br>
&gt; | |<br>
&gt; | | Well, that would not be possible, for that you will have to create a<br>
&gt; | | &quot;child&quot;<br>
&gt; | | pipe. But I agree, that is maybe no optimal ...<br>
&gt; | |<br>
&gt; | |<br>
&gt; | | On Fri, Mar 15, 2013 at 6:44 PM, Summers Pittman &lt; <a href="mailto:supittma@redhat.com">supittma@redhat.com</a>&gt;<br>
&gt; | | wrote:<br>
&gt; | |<br>
&gt; | |<br>
&gt; | |<br>
&gt; | | On 03/15/2013 01:34 PM, Sebastien Blanc wrote:<br>
&gt; | |<br>
&gt; | |<br>
&gt; | | I like the idea but I will more see that has a method/function for the<br>
&gt; | | pipelineManager (and will be easier to implement in JS, I think) :<br>
&gt; | |<br>
&gt; | | var myParentPipe =<br>
&gt; Aerogear.Pipeline({name:&quot;parentPipe&quot;}).pipes.parentPipe<br>
&gt; | |<br>
&gt; | | var myChildPipe = Aerogear.Pipeline.fromParent(myParentPipe, {options}<br>
&gt; )<br>
&gt; | | What would it look like to get a child record from a parent?<br>
&gt; | |<br>
&gt; | |<br>
&gt; | |<br>
&gt; | |<br>
&gt; | |<br>
&gt; | |<br>
&gt; | | On Fri, Mar 15, 2013 at 5:37 PM, Douglas Campos &lt; <a href="mailto:qmx@qmx.me">qmx@qmx.me</a> &gt; wrote:<br>
&gt; | |<br>
&gt; | |<br>
&gt; | | What about this?<br>
&gt; | |<br>
&gt; | | Pipeline&lt;Post&gt; postPipeline = …<br>
&gt; | | Post post = // get from the pipeline<br>
&gt; | | Pipeline&lt;Comment&gt;<br>
&gt; | | postPipeline.childPipelineForOrOtherWeirdName(Comment.class, post)<br>
&gt; | |<br>
&gt; | |<br>
&gt; | | On 15/03/2013, at 12:26, Summers Pittman &lt; <a href="mailto:supittma@redhat.com">supittma@redhat.com</a> &gt;<br>
&gt; wrote:<br>
&gt; | |<br>
&gt; | | &gt; On 03/14/2013 04:48 AM, Matthias Wessendorf wrote:<br>
&gt; | | &gt;&gt;<br>
&gt; | | &gt;&gt;<br>
&gt; | | &gt;&gt; On Thu, Mar 14, 2013 at 9:32 AM, Sebastien Blanc &lt;<br>
&gt; <a href="mailto:scm.blanc@gmail.com">scm.blanc@gmail.com</a> &gt;<br>
&gt; | | &gt;&gt; wrote:<br>
&gt; | | &gt;&gt; Hi,<br>
&gt; | | &gt;&gt; While I was playing with scaffolding and tried to build a simple<br>
&gt; Blog<br>
&gt; | | &gt;&gt; Application with Aerogear I faced the current situation :<br>
&gt; | | &gt;&gt; I have a Post object which contains many Comment objects. Now I<br>
&gt; want to<br>
&gt; | | &gt;&gt; call my Post pipe to retrieve the related comments, I have<br>
&gt; currently 2<br>
&gt; | | &gt;&gt; options :<br>
&gt; | | &gt;&gt;<br>
&gt; | | &gt;&gt; /posts/1 -&gt; assuming comments will be implicitly retrieved (eager<br>
&gt; | | &gt;&gt; loading)<br>
&gt; | | &gt;&gt; /comments/?postid=1<br>
&gt; | | &gt;&gt;<br>
&gt; | | &gt;&gt; But regarding our model the correct form should be :<br>
&gt; | | &gt;&gt;<br>
&gt; | | &gt;&gt; /posts/1/comments<br>
&gt; | | &gt;&gt;<br>
&gt; | | &gt;&gt;<br>
&gt; | | &gt;&gt; +1<br>
&gt; | | &gt;&gt; that is the ideal way to model URIs for &quot;nested&quot; resources.<br>
&gt; | | &gt;&gt;<br>
&gt; | | &gt;&gt; See [1], extracted from [2]<br>
&gt; | | &gt;&gt;<br>
&gt; | | &gt;&gt;<br>
&gt; | | &gt;&gt;<br>
&gt; | | &gt;&gt; But, AFAIK, with the current API, it is not possible to define this<br>
&gt; last<br>
&gt; | | &gt;&gt; pattern (at least for JS and iOs, confirmed by Matzew). When doing a<br>
&gt; | | &gt;&gt; read<br>
&gt; | | &gt;&gt; we can pass an id option but as mentioned in the doc, this id will<br>
&gt; | | &gt;&gt; always<br>
&gt; | | &gt;&gt; be append to the endpoint.<br>
&gt; | | &gt;&gt;<br>
&gt; | | &gt;&gt;<br>
&gt; | | &gt;&gt; Well, it is possible - but in a very (IMO) ugly way:<br>
&gt; | | &gt;&gt;<br>
&gt; | | &gt;&gt; <a href="https://gist.github.com/matzew/6ab432e437b9a017a21d" target="_blank">https://gist.github.com/matzew/6ab432e437b9a017a21d</a><br>
&gt; | | &gt;&gt;<br>
&gt; | | &gt;&gt;<br>
&gt; | | &gt;&gt;<br>
&gt; | | &gt;&gt;<br>
&gt; | | &gt;&gt; IMO, we should be able to support this pattern but for now I&#39;m not<br>
&gt; | | &gt;&gt; really<br>
&gt; | | &gt;&gt; sure how to specify this in our API, so if you have any ideas<br>
&gt; feedback<br>
&gt; | | &gt;&gt; this thread has been made for you !<br>
&gt; | | &gt;&gt;<br>
&gt; | | &gt;&gt;<br>
&gt; | | &gt;&gt;<br>
&gt; | | &gt;&gt; Suggestion: Enhance the read function - example:<br>
&gt; | | &gt;&gt;<br>
&gt; | | &gt;&gt; <a href="https://gist.github.com/matzew/04f069dfbed2cc77a8b4" target="_blank">https://gist.github.com/matzew/04f069dfbed2cc77a8b4</a><br>
&gt; | | &gt; I&#39;m thinking of the inverse myself. Add a &quot;ParentPath&quot; property<br>
&gt; which can<br>
&gt; | | &gt; be used to extract information from parent objects.<br>
&gt; | | &gt;<br>
&gt; | | &gt; <a href="https://gist.github.com/secondsun/17ce96082eda37dbd10e" target="_blank">https://gist.github.com/secondsun/17ce96082eda37dbd10e</a><br>
&gt; | | &gt;<br>
&gt; | | &gt;&gt;<br>
&gt; | | &gt;&gt;<br>
&gt; | | &gt;&gt; -Matthias<br>
&gt; | | &gt;&gt;<br>
&gt; | | &gt;&gt;<br>
&gt; | | &gt;&gt; [1]<br>
&gt; | | &gt;&gt;<br>
&gt; <a href="http://www.infoq.com/resource/articles/rest-introduction/en/resources/figure2.jpg" target="_blank">http://www.infoq.com/resource/articles/rest-introduction/en/resources/figure2.jpg</a><br>
&gt; | | &gt;&gt; [2] <a href="http://www.infoq.com/articles/rest-introduction" target="_blank">http://www.infoq.com/articles/rest-introduction</a><br>
&gt; | | &gt;&gt;<br>
&gt; | | &gt;&gt;<br>
&gt; | | &gt;&gt;<br>
&gt; | | &gt;&gt;<br>
&gt; | | &gt;&gt; Seb<br>
&gt; | | &gt;&gt;<br>
&gt; | | &gt;&gt;<br>
&gt; | | &gt;&gt; _______________________________________________<br>
&gt; | | &gt;&gt; aerogear-dev mailing list<br>
&gt; | | &gt;&gt; <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
&gt; | | &gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
&gt; | | &gt;&gt;<br>
&gt; | | &gt;&gt;<br>
&gt; | | &gt;&gt;<br>
&gt; | | &gt;&gt; --<br>
&gt; | | &gt;&gt; Matthias Wessendorf<br>
&gt; | | &gt;&gt;<br>
&gt; | | &gt;&gt; blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
&gt; | | &gt;&gt; sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
&gt; | | &gt;&gt; twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
&gt; | | &gt;&gt;<br>
&gt; | | &gt;&gt; _______________________________________________<br>
&gt; | | &gt;&gt; aerogear-dev mailing list<br>
&gt; | | &gt;&gt;<br>
&gt; | | &gt;&gt; <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
&gt; | | &gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
&gt; | | &gt;<br>
&gt; | | &gt; _______________________________________________<br>
&gt; | | &gt; aerogear-dev mailing list<br>
&gt; | | &gt; <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
&gt; | | &gt; <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
&gt; | |<br>
&gt; | | -- qmx<br>
&gt; | |<br>
&gt; | |<br>
&gt; | | _______________________________________________<br>
&gt; | | aerogear-dev mailing list<br>
&gt; | | <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
&gt; | | <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
&gt; | |<br>
&gt; | |<br>
&gt; | |<br>
&gt; | | _______________________________________________<br>
&gt; | | aerogear-dev mailing list <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
&gt; | | <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
&gt; | |<br>
&gt; | |<br>
&gt; | | _______________________________________________<br>
&gt; | | aerogear-dev mailing list<br>
&gt; | | <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
&gt; | | <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
&gt; | |<br>
&gt; | | _______________________________________________<br>
&gt; | | aerogear-dev mailing list<br>
&gt; | | <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
&gt; | | <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
&gt; | |<br>
&gt; | |<br>
&gt; | | _______________________________________________<br>
&gt; | | aerogear-dev mailing list<br>
&gt; | | <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
&gt; | | <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
&gt; | |<br>
&gt; | |<br>
&gt; | |<br>
&gt; | | --<br>
&gt; | | Matthias Wessendorf<br>
&gt; | |<br>
&gt; | | blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
&gt; | | sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
&gt; | | twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
&gt; | | _______________________________________________<br>
&gt; | | aerogear-dev mailing list<br>
&gt; | | <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
&gt; | | <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
&gt; | |<br>
&gt; | |<br>
&gt; | | _______________________________________________<br>
&gt; | | aerogear-dev mailing list<br>
&gt; | | <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
&gt; | | <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
&gt; | |<br>
&gt; | |<br>
&gt; | |<br>
&gt; | | --<br>
&gt; | | Matthias Wessendorf<br>
&gt; | |<br>
&gt; | | blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
&gt; | | sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
&gt; | | twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
&gt; | | _______________________________________________<br>
&gt; | | aerogear-dev mailing list<br>
&gt; | | <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
&gt; | | <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
&gt; | |<br>
&gt; | |<br>
&gt; | | _______________________________________________<br>
&gt; | | aerogear-dev mailing list<br>
&gt; | | <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
&gt; | | <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
&gt; |<br>
&gt; | _______________________________________________<br>
&gt; | aerogear-dev mailing list<br>
&gt; | <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
&gt; | <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
&gt; |<br>
&gt; |<br>
&gt; | _______________________________________________<br>
&gt; | aerogear-dev mailing list<br>
&gt; | <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
&gt; | <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; | --<br>
&gt; | Matthias Wessendorf<br>
&gt; |<br>
&gt; | blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
&gt; | sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
&gt; | twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
&gt; |<br>
&gt; | _______________________________________________<br>
&gt; | aerogear-dev mailing list<br>
&gt; | <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
&gt; | <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
&gt; |<br>
&gt; |<br>
&gt; | _______________________________________________<br>
&gt; | aerogear-dev mailing list<br>
&gt; | <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
&gt; | <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; | --<br>
&gt; | Matthias Wessendorf<br>
&gt; |<br>
&gt; | blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
&gt; | sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
&gt; | twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; | --<br>
&gt; | Matthias Wessendorf<br>
&gt; |<br>
&gt; | blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
&gt; | sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
&gt; | twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
&gt; |<br>
&gt; |<br>
&gt; |<br>
&gt; | --<br>
&gt; | Matthias Wessendorf<br>
&gt; |<br>
&gt; | blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
&gt; | sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
&gt; | twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
&gt; |<br>
&gt; | _______________________________________________<br>
&gt; | aerogear-dev mailing list<br>
&gt; | <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
&gt; | <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; aerogear-dev mailing list<br>
&gt; <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
&gt; <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
&gt;<br>
<br>
<br>
<br>
--<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><br>
</div></div><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></div></div>