On Thu, Mar 14, 2013 at 9:32 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: Hi, While I was playing with scaffolding and tried to build a simple Blog Application with Aerogear I faced the current situation : I have a Post object which contains many Comment objects. Now I want to call my Post pipe to retrieve the related comments, I have currently 2 options : /posts/1 -> assuming comments will be implicitly retrieved (eager loading) /comments/?postid=1 But regarding our model the correct form should be : /posts/1/comments +1 that is the ideal way to model URIs for "nested" resources.

See [1], extracted from [2] But, AFAIK, with the current API, it is not possible to define this last pattern (at least for JS and iOs, confirmed by Matzew). When doing a read we can pass an id option but as mentioned in the doc, this id will always be append to the endpoint. Well, it is possible - but in a very (IMO) ugly way: https://gist.github.com/matzew/6ab432e437b9a017a21d

IMO, we should be able to support this pattern but for now I'm not really sure how to specify this in our API, so if you have any ideas feedback this thread has been made for you ! Suggestion: Enhance the read function - example: https://gist.github.com/matzew/04f069dfbed2cc77a8b4

-Matthias [1] http://www.infoq.com/resource/articles/rest-introduction/en/resources/fig... [2] http://www.infoq.com/articles/rest-introduction Seb _______________________________________________ aerogear-dev mailing list aerogear-dev(a)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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Ok, Do we limit the depth to 1 ? Because in theory we could have /companies/1/teams/1/slackers On Thu, Mar 14, 2013 at 3:10 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > > On Mar 14, 2013, at 3:48 AM, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: > > > > On Thu, Mar 14, 2013 at 9:32 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt;wrote: > >> Hi, >> While I was playing with scaffolding and tried to build a simple Blog >> Application with Aerogear I faced the current situation : >> I have a *Post* object which contains many *Comment* objects. Now I >> want to call my Post pipe to retrieve the related comments, I have >> currently 2 options : >> * >> * >> */posts/1* -> assuming comments will be implicitly retrieved (eager >> loading) >> */comments/?postid=1* >> >> But regarding our model the correct form should be : >> >> */posts/1/comments* >> > > > +1 > that is the ideal way to model URIs for "nested" resources. > > > +1 > > > See [1], extracted from [2] > > > >> * >> * >> But, AFAIK, with the current API, it is not possible to define this >> last pattern (at least for JS and iOs, confirmed by Matzew). When doing a >> *read *we can pass an *id *option but as mentioned in the doc, this id >> will always be append to the endpoint. >> > > > Well, it is possible - but in a very (IMO) ugly way: > > https://gist.github.com/matzew/6ab432e437b9a017a21d > > > +1 - Ugly > > > > > >> >> IMO, we should be able to support this pattern but for now I'm not >> really sure how to specify this in our API, so if you have any ideas >> feedback this thread has been made for you ! >> > > > > Suggestion: Enhance the read function - example: > > https://gist.github.com/matzew/04f069dfbed2cc77a8b4 > > > +1 - So for JS we could just add a 'resource' (not crazy about that name) > option to the read options which, if present, would be tacked on to the url > after the id. > > > > -Matthias > > > [1] > http://www.infoq.com/resource/articles/rest-introduction/en/resources/fig... > [2] http://www.infoq.com/articles/rest-introduction > > > > >> >> Seb >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)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___________________________________________... > > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

I'll leave that decision to others. It would be easy enough for JS to just provide this as an object representing the nesting that I would just translate to a URI but it may not be that easy for others. On Mar 14, 2013, at 9:26 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > sure ... :) > > now you are addressing the entire graph ?! :) > > Well... not sure about something proper... > > On Thu, Mar 14, 2013 at 3:16 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > Ok, > Do we limit the depth to 1 ? > Because in theory we could have > > /companies/1/teams/1/slackers > > > > On Thu, Mar 14, 2013 at 3:10 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > > On Mar 14, 2013, at 3:48 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > >> >> >> On Thu, Mar 14, 2013 at 9:32 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >> Hi, >> While I was playing with scaffolding and tried to build a simple Blog Application with Aerogear I faced the current situation : >> I have a Post object which contains many Comment objects. Now I want to call my Post pipe to retrieve the related comments, I have currently 2 options : >> >> /posts/1 -> assuming comments will be implicitly retrieved (eager loading) >> /comments/?postid=1 >> >> But regarding our model the correct form should be : >> >> /posts/1/comments >> >> >> +1 >> that is the ideal way to model URIs for "nested" resources. > > +1 > >> >> See [1], extracted from [2] >> >> >> >> But, AFAIK, with the current API, it is not possible to define this last pattern (at least for JS and iOs, confirmed by Matzew). When doing a read we can pass an id option but as mentioned in the doc, this id will always be append to the endpoint. >> >> >> Well, it is possible - but in a very (IMO) ugly way: >> >> https://gist.github.com/matzew/6ab432e437b9a017a21d > > +1 - Ugly > >> >> >> >> >> IMO, we should be able to support this pattern but for now I'm not really sure how to specify this in our API, so if you have any ideas feedback this thread has been made for you ! >> >> >> >> Suggestion: Enhance the read function - example: >> >> https://gist.github.com/matzew/04f069dfbed2cc77a8b4 > > +1 - So for JS we could just add a 'resource' (not crazy about that name) option to the read options which, if present, would be tacked on to the url after the id. >> >> >> -Matthias >> >> >> [1] http://www.infoq.com/resource/articles/rest-introduction/en/resources/fig... >> [2] http://www.infoq.com/articles/rest-introduction >> >> >> >> >> Seb >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)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 _______________________________________________ >> >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Ok, Do we limit the depth to 1 ? Because in theory we could have /companies/1/teams/1/slackers

On Thu, Mar 14, 2013 at 3:10 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > > On Mar 14, 2013, at 3:48 AM, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: > > > > On Thu, Mar 14, 2013 at 9:32 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt;wrote: > >> Hi, >> While I was playing with scaffolding and tried to build a simple Blog >> Application with Aerogear I faced the current situation : >> I have a *Post* object which contains many *Comment* objects. Now I >> want to call my Post pipe to retrieve the related comments, I have >> currently 2 options : >> * >> * >> */posts/1* -> assuming comments will be implicitly retrieved (eager >> loading) >> */comments/?postid=1* >> >> But regarding our model the correct form should be : >> >> */posts/1/comments* >> > > > +1 > that is the ideal way to model URIs for "nested" resources. > > > +1 > > > See [1], extracted from [2] > > > >> * >> * >> But, AFAIK, with the current API, it is not possible to define this >> last pattern (at least for JS and iOs, confirmed by Matzew). When doing a >> *read *we can pass an *id *option but as mentioned in the doc, this id >> will always be append to the endpoint. >> > > > Well, it is possible - but in a very (IMO) ugly way: > > https://gist.github.com/matzew/6ab432e437b9a017a21d > > > +1 - Ugly > > > > > >> >> IMO, we should be able to support this pattern but for now I'm not >> really sure how to specify this in our API, so if you have any ideas >> feedback this thread has been made for you ! >> > > > > Suggestion: Enhance the read function - example: > > https://gist.github.com/matzew/04f069dfbed2cc77a8b4 > > > +1 - So for JS we could just add a 'resource' (not crazy about that name) > option to the read options which, if present, would be tacked on to the url > after the id. > > > > -Matthias > > > [1] > http://www.infoq.com/resource/articles/rest-introduction/en/resources/fig... > [2] http://www.infoq.com/articles/rest-introduction > > > > >> >> Seb >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)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___________________________________________... > > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On 03/14/2013 04:48 AM, Matthias Wessendorf wrote: > > > On Thu, Mar 14, 2013 at 9:32 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > Hi, > While I was playing with scaffolding and tried to build a simple Blog Application with Aerogear I faced the current situation : > I have a Post object which contains many Comment objects. Now I want to call my Post pipe to retrieve the related comments, I have currently 2 options : > > /posts/1 -> assuming comments will be implicitly retrieved (eager loading) > /comments/?postid=1 > > But regarding our model the correct form should be : > > /posts/1/comments > > > +1 > that is the ideal way to model URIs for "nested" resources. > > See [1], extracted from [2] > > > > But, AFAIK, with the current API, it is not possible to define this last pattern (at least for JS and iOs, confirmed by Matzew). When doing a read we can pass an id option but as mentioned in the doc, this id will always be append to the endpoint. > > > Well, it is possible - but in a very (IMO) ugly way: > > https://gist.github.com/matzew/6ab432e437b9a017a21d > > > > > IMO, we should be able to support this pattern but for now I'm not really sure how to specify this in our API, so if you have any ideas feedback this thread has been made for you ! > > > > Suggestion: Enhance the read function - example: > > https://gist.github.com/matzew/04f069dfbed2cc77a8b4 I'm thinking of the inverse myself. Add a "ParentPath" property which can be used to extract information from parent objects. https://gist.github.com/secondsun/17ce96082eda37dbd10e > > > -Matthias > > > [1] http://www.infoq.com/resource/articles/rest-introduction/en/resources/fig... > [2] http://www.infoq.com/articles/rest-introduction > > > > > Seb > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)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 > > _______________________________________________ > aerogear-dev mailing list > > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

What about this? Pipeline<Post> postPipeline = … Post post = // get from the pipeline Pipeline<Comment> postPipeline.childPipelineForOrOtherWeirdName(Comment.class, post)

On 15/03/2013, at 12:26, Summers Pittman <supittma(a)redhat.com&gt; wrote: > On 03/14/2013 04:48 AM, Matthias Wessendorf wrote: >> >> On Thu, Mar 14, 2013 at 9:32 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >> Hi, >> While I was playing with scaffolding and tried to build a simple Blog Application with Aerogear I faced the current situation : >> I have a Post object which contains many Comment objects. Now I want to call my Post pipe to retrieve the related comments, I have currently 2 options : >> >> /posts/1 -> assuming comments will be implicitly retrieved (eager loading) >> /comments/?postid=1 >> >> But regarding our model the correct form should be : >> >> /posts/1/comments >> >> >> +1 >> that is the ideal way to model URIs for "nested" resources. >> >> See [1], extracted from [2] >> >> >> >> But, AFAIK, with the current API, it is not possible to define this last pattern (at least for JS and iOs, confirmed by Matzew). When doing a read we can pass an id option but as mentioned in the doc, this id will always be append to the endpoint. >> >> >> Well, it is possible - but in a very (IMO) ugly way: >> >> https://gist.github.com/matzew/6ab432e437b9a017a21d >> >> >> >> >> IMO, we should be able to support this pattern but for now I'm not really sure how to specify this in our API, so if you have any ideas feedback this thread has been made for you ! >> >> >> >> Suggestion: Enhance the read function - example: >> >> https://gist.github.com/matzew/04f069dfbed2cc77a8b4 > I'm thinking of the inverse myself. Add a "ParentPath" property which can be used to extract information from parent objects. > > https://gist.github.com/secondsun/17ce96082eda37dbd10e > >> >> -Matthias >> >> >> [1] http://www.infoq.com/resource/articles/rest-introduction/en/resources/fig... >> [2] http://www.infoq.com/articles/rest-introduction >> >> >> >> >> Seb >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)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 >> >> _______________________________________________ >> aerogear-dev mailing list >> >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- qmx _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

I like the idea but I will more see that has a method/function for the pipelineManager (and will be easier to implement in JS, I think) : var myParentPipe = Aerogear.Pipeline({name:"parentPipe"}).pipes.parentPipe var myChildPipe = Aerogear.Pipeline.fromParent(myParentPipe, {options} )

On Fri, Mar 15, 2013 at 5:37 PM, Douglas Campos <qmx(a)qmx.me <mailto:qmx@qmx.me>> wrote: What about this? Pipeline<Post> postPipeline = ... Post post = // get from the pipeline Pipeline<Comment> postPipeline.childPipelineForOrOtherWeirdName(Comment.class, post) On 15/03/2013, at 12:26, Summers Pittman <supittma(a)redhat.com <mailto:supittma@redhat.com>> wrote: > On 03/14/2013 04:48 AM, Matthias Wessendorf wrote: >> >> >> On Thu, Mar 14, 2013 at 9:32 AM, Sebastien Blanc <scm.blanc(a)gmail.com <mailto:scm.blanc@gmail.com>> wrote: >> Hi, >> While I was playing with scaffolding and tried to build a simple Blog Application with Aerogear I faced the current situation : >> I have a Post object which contains many Comment objects. Now I want to call my Post pipe to retrieve the related comments, I have currently 2 options : >> >> /posts/1 -> assuming comments will be implicitly retrieved (eager loading) >> /comments/?postid=1 >> >> But regarding our model the correct form should be : >> >> /posts/1/comments >> >> >> +1 >> that is the ideal way to model URIs for "nested" resources. >> >> See [1], extracted from [2] >> >> >> >> But, AFAIK, with the current API, it is not possible to define this last pattern (at least for JS and iOs, confirmed by Matzew). When doing a read we can pass an id option but as mentioned in the doc, this id will always be append to the endpoint. >> >> >> Well, it is possible - but in a very (IMO) ugly way: >> >> https://gist.github.com/matzew/6ab432e437b9a017a21d >> >> >> >> >> IMO, we should be able to support this pattern but for now I'm not really sure how to specify this in our API, so if you have any ideas feedback this thread has been made for you ! >> >> >> >> Suggestion: Enhance the read function - example: >> >> https://gist.github.com/matzew/04f069dfbed2cc77a8b4 > I'm thinking of the inverse myself. Add a "ParentPath" property which can be used to extract information from parent objects. > > https://gist.github.com/secondsun/17ce96082eda37dbd10e > >> >> >> -Matthias >> >> >> [1] http://www.infoq.com/resource/articles/rest-introduction/en/resources/fig... >> [2] http://www.infoq.com/articles/rest-introduction >> >> >> >> >> Seb >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@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 >> >> _______________________________________________ >> aerogear-dev mailing list >> >> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- qmx _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On 03/15/2013 01:34 PM, Sebastien Blanc wrote: I like the idea but I will more see that has a method/function for the pipelineManager (and will be easier to implement in JS, I think) : var myParentPipe = Aerogear.Pipeline({name:"parentPipe"}).pipes.parentPipe var myChildPipe = Aerogear.Pipeline.fromParent(myParentPipe, {options} ) What would it look like to get a child record from a parent? On Fri, Mar 15, 2013 at 5:37 PM, Douglas Campos <qmx(a)qmx.me&gt; wrote: > What about this? > > Pipeline<Post> postPipeline = … > Post post = // get from the pipeline > Pipeline<Comment> > postPipeline.childPipelineForOrOtherWeirdName(Comment.class, post) > > > On 15/03/2013, at 12:26, Summers Pittman <supittma(a)redhat.com&gt; wrote: > > > On 03/14/2013 04:48 AM, Matthias Wessendorf wrote: > >> > >> > >> On Thu, Mar 14, 2013 at 9:32 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; > wrote: > >> Hi, > >> While I was playing with scaffolding and tried to build a simple Blog > Application with Aerogear I faced the current situation : > >> I have a Post object which contains many Comment objects. Now I want > to call my Post pipe to retrieve the related comments, I have currently 2 > options : > >> > >> /posts/1 -> assuming comments will be implicitly retrieved (eager > loading) > >> /comments/?postid=1 > >> > >> But regarding our model the correct form should be : > >> > >> /posts/1/comments > >> > >> > >> +1 > >> that is the ideal way to model URIs for "nested" resources. > >> > >> See [1], extracted from [2] > >> > >> > >> > >> But, AFAIK, with the current API, it is not possible to define this > last pattern (at least for JS and iOs, confirmed by Matzew). When doing a > read we can pass an id option but as mentioned in the doc, this id will > always be append to the endpoint. > >> > >> > >> Well, it is possible - but in a very (IMO) ugly way: > >> > >> https://gist.github.com/matzew/6ab432e437b9a017a21d > >> > >> > >> > >> > >> IMO, we should be able to support this pattern but for now I'm not > really sure how to specify this in our API, so if you have any ideas > feedback this thread has been made for you ! > >> > >> > >> > >> Suggestion: Enhance the read function - example: > >> > >> https://gist.github.com/matzew/04f069dfbed2cc77a8b4 > > I'm thinking of the inverse myself. Add a "ParentPath" property which > can be used to extract information from parent objects. > > > > https://gist.github.com/secondsun/17ce96082eda37dbd10e > > > >> > >> > >> -Matthias > >> > >> > >> [1] > http://www.infoq.com/resource/articles/rest-introduction/en/resources/fig... > >> [2] http://www.infoq.com/articles/rest-introduction > >> > >> > >> > >> > >> Seb > >> > >> > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev(a)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 > >> > >> _______________________________________________ > >> aerogear-dev mailing list > >> > >> aerogear-dev(a)lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > -- qmx > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ aerogear-dev mailing listaerogear-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Hi team, on the last couple of days I have been playing with the idea on how to support nested path in resources (a.k.a subresources). I am more keen in the idea to treat the nested resources as full-time citizens. That is, treat the nested resource as a Pipe.

I came up with the following proposal (showing here in iOS) For demonstration I use an imaginative Soccer API e.g. soccer.org/leagues/{id}/teams/{id}/players when expanded with sample {ids}: soccer.org/leagues/seattle/teams/trebuchet/players During registration of the "parent pipe" (leagues) we specify the nested resources for this Pipe using the "setNestedPipes" config option. Internally the Pipeline during the setup of this pipe creates the corresponding nested pipes, initialising their URL accordingly. e.g. ----- AGPipeline* pipeline = [AGPipeline pipelineWithBaseURL:BASE_SOCCER_APP_URL]; id<AGPipe> leagues = [pipeline pipe:^(id<AGPipeConfig> config) { [config setName:@"leagues"]; [config setNestedPipes:[@"teams", @"players"]; // an array of nested resources for this pipe

}]; ----- A new "pipe" method is added in the pipeline with params the Parent ID's of this nested resource. Once returned you have a fill Pipe to invoke operations on. ----- soccer.org/leagues/seattle/teams/trebuchet - > [[pipeline pipe:@"teams" pathParams:@[@"seattle"]] read:@"trebuchet"] ... soccer.org/leagues/seattle/teams/trebuchet/players/foo - > [[pipeline pipe:@"players" pathParams:@[@"seattle", @"trebuchet"]] read:@"foo"] .. ----- Wdyt? Thanks Christos On Mar 18, 2013, at 1:12 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > Well, that would not be possible, for that you will have to create a "child" pipe. But I agree, that is maybe no optimal ... > > > On Fri, Mar 15, 2013 at 6:44 PM, Summers Pittman <supittma(a)redhat.com&gt; wrote: > On 03/15/2013 01:34 PM, Sebastien Blanc wrote: >> I like the idea but I will more see that has a method/function for the pipelineManager (and will be easier to implement in JS, I think) : >> >> var myParentPipe = Aerogear.Pipeline({name:"parentPipe"}).pipes.parentPipe >> >> var myChildPipe = Aerogear.Pipeline.fromParent(myParentPipe, {options} ) > What would it look like to get a child record from a parent? > >> >> >> On Fri, Mar 15, 2013 at 5:37 PM, Douglas Campos <qmx(a)qmx.me&gt; wrote: >> What about this? >> >> Pipeline<Post> postPipeline = … >> Post post = // get from the pipeline >> Pipeline<Comment> postPipeline.childPipelineForOrOtherWeirdName(Comment.class, post) >> >> >> On 15/03/2013, at 12:26, Summers Pittman <supittma(a)redhat.com&gt; wrote: >> >> > On 03/14/2013 04:48 AM, Matthias Wessendorf wrote: >> >> >> >> >> >> On Thu, Mar 14, 2013 at 9:32 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >> >> Hi, >> >> While I was playing with scaffolding and tried to build a simple Blog Application with Aerogear I faced the current situation : >> >> I have a Post object which contains many Comment objects. Now I want to call my Post pipe to retrieve the related comments, I have currently 2 options : >> >> >> >> /posts/1 -> assuming comments will be implicitly retrieved (eager loading) >> >> /comments/?postid=1 >> >> >> >> But regarding our model the correct form should be : >> >> >> >> /posts/1/comments >> >> >> >> >> >> +1 >> >> that is the ideal way to model URIs for "nested" resources. >> >> >> >> See [1], extracted from [2] >> >> >> >> >> >> >> >> But, AFAIK, with the current API, it is not possible to define this last pattern (at least for JS and iOs, confirmed by Matzew). When doing a read we can pass an id option but as mentioned in the doc, this id will always be append to the endpoint. >> >> >> >> >> >> Well, it is possible - but in a very (IMO) ugly way: >> >> >> >> https://gist.github.com/matzew/6ab432e437b9a017a21d >> >> >> >> >> >> >> >> >> >> IMO, we should be able to support this pattern but for now I'm not really sure how to specify this in our API, so if you have any ideas feedback this thread has been made for you ! >> >> >> >> >> >> >> >> Suggestion: Enhance the read function - example: >> >> >> >> https://gist.github.com/matzew/04f069dfbed2cc77a8b4 >> > I'm thinking of the inverse myself. Add a "ParentPath" property which can be used to extract information from parent objects. >> > >> > https://gist.github.com/secondsun/17ce96082eda37dbd10e >> > >> >> >> >> >> >> -Matthias >> >> >> >> >> >> [1] http://www.infoq.com/resource/articles/rest-introduction/en/resources/fig... >> >> [2] http://www.infoq.com/articles/rest-introduction >> >> >> >> >> >> >> >> >> >> Seb >> >> >> >> >> >> _______________________________________________ >> >> aerogear-dev mailing list >> >> aerogear-dev(a)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 >> >> >> >> _______________________________________________ >> >> aerogear-dev mailing list >> >> >> >> aerogear-dev(a)lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > >> > _______________________________________________ >> > aerogear-dev mailing list >> > aerogear-dev(a)lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> -- qmx >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Thu, Mar 28, 2013 at 1:03 PM, Christos Vasilakis <cvasilak(a)gmail.com&gt; wrote: Hi team, on the last couple of days I have been playing with the idea on how to support nested path in resources (a.k.a subresources). I am more keen in the idea to treat the nested resources as full-time citizens. That is, treat the nested resource as a Pipe. I agree w/ Luke - interesting proposal I came up with the following proposal (showing here in iOS) For demonstration I use an imaginative Soccer API e.g. soccer.org/leagues/{id}/teams/{id}/players when expanded with sample {ids}: soccer.org/leagues/seattle/teams/trebuchet/players During registration of the "parent pipe" (leagues) we specify the nested resources for this Pipe using the "setNestedPipes" config option. Internally the Pipeline during the setup of this pipe creates the corresponding nested pipes, initialising their URL accordingly. e.g. ----- AGPipeline* pipeline = [AGPipeline pipelineWithBaseURL:BASE_SOCCER_APP_URL]; id<AGPipe> leagues = [pipeline pipe:^(id<AGPipeConfig> config) { [config setName:@"leagues"]; [config setNestedPipes:[@"teams", @"players"]; // an array of nested resources for this pipe I would read the nested pipes here as: * soccer.org/leagues/{id}/teams * soccer.org/leagues/{id}/players which does not match the above URL samples, you gave;

}]; ----- A new "pipe" method is added in the pipeline with params the Parent ID's of this nested resource. Once returned you have a fill Pipe to invoke operations on. ----- soccer.org/leagues/seattle/teams/trebuchet - > [[pipeline pipe:@"teams" pathParams:@[@"seattle"]] read:@"trebuchet"] ... Hrm..... I am confused... What is the name of the first argument? Also the path params, not sure about them…

I think this proposal differs from how we currently read a specific entry: (soccer.org/leagues/seattle) [leaguesPipe read:@"seattle" success:callback failure:othercallback]; So i guess ... the above would return details about the "Seattle League", right?

Now... I think... If I wanted a "sub"/"nested" pipe, from that leagues pipe (e.g. to work with teams in the "Seattle Leaguue" ... I think there are two ways... a) use the Pipeline as it's factory (I guess that's what you proposed) b) use the actual pipe to create a nested pipe, by leveraging the available information Here is, I think, how the b) could look for this URL: id<AGPipe> allTeamsInSeattlePipe = [leaguesPipe subPipe:@"teams" for:@"seattle"]; Now we have a subPipe that has this (inherited) URL: -> soccer.org/leagues/seattle/teams And, if I want to issue a a read against "soccer.org/leagues/seattle/teams/trebuchet" would look like: [allTeamsInSeattlePipe read:@"trebuchet" success:callback failure:othercallback]; Now, imagine the API could also return the owners of a certain lagues - the "sub pipe creation" could be done like: Here is, I think, how the b) could look for this URL: id<AGPipe> allOwnersInNewYorkPipe = [leaguesPipe subPipe:@"owners" for:@"newyork"]; Reading details about Mr. Brown (some owner in the list, that has the ID 19) would be like: [allOwnersInNewYorkPipe read:@"19" success:callback failure:othercallback]; So... this would match a read to: "soccer.org/leagues/newyork/owners/19" Does that make sense ? Any thoughts ?

soccer.org/leagues/seattle/teams/trebuchet/players/foo - > [[pipeline pipe:@"players" pathParams:@[@"seattle", @"trebuchet"]] read:@"foo"] .. ----- Wdyt? Thanks Christos On Mar 18, 2013, at 1:12 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > Well, that would not be possible, for that you will have to create a "child" pipe. But I agree, that is maybe no optimal ... > > > On Fri, Mar 15, 2013 at 6:44 PM, Summers Pittman <supittma(a)redhat.com&gt; wrote: > On 03/15/2013 01:34 PM, Sebastien Blanc wrote: >> I like the idea but I will more see that has a method/function for the pipelineManager (and will be easier to implement in JS, I think) : >> >> var myParentPipe = Aerogear.Pipeline({name:"parentPipe"}).pipes.parentPipe >> >> var myChildPipe = Aerogear.Pipeline.fromParent(myParentPipe, {options} ) > What would it look like to get a child record from a parent? > >> >> >> On Fri, Mar 15, 2013 at 5:37 PM, Douglas Campos <qmx(a)qmx.me&gt; wrote: >> What about this? >> >> Pipeline<Post> postPipeline = … >> Post post = // get from the pipeline >> Pipeline<Comment> postPipeline.childPipelineForOrOtherWeirdName(Comment.class, post) >> >> >> On 15/03/2013, at 12:26, Summers Pittman <supittma(a)redhat.com&gt; wrote: >> >> > On 03/14/2013 04:48 AM, Matthias Wessendorf wrote: >> >> >> >> >> >> On Thu, Mar 14, 2013 at 9:32 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >> >> Hi, >> >> While I was playing with scaffolding and tried to build a simple Blog Application with Aerogear I faced the current situation : >> >> I have a Post object which contains many Comment objects. Now I want to call my Post pipe to retrieve the related comments, I have currently 2 options : >> >> >> >> /posts/1 -> assuming comments will be implicitly retrieved (eager loading) >> >> /comments/?postid=1 >> >> >> >> But regarding our model the correct form should be : >> >> >> >> /posts/1/comments >> >> >> >> >> >> +1 >> >> that is the ideal way to model URIs for "nested" resources. >> >> >> >> See [1], extracted from [2] >> >> >> >> >> >> >> >> But, AFAIK, with the current API, it is not possible to define this last pattern (at least for JS and iOs, confirmed by Matzew). When doing a read we can pass an id option but as mentioned in the doc, this id will always be append to the endpoint. >> >> >> >> >> >> Well, it is possible - but in a very (IMO) ugly way: >> >> >> >> https://gist.github.com/matzew/6ab432e437b9a017a21d >> >> >> >> >> >> >> >> >> >> IMO, we should be able to support this pattern but for now I'm not really sure how to specify this in our API, so if you have any ideas feedback this thread has been made for you ! >> >> >> >> >> >> >> >> Suggestion: Enhance the read function - example: >> >> >> >> https://gist.github.com/matzew/04f069dfbed2cc77a8b4 >> > I'm thinking of the inverse myself. Add a "ParentPath" property which can be used to extract information from parent objects. >> > >> > https://gist.github.com/secondsun/17ce96082eda37dbd10e >> > >> >> >> >> >> >> -Matthias >> >> >> >> >> >> [1] http://www.infoq.com/resource/articles/rest-introduction/en/resources/fig... >> >> [2] http://www.infoq.com/articles/rest-introduction >> >> >> >> >> >> >> >> >> >> Seb >> >> >> >> >> >> _______________________________________________ >> >> aerogear-dev mailing list >> >> aerogear-dev(a)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 >> >> >> >> _______________________________________________ >> >> aerogear-dev mailing list >> >> >> >> aerogear-dev(a)lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > >> > _______________________________________________ >> > aerogear-dev mailing list >> > aerogear-dev(a)lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> -- qmx >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Two thoughts.... 1) the 'original' leaguesPipe has no clue about the subpipes, right ? 2) should a pipe offer a 'getter' for all it's sub pipes ?

-M Thanks, Christos > > > > > > > soccer.org/leagues/seattle/teams/trebuchet/players/foo - > > [[pipeline pipe:@"players" pathParams:@[@"seattle", @"trebuchet"]] read:@"foo"] .. > ----- > > > Wdyt? > > Thanks > Christos > > On Mar 18, 2013, at 1:12 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > >> Well, that would not be possible, for that you will have to create a "child" pipe. But I agree, that is maybe no optimal ... >> >> >> On Fri, Mar 15, 2013 at 6:44 PM, Summers Pittman <supittma(a)redhat.com&gt; wrote: >> On 03/15/2013 01:34 PM, Sebastien Blanc wrote: >>> I like the idea but I will more see that has a method/function for the pipelineManager (and will be easier to implement in JS, I think) : >>> >>> var myParentPipe = Aerogear.Pipeline({name:"parentPipe"}).pipes.parentPipe >>> >>> var myChildPipe = Aerogear.Pipeline.fromParent(myParentPipe, {options} ) >> What would it look like to get a child record from a parent? >> >>> >>> >>> On Fri, Mar 15, 2013 at 5:37 PM, Douglas Campos <qmx(a)qmx.me&gt; wrote: >>> What about this? >>> >>> Pipeline<Post> postPipeline = … >>> Post post = // get from the pipeline >>> Pipeline<Comment> postPipeline.childPipelineForOrOtherWeirdName(Comment.class, post) >>> >>> >>> On 15/03/2013, at 12:26, Summers Pittman <supittma(a)redhat.com&gt; wrote: >>> >>> > On 03/14/2013 04:48 AM, Matthias Wessendorf wrote: >>> >> >>> >> >>> >> On Thu, Mar 14, 2013 at 9:32 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >>> >> Hi, >>> >> While I was playing with scaffolding and tried to build a simple Blog Application with Aerogear I faced the current situation : >>> >> I have a Post object which contains many Comment objects. Now I want to call my Post pipe to retrieve the related comments, I have currently 2 options : >>> >> >>> >> /posts/1 -> assuming comments will be implicitly retrieved (eager loading) >>> >> /comments/?postid=1 >>> >> >>> >> But regarding our model the correct form should be : >>> >> >>> >> /posts/1/comments >>> >> >>> >> >>> >> +1 >>> >> that is the ideal way to model URIs for "nested" resources. >>> >> >>> >> See [1], extracted from [2] >>> >> >>> >> >>> >> >>> >> But, AFAIK, with the current API, it is not possible to define this last pattern (at least for JS and iOs, confirmed by Matzew). When doing a read we can pass an id option but as mentioned in the doc, this id will always be append to the endpoint. >>> >> >>> >> >>> >> Well, it is possible - but in a very (IMO) ugly way: >>> >> >>> >> https://gist.github.com/matzew/6ab432e437b9a017a21d >>> >> >>> >> >>> >> >>> >> >>> >> IMO, we should be able to support this pattern but for now I'm not really sure how to specify this in our API, so if you have any ideas feedback this thread has been made for you ! >>> >> >>> >> >>> >> >>> >> Suggestion: Enhance the read function - example: >>> >> >>> >> https://gist.github.com/matzew/04f069dfbed2cc77a8b4 >>> > I'm thinking of the inverse myself. Add a "ParentPath" property which can be used to extract information from parent objects. >>> > >>> > https://gist.github.com/secondsun/17ce96082eda37dbd10e >>> > >>> >> >>> >> >>> >> -Matthias >>> >> >>> >> >>> >> [1] http://www.infoq.com/resource/articles/rest-introduction/en/resources/fig... >>> >> [2] http://www.infoq.com/articles/rest-introduction >>> >> >>> >> >>> >> >>> >> >>> >> Seb >>> >> >>> >> >>> >> _______________________________________________ >>> >> aerogear-dev mailing list >>> >> aerogear-dev(a)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 >>> >> >>> >> _______________________________________________ >>> >> aerogear-dev mailing list >>> >> >>> >> aerogear-dev(a)lists.jboss.org >>> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> > >>> > _______________________________________________ >>> > aerogear-dev mailing list >>> > aerogear-dev(a)lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> -- qmx >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Interesting thoughts - but I am not sure if I like the "of" - feels a bit procedural :) Would be interested in other opinions on this -Matthias On Wed, Apr 3, 2013 at 9:03 AM, Christos Vasilakis <cvasilak(a)gmail.com&gt; wrote: On Apr 2, 2013, at 4:03 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > Two thoughts.... > > 1) the 'original' leaguesPipe has no clue about the subpipes, right ? > 2) should a pipe offer a 'getter' for all it's sub pipes ? > Just a thought is instead of using Pipe, to continue using Pipeline adding an extra parameter "of" for specifying the parent: E.g.: ….. id<AGPipe> leaguesPipe = [pipeline pipe@"leagues"]; id<AGPipe> allTeamsInSeattlePipe = [pipeline subPipe@"teams" of:leaguesPipe for:@"seattle"] id<AGPipe> allPlayersInTrebuchetPipe = [pipeline subPipe:@"players" of:allTeamsInSeattlePipe for:@"trebuchet"]; ….. Wdyt? > -M > > > > Thanks, > Christos > > > >> >> >> >> >> >> >> soccer.org/leagues/seattle/teams/trebuchet/players/foo - > >> [[pipeline pipe:@"players" pathParams:@[@"seattle", @"trebuchet"]] read:@"foo"] .. >> ----- >> >> >> Wdyt? >> >> Thanks >> Christos >> >> On Mar 18, 2013, at 1:12 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >> >>> Well, that would not be possible, for that you will have to create a "child" pipe. But I agree, that is maybe no optimal ... >>> >>> >>> On Fri, Mar 15, 2013 at 6:44 PM, Summers Pittman <supittma(a)redhat.com&gt; wrote: >>> On 03/15/2013 01:34 PM, Sebastien Blanc wrote: >>>> I like the idea but I will more see that has a method/function for the pipelineManager (and will be easier to implement in JS, I think) : >>>> >>>> var myParentPipe = Aerogear.Pipeline({name:"parentPipe"}).pipes.parentPipe >>>> >>>> var myChildPipe = Aerogear.Pipeline.fromParent(myParentPipe, {options} ) >>> What would it look like to get a child record from a parent? >>> >>>> >>>> >>>> On Fri, Mar 15, 2013 at 5:37 PM, Douglas Campos <qmx(a)qmx.me&gt; wrote: >>>> What about this? >>>> >>>> Pipeline<Post> postPipeline = … >>>> Post post = // get from the pipeline >>>> Pipeline<Comment> postPipeline.childPipelineForOrOtherWeirdName(Comment.class, post) >>>> >>>> >>>> On 15/03/2013, at 12:26, Summers Pittman <supittma(a)redhat.com&gt; wrote: >>>> >>>> > On 03/14/2013 04:48 AM, Matthias Wessendorf wrote: >>>> >> >>>> >> >>>> >> On Thu, Mar 14, 2013 at 9:32 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >>>> >> Hi, >>>> >> While I was playing with scaffolding and tried to build a simple Blog Application with Aerogear I faced the current situation : >>>> >> I have a Post object which contains many Comment objects. Now I want to call my Post pipe to retrieve the related comments, I have currently 2 options : >>>> >> >>>> >> /posts/1 -> assuming comments will be implicitly retrieved (eager loading) >>>> >> /comments/?postid=1 >>>> >> >>>> >> But regarding our model the correct form should be : >>>> >> >>>> >> /posts/1/comments >>>> >> >>>> >> >>>> >> +1 >>>> >> that is the ideal way to model URIs for "nested" resources. >>>> >> >>>> >> See [1], extracted from [2] >>>> >> >>>> >> >>>> >> >>>> >> But, AFAIK, with the current API, it is not possible to define this last pattern (at least for JS and iOs, confirmed by Matzew). When doing a read we can pass an id option but as mentioned in the doc, this id will always be append to the endpoint. >>>> >> >>>> >> >>>> >> Well, it is possible - but in a very (IMO) ugly way: >>>> >> >>>> >> https://gist.github.com/matzew/6ab432e437b9a017a21d >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> IMO, we should be able to support this pattern but for now I'm not really sure how to specify this in our API, so if you have any ideas feedback this thread has been made for you ! >>>> >> >>>> >> >>>> >> >>>> >> Suggestion: Enhance the read function - example: >>>> >> >>>> >> https://gist.github.com/matzew/04f069dfbed2cc77a8b4 >>>> > I'm thinking of the inverse myself. Add a "ParentPath" property which can be used to extract information from parent objects. >>>> > >>>> > https://gist.github.com/secondsun/17ce96082eda37dbd10e >>>> > >>>> >> >>>> >> >>>> >> -Matthias >>>> >> >>>> >> >>>> >> [1] http://www.infoq.com/resource/articles/rest-introduction/en/resources/fig... >>>> >> [2] http://www.infoq.com/articles/rest-introduction >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> Seb >>>> >> >>>> >> >>>> >> _______________________________________________ >>>> >> aerogear-dev mailing list >>>> >> aerogear-dev(a)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 >>>> >> >>>> >> _______________________________________________ >>>> >> aerogear-dev mailing list >>>> >> >>>> >> aerogear-dev(a)lists.jboss.org >>>> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> > >>>> > _______________________________________________ >>>> > aerogear-dev mailing list >>>> > aerogear-dev(a)lists.jboss.org >>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> -- qmx >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)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 >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

What if we create a new metaphor, a Junction. https://gist.github.com/secondsun/dcf5682b6ff17c729d9a It joins two pipes together and can be used over and over again with different data? It isn't a Pipe though, but perhaps that could be changed to look more like Christos's previous example. At the very least I like the words "junction" or "join" more than "of" ----- Original Message ----- | From: "Christos Vasilakis" <cvasilak(a)gmail.com&gt; | To: "AeroGear Developer Mailing List" <aerogear-dev(a)lists.jboss.org&gt; | Sent: Wednesday, April 3, 2013 3:03:02 AM | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for nested endpoints | | | On Apr 2, 2013, at 4:03 PM, Matthias Wessendorf < matzew(a)apache.org > wrote: | | | | | Two thoughts.... | | 1) the 'original' leaguesPipe has no clue about the subpipes, right ? | 2) should a pipe offer a 'getter' for all it's sub pipes ? | | | Just a thought is instead of using Pipe, to continue using Pipeline adding an | extra parameter " of" for specifying the parent : E.g.: | | ….. | id<AGPipe> leaguesPipe = [pipeline pipe@"leagues"]; | | id<AGPipe> allTeamsInSeattlePipe = [pipeline subPipe@"teams" of :leaguesPipe | for:@"seattle"] | | id<AGPipe> allPlayersInTrebuchetPipe = [pipeline subPipe:@"players" of: | allTeamsInSeattlePipe for:@"trebuchet"]; | ….. | | | Wdyt? | | | | | | | | -M | | | | | | Thanks, | Christos | | | | | | | | | | | | | | | soccer.org/leagues/seattle/teams/trebuchet/players/foo - > | [[pipeline pipe:@"players" pathParams:@[@"seattle", @"trebuchet"]] read | :@"foo"] .. | ----- | | | Wdyt? | | Thanks | Christos | | On Mar 18, 2013, at 1:12 PM, Sebastien Blanc < scm.blanc(a)gmail.com > wrote: | | | | Well, that would not be possible, for that you will have to create a "child" | pipe. But I agree, that is maybe no optimal ... | | | On Fri, Mar 15, 2013 at 6:44 PM, Summers Pittman < supittma(a)redhat.com > | wrote: | | | | On 03/15/2013 01:34 PM, Sebastien Blanc wrote: | | | I like the idea but I will more see that has a method/function for the | pipelineManager (and will be easier to implement in JS, I think) : | | var myParentPipe = Aerogear.Pipeline({name:"parentPipe"}).pipes.parentPipe | | var myChildPipe = Aerogear.Pipeline.fromParent(myParentPipe, {options} ) | What would it look like to get a child record from a parent? | | | | | | | On Fri, Mar 15, 2013 at 5:37 PM, Douglas Campos < qmx(a)qmx.me > wrote: | | | What about this? | | Pipeline<Post> postPipeline = … | Post post = // get from the pipeline | Pipeline<Comment> | postPipeline.childPipelineForOrOtherWeirdName(Comment.class, post) | | | On 15/03/2013, at 12:26, Summers Pittman < supittma(a)redhat.com > wrote: | | > On 03/14/2013 04:48 AM, Matthias Wessendorf wrote: | >> | >> | >> On Thu, Mar 14, 2013 at 9:32 AM, Sebastien Blanc < scm.blanc(a)gmail.com > | >> wrote: | >> Hi, | >> While I was playing with scaffolding and tried to build a simple Blog | >> Application with Aerogear I faced the current situation : | >> I have a Post object which contains many Comment objects. Now I want to | >> call my Post pipe to retrieve the related comments, I have currently 2 | >> options : | >> | >> /posts/1 -> assuming comments will be implicitly retrieved (eager loading) | >> /comments/?postid=1 | >> | >> But regarding our model the correct form should be : | >> | >> /posts/1/comments | >> | >> | >> +1 | >> that is the ideal way to model URIs for "nested" resources. | >> | >> See [1], extracted from [2] | >> | >> | >> | >> But, AFAIK, with the current API, it is not possible to define this last | >> pattern (at least for JS and iOs, confirmed by Matzew). When doing a read | >> we can pass an id option but as mentioned in the doc, this id will always | >> be append to the endpoint. | >> | >> | >> Well, it is possible - but in a very (IMO) ugly way: | >> | >> https://gist.github.com/matzew/6ab432e437b9a017a21d | >> | >> | >> | >> | >> IMO, we should be able to support this pattern but for now I'm not really | >> sure how to specify this in our API, so if you have any ideas feedback | >> this thread has been made for you ! | >> | >> | >> | >> Suggestion: Enhance the read function - example: | >> | >> https://gist.github.com/matzew/04f069dfbed2cc77a8b4 | > I'm thinking of the inverse myself. Add a "ParentPath" property which can | > be used to extract information from parent objects. | > | > https://gist.github.com/secondsun/17ce96082eda37dbd10e | > | >> | >> | >> -Matthias | >> | >> | >> [1] | >> http://www.infoq.com/resource/articles/rest-introduction/en/resources/fig... | >> [2] http://www.infoq.com/articles/rest-introduction | >> | >> | >> | >> | >> Seb | >> | >> | >> _______________________________________________ | >> aerogear-dev mailing list | >> aerogear-dev(a)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 | >> | >> _______________________________________________ | >> aerogear-dev mailing list | >> | >> aerogear-dev(a)lists.jboss.org | >> https://lists.jboss.org/mailman/listinfo/aerogear-dev | > | > _______________________________________________ | > aerogear-dev mailing list | > aerogear-dev(a)lists.jboss.org | > https://lists.jboss.org/mailman/listinfo/aerogear-dev | | -- qmx | | | _______________________________________________ | aerogear-dev mailing list | aerogear-dev(a)lists.jboss.org | https://lists.jboss.org/mailman/listinfo/aerogear-dev | | | | _______________________________________________ | aerogear-dev mailing list aerogear-dev(a)lists.jboss.org | https://lists.jboss.org/mailman/listinfo/aerogear-dev | | | _______________________________________________ | aerogear-dev mailing list | aerogear-dev(a)lists.jboss.org | https://lists.jboss.org/mailman/listinfo/aerogear-dev | | _______________________________________________ | aerogear-dev mailing list | aerogear-dev(a)lists.jboss.org | https://lists.jboss.org/mailman/listinfo/aerogear-dev | | | _______________________________________________ | aerogear-dev mailing list | aerogear-dev(a)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 | _______________________________________________ | aerogear-dev mailing list | aerogear-dev(a)lists.jboss.org | https://lists.jboss.org/mailman/listinfo/aerogear-dev | | | _______________________________________________ | aerogear-dev mailing list | aerogear-dev(a)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 | _______________________________________________ | aerogear-dev mailing list | aerogear-dev(a)lists.jboss.org | https://lists.jboss.org/mailman/listinfo/aerogear-dev | | | _______________________________________________ | aerogear-dev mailing list | aerogear-dev(a)lists.jboss.org | https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Fri, Apr 5, 2013 at 10:14 AM, Christos Vasilakis <cvasilak(a)gmail.com&gt;wrote: > Hi > > some comments > > I believe the method can't be used since you don't know the team for the > players so you can't retrieve the pipe directly..right? > Isn't that really up to the impl of the rest service? They could return a list of teamsHePlayed for; So, let's not tie this API to a specific, not existing RESTful service; > > getPlayers(Callback<List<Player>> callback) { > pipe.get("player").read(callback); > } > > > Further my questions is, how is a third (or arbitrary) nested resources > are supported? I mean for a url schema like this > > soccer.org/leagues/{id}/teams/{id}/players/{id} > > first we access the leagues: > --- > getLeagues(Callback<List<Leagues>> callback) { > pipe.get("leagues").read(callback); > } > --- > then the teams for this league: > --- > getTeamsOnLeaque(Leaque league, Callback<List<Team>> callback) { > pipe.junction("league","team").read(leaque, callback); > } > --- > ..and then we access the "Players" for a "Team": > --- > getPlayersOnTeam(Team team, Callback<List<Player>> callback) { > pipe.junction("team","player").read(team, callback); > } > --- > But where is the "League" information to fill the "/leagues/{id}..." > path? > I'd assume the information is 'inherited' out of a given pipe, when doing the 'join' e.g. like myTeamsForLeaguePipe = leaguePipe.junction("team"); not sure... > Unless you mean something like: > --- > getPlayersOnTeam(Leaque league, Team team, Callback<List<Player>> > callback) { > pipe.junction("league", "team","player").read(league, team, callback); > } > I am not sure if that is really easy to understand/use > --- > > probably I am missing sth.. > > Thanks, > Christos > > On Apr 4, 2013, at 5:52 PM, Summers Pittman <supittma(a)redhat.com&gt; wrote: > > What if we create a new metaphor, a Junction. > > https://gist.github.com/secondsun/dcf5682b6ff17c729d9a > > It joins two pipes together and can be used over and over again with > different data? > It isn't a Pipe though, but perhaps that could be changed to look more > like Christos's previous example. > > At the very least I like the words "junction" or "join" more than "of" > > ----- Original Message ----- > | From: "Christos Vasilakis" <cvasilak(a)gmail.com&gt; > | To: "AeroGear Developer Mailing List" <aerogear-dev(a)lists.jboss.org&gt; > | Sent: Wednesday, April 3, 2013 3:03:02 AM > | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for nested > endpoints > | > | > | On Apr 2, 2013, at 4:03 PM, Matthias Wessendorf < matzew(a)apache.org > > wrote: > | > | > | > | > | Two thoughts.... > | > | 1) the 'original' leaguesPipe has no clue about the subpipes, right ? > | 2) should a pipe offer a 'getter' for all it's sub pipes ? > | > | > | Just a thought is instead of using Pipe, to continue using Pipeline > adding an > | extra parameter " of" for specifying the parent : E.g.: > | > | ….. > | id<AGPipe> leaguesPipe = [pipeline pipe@"leagues"]; > | > | id<AGPipe> allTeamsInSeattlePipe = [pipeline subPipe@"teams" of > :leaguesPipe > | for:@"seattle"] > | > | id<AGPipe> allPlayersInTrebuchetPipe = [pipeline subPipe:@"players" of: > | allTeamsInSeattlePipe for:@"trebuchet"]; > | ….. > | > | > | Wdyt? > | > | > | > | > | > | > | > | -M > | > | > | > | > | > | Thanks, > | Christos > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | soccer.org/leagues/seattle/teams/trebuchet/players/foo - > > | [[pipeline pipe:@"players" pathParams:@[@"seattle", @"trebuchet"]] read > | :@"foo"] .. > | ----- > | > | > | Wdyt? > | > | Thanks > | Christos > | > | On Mar 18, 2013, at 1:12 PM, Sebastien Blanc < scm.blanc(a)gmail.com > > wrote: > | > | > | > | Well, that would not be possible, for that you will have to create a > "child" > | pipe. But I agree, that is maybe no optimal ... > | > | > | On Fri, Mar 15, 2013 at 6:44 PM, Summers Pittman < supittma(a)redhat.com&gt; > | wrote: > | > | > | > | On 03/15/2013 01:34 PM, Sebastien Blanc wrote: > | > | > | I like the idea but I will more see that has a method/function for the > | pipelineManager (and will be easier to implement in JS, I think) : > | > | var myParentPipe = > Aerogear.Pipeline({name:"parentPipe"}).pipes.parentPipe > | > | var myChildPipe = Aerogear.Pipeline.fromParent(myParentPipe, {options} ) > | What would it look like to get a child record from a parent? > | > | > | > | > | > | > | On Fri, Mar 15, 2013 at 5:37 PM, Douglas Campos < qmx(a)qmx.me > wrote: > | > | > | What about this? > | > | Pipeline<Post> postPipeline = … > | Post post = // get from the pipeline > | Pipeline<Comment> > | postPipeline.childPipelineForOrOtherWeirdName(Comment.class, post) > | > | > | On 15/03/2013, at 12:26, Summers Pittman < supittma(a)redhat.com > wrote: > | > | > On 03/14/2013 04:48 AM, Matthias Wessendorf wrote: > | >> > | >> > | >> On Thu, Mar 14, 2013 at 9:32 AM, Sebastien Blanc < > scm.blanc(a)gmail.com > > | >> wrote: > | >> Hi, > | >> While I was playing with scaffolding and tried to build a simple Blog > | >> Application with Aerogear I faced the current situation : > | >> I have a Post object which contains many Comment objects. Now I want > to > | >> call my Post pipe to retrieve the related comments, I have currently > 2 > | >> options : > | >> > | >> /posts/1 -> assuming comments will be implicitly retrieved (eager > loading) > | >> /comments/?postid=1 > | >> > | >> But regarding our model the correct form should be : > | >> > | >> /posts/1/comments > | >> > | >> > | >> +1 > | >> that is the ideal way to model URIs for "nested" resources. > | >> > | >> See [1], extracted from [2] > | >> > | >> > | >> > | >> But, AFAIK, with the current API, it is not possible to define this > last > | >> pattern (at least for JS and iOs, confirmed by Matzew). When doing a > read > | >> we can pass an id option but as mentioned in the doc, this id will > always > | >> be append to the endpoint. > | >> > | >> > | >> Well, it is possible - but in a very (IMO) ugly way: > | >> > | >> https://gist.github.com/matzew/6ab432e437b9a017a21d > | >> > | >> > | >> > | >> > | >> IMO, we should be able to support this pattern but for now I'm not > really > | >> sure how to specify this in our API, so if you have any ideas > feedback > | >> this thread has been made for you ! > | >> > | >> > | >> > | >> Suggestion: Enhance the read function - example: > | >> > | >> https://gist.github.com/matzew/04f069dfbed2cc77a8b4 > | > I'm thinking of the inverse myself. Add a "ParentPath" property which > can > | > be used to extract information from parent objects. > | > > | > https://gist.github.com/secondsun/17ce96082eda37dbd10e > | > > | >> > | >> > | >> -Matthias > | >> > | >> > | >> [1] > | >> > http://www.infoq.com/resource/articles/rest-introduction/en/resources/fig... > | >> [2] http://www.infoq.com/articles/rest-introduction > | >> > | >> > | >> > | >> > | >> Seb > | >> > | >> > | >> _______________________________________________ > | >> aerogear-dev mailing list > | >> aerogear-dev(a)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 > | >> > | >> _______________________________________________ > | >> aerogear-dev mailing list > | >> > | >> aerogear-dev(a)lists.jboss.org > | >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > | > > | > _______________________________________________ > | > aerogear-dev mailing list > | > aerogear-dev(a)lists.jboss.org > | > https://lists.jboss.org/mailman/listinfo/aerogear-dev > | > | -- qmx > | > | > | _______________________________________________ > | aerogear-dev mailing list > | aerogear-dev(a)lists.jboss.org > | https://lists.jboss.org/mailman/listinfo/aerogear-dev > | > | > | > | _______________________________________________ > | aerogear-dev mailing list aerogear-dev(a)lists.jboss.org > | https://lists.jboss.org/mailman/listinfo/aerogear-dev > | > | > | _______________________________________________ > | aerogear-dev mailing list > | aerogear-dev(a)lists.jboss.org > | https://lists.jboss.org/mailman/listinfo/aerogear-dev > | > | _______________________________________________ > | aerogear-dev mailing list > | aerogear-dev(a)lists.jboss.org > | https://lists.jboss.org/mailman/listinfo/aerogear-dev > | > | > | _______________________________________________ > | aerogear-dev mailing list > | aerogear-dev(a)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 > | _______________________________________________ > | aerogear-dev mailing list > | aerogear-dev(a)lists.jboss.org > | https://lists.jboss.org/mailman/listinfo/aerogear-dev > | > | > | _______________________________________________ > | aerogear-dev mailing list > | aerogear-dev(a)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 > | _______________________________________________ > | aerogear-dev mailing list > | aerogear-dev(a)lists.jboss.org > | https://lists.jboss.org/mailman/listinfo/aerogear-dev > | > | > | _______________________________________________ > | aerogear-dev mailing list > | aerogear-dev(a)lists.jboss.org > | https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)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

On Fri, Apr 5, 2013 at 10:36 AM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: > > > > On Fri, Apr 5, 2013 at 10:14 AM, Christos Vasilakis <cvasilak(a)gmail.com&gt;wrote: > >> Hi >> >> some comments >> >> I believe the method can't be used since you don't know the team for the >> players so you can't retrieve the pipe directly..right? >> > > Isn't that really up to the impl of the rest service? > They could return a list of teamsHePlayed for; > > So, let's not tie this API to a specific, not existing RESTful service; > +1, we don't need to care about that, we must just focus on how we can declare and call nested pipes.

> > >> >> getPlayers(Callback<List<Player>> callback) { >> >> pipe.get("player").read(callback); >> >> } >> >> >> Further my questions is, how is a third (or arbitrary) nested resources >> are supported? I mean for a url schema like this >> >> soccer.org/leagues/{id}/teams/{id}/players/{id} >> >> first we access the leagues: >> --- >> getLeagues(Callback<List<Leagues>> callback) { >> pipe.get("leagues").read(callback); >> } >> --- >> then the teams for this league: >> --- >> getTeamsOnLeaque(Leaque league, Callback<List<Team>> callback) { >> pipe.junction("league","team").read(leaque, callback); >> } >> --- >> ..and then we access the "Players" for a "Team": >> --- >> getPlayersOnTeam(Team team, Callback<List<Player>> callback) { >> pipe.junction("team","player").read(team, callback); >> } >> --- >> But where is the "League" information to fill the "/leagues/{id}..." >> path? >> > > > I'd assume the information is 'inherited' out of a given pipe, when doing > the 'join' > > e.g. like > myTeamsForLeaguePipe = leaguePipe.junction("team"); > > not sure... > > > >> Unless you mean something like: >> --- >> getPlayersOnTeam(Leaque league, Team team, Callback<List<Player>> >> callback) { >> pipe.junction("league", "team","player").read(league, team, >> callback); >> } >> > > I am not sure if that is really easy to understand/use > Yes and the term "junction" is a bit confusing as it don't express explicitly a parent/child relation. > > > >> --- >> >> probably I am missing sth.. >> >> Thanks, >> Christos >> >> On Apr 4, 2013, at 5:52 PM, Summers Pittman <supittma(a)redhat.com&gt; wrote: >> >> What if we create a new metaphor, a Junction. >> >> https://gist.github.com/secondsun/dcf5682b6ff17c729d9a >> >> It joins two pipes together and can be used over and over again with >> different data? >> It isn't a Pipe though, but perhaps that could be changed to look more >> like Christos's previous example. >> >> At the very least I like the words "junction" or "join" more than "of" >> >> ----- Original Message ----- >> | From: "Christos Vasilakis" <cvasilak(a)gmail.com&gt; >> | To: "AeroGear Developer Mailing List" <aerogear-dev(a)lists.jboss.org&gt; >> | Sent: Wednesday, April 3, 2013 3:03:02 AM >> | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for nested >> endpoints >> | >> | >> | On Apr 2, 2013, at 4:03 PM, Matthias Wessendorf < matzew(a)apache.org > >> wrote: >> | >> | >> | >> | >> | Two thoughts.... >> | >> | 1) the 'original' leaguesPipe has no clue about the subpipes, right ? >> | 2) should a pipe offer a 'getter' for all it's sub pipes ? >> | >> | >> | Just a thought is instead of using Pipe, to continue using Pipeline >> adding an >> | extra parameter " of" for specifying the parent : E.g.: >> | >> | ….. >> | id<AGPipe> leaguesPipe = [pipeline pipe@"leagues"]; >> | >> | id<AGPipe> allTeamsInSeattlePipe = [pipeline subPipe@"teams" of >> :leaguesPipe >> | for:@"seattle"] >> | >> | id<AGPipe> allPlayersInTrebuchetPipe = [pipeline subPipe:@"players" >> of: >> | allTeamsInSeattlePipe for:@"trebuchet"]; >> | ….. >> | >> | >> | Wdyt? >> | >> | >> | >> | >> | >> | >> | >> | -M >> | >> | >> | >> | >> | >> | Thanks, >> | Christos >> | >> | >> | >> | >> | >> | >> | >> | >> | >> | >> | >> | >> | >> | >> | soccer.org/leagues/seattle/teams/trebuchet/players/foo - > >> | [[pipeline pipe:@"players" pathParams:@[@"seattle", @"trebuchet"]] >> read >> | :@"foo"] .. >> | ----- >> | >> | >> | Wdyt? >> | >> | Thanks >> | Christos >> | >> | On Mar 18, 2013, at 1:12 PM, Sebastien Blanc < scm.blanc(a)gmail.com > >> wrote: >> | >> | >> | >> | Well, that would not be possible, for that you will have to create a >> "child" >> | pipe. But I agree, that is maybe no optimal ... >> | >> | >> | On Fri, Mar 15, 2013 at 6:44 PM, Summers Pittman < supittma(a)redhat.com&gt; >> | wrote: >> | >> | >> | >> | On 03/15/2013 01:34 PM, Sebastien Blanc wrote: >> | >> | >> | I like the idea but I will more see that has a method/function for the >> | pipelineManager (and will be easier to implement in JS, I think) : >> | >> | var myParentPipe = >> Aerogear.Pipeline({name:"parentPipe"}).pipes.parentPipe >> | >> | var myChildPipe = Aerogear.Pipeline.fromParent(myParentPipe, {options} >> ) >> | What would it look like to get a child record from a parent? >> | >> | >> | >> | >> | >> | >> | On Fri, Mar 15, 2013 at 5:37 PM, Douglas Campos < qmx(a)qmx.me > wrote: >> | >> | >> | What about this? >> | >> | Pipeline<Post> postPipeline = … >> | Post post = // get from the pipeline >> | Pipeline<Comment> >> | postPipeline.childPipelineForOrOtherWeirdName(Comment.class, post) >> | >> | >> | On 15/03/2013, at 12:26, Summers Pittman < supittma(a)redhat.com > >> wrote: >> | >> | > On 03/14/2013 04:48 AM, Matthias Wessendorf wrote: >> | >> >> | >> >> | >> On Thu, Mar 14, 2013 at 9:32 AM, Sebastien Blanc < >> scm.blanc(a)gmail.com > >> | >> wrote: >> | >> Hi, >> | >> While I was playing with scaffolding and tried to build a simple >> Blog >> | >> Application with Aerogear I faced the current situation : >> | >> I have a Post object which contains many Comment objects. Now I >> want to >> | >> call my Post pipe to retrieve the related comments, I have >> currently 2 >> | >> options : >> | >> >> | >> /posts/1 -> assuming comments will be implicitly retrieved (eager >> loading) >> | >> /comments/?postid=1 >> | >> >> | >> But regarding our model the correct form should be : >> | >> >> | >> /posts/1/comments >> | >> >> | >> >> | >> +1 >> | >> that is the ideal way to model URIs for "nested" resources. >> | >> >> | >> See [1], extracted from [2] >> | >> >> | >> >> | >> >> | >> But, AFAIK, with the current API, it is not possible to define this >> last >> | >> pattern (at least for JS and iOs, confirmed by Matzew). When doing >> a read >> | >> we can pass an id option but as mentioned in the doc, this id will >> always >> | >> be append to the endpoint. >> | >> >> | >> >> | >> Well, it is possible - but in a very (IMO) ugly way: >> | >> >> | >> https://gist.github.com/matzew/6ab432e437b9a017a21d >> | >> >> | >> >> | >> >> | >> >> | >> IMO, we should be able to support this pattern but for now I'm not >> really >> | >> sure how to specify this in our API, so if you have any ideas >> feedback >> | >> this thread has been made for you ! >> | >> >> | >> >> | >> >> | >> Suggestion: Enhance the read function - example: >> | >> >> | >> https://gist.github.com/matzew/04f069dfbed2cc77a8b4 >> | > I'm thinking of the inverse myself. Add a "ParentPath" property >> which can >> | > be used to extract information from parent objects. >> | > >> | > https://gist.github.com/secondsun/17ce96082eda37dbd10e >> | > >> | >> >> | >> >> | >> -Matthias >> | >> >> | >> >> | >> [1] >> | >> >> http://www.infoq.com/resource/articles/rest-introduction/en/resources/fig... >> | >> [2] http://www.infoq.com/articles/rest-introduction >> | >> >> | >> >> | >> >> | >> >> | >> Seb >> | >> >> | >> >> | >> _______________________________________________ >> | >> aerogear-dev mailing list >> | >> aerogear-dev(a)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 >> | >> >> | >> _______________________________________________ >> | >> aerogear-dev mailing list >> | >> >> | >> aerogear-dev(a)lists.jboss.org >> | >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> | > >> | > _______________________________________________ >> | > aerogear-dev mailing list >> | > aerogear-dev(a)lists.jboss.org >> | > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> | >> | -- qmx >> | >> | >> | _______________________________________________ >> | aerogear-dev mailing list >> | aerogear-dev(a)lists.jboss.org >> | https://lists.jboss.org/mailman/listinfo/aerogear-dev >> | >> | >> | >> | _______________________________________________ >> | aerogear-dev mailing list aerogear-dev(a)lists.jboss.org >> | https://lists.jboss.org/mailman/listinfo/aerogear-dev >> | >> | >> | _______________________________________________ >> | aerogear-dev mailing list >> | aerogear-dev(a)lists.jboss.org >> | https://lists.jboss.org/mailman/listinfo/aerogear-dev >> | >> | _______________________________________________ >> | aerogear-dev mailing list >> | aerogear-dev(a)lists.jboss.org >> | https://lists.jboss.org/mailman/listinfo/aerogear-dev >> | >> | >> | _______________________________________________ >> | aerogear-dev mailing list >> | aerogear-dev(a)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 >> | _______________________________________________ >> | aerogear-dev mailing list >> | aerogear-dev(a)lists.jboss.org >> | https://lists.jboss.org/mailman/listinfo/aerogear-dev >> | >> | >> | _______________________________________________ >> | aerogear-dev mailing list >> | aerogear-dev(a)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 >> | _______________________________________________ >> | aerogear-dev mailing list >> | aerogear-dev(a)lists.jboss.org >> | https://lists.jboss.org/mailman/listinfo/aerogear-dev >> | >> | >> | _______________________________________________ >> | aerogear-dev mailing list >> | aerogear-dev(a)lists.jboss.org >> | https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

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

----- Original Message ----- | From: "Matthias Wessendorf" <matzew(a)apache.org&gt; | To: "AeroGear Developer Mailing List" <aerogear-dev(a)lists.jboss.org&gt; | Sent: Monday, April 8, 2013 10:28:46 AM | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for nested endpoints | | or, like before said - reading "lists" (e.g. all the comments for specific | blog post): | https://gist.github.com/matzew/04f069dfbed2cc77a8b4 | | | For Java.... I guess...... resolving this URL: | http://some.server.com/posts/1/comments | | could be done with this - right ? | | ======= | Class Post: | - string: title; | - string: postContent; | - List<Comment> comments; | Class Comment: | - string username; | - string comment; | | | // get all the comments for 1: | Post myPostOne = postPipe.read("1"); | myPostOne.getComments(); | | // get all the comments for 2: | Post myPostTwo = postPipe.read("2"); | myPostTwo.getComments(); | ======= It can be done with that yes. My concern was more when we had a Pipe of type <Post> and a readForResource(String property) method.

The type information of the property isn't available unless we can infer it from the Post object.

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

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

----- Original Message ----- | From: "Matthias Wessendorf" <matzew(a)apache.org&gt; | To: "AeroGear Developer Mailing List" <aerogear-dev(a)lists.jboss.org&gt; | Sent: Monday, April 8, 2013 1:22:19 PM | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for nested endpoints | | OK, with the following server API: | | http://some.server.com/posts/1 | http://some.server.com/posts/1/comments | (and NO 'comments' collection on the ' http://some.server.com/posts/1 ' | response) | | Does this (today) 'myPipe.read(1)' already read the specific comments ( | http://some.server.com/posts/1/comments ) ?? | | ======= JAVA API ======= | Class Post: | - string: id; | - string: title; | - string: postContent; | - List<Comment> comments; | Class Comment: | - string username; | - string comment; | | Or would the IMPL expect an 'embedded' _comments_ collection on the response | of "GET http://some.server.com/posts/1 " ?

you have a comments collection on the post but no comments data in the response then the value for getComments will just be null.

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

Hey, Like paging, could we start 2 gists : one with a side to side techno samples and another one with high level Specs ? I start a bit to get lost in this thread :)

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

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

yeah - same here, :) +1 on proposal #1 On Wed, Apr 10, 2013 at 6:23 PM, Douglas Campos <qmx(a)qmx.me&gt; wrote: > Approach #1 hands down > > -- > qmx > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

+1 for approach #1 And since approach #1 seems quite popular the Gist has been updated with the JS version of #1 https://gist.github.com/cvasilak/4a5f51b8d1ad9cc7f21b On Thu, Apr 11, 2013 at 8:33 AM, Daniel Bevenius < daniel.bevenius(a)gmail.com&gt; wrote: > +1 for approach #1. Nice write up on this Christos, thanks for that! > > > On 10 April 2013 18:32, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > >> yeah - same here, :) +1 on proposal #1 >> >> >> On Wed, Apr 10, 2013 at 6:23 PM, Douglas Campos <qmx(a)qmx.me&gt; wrote: >> >>> Approach #1 hands down >>> >>> -- >>> qmx >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)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 >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev >

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

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

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

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

what about relativePath ? On Apr 16, 2013, at 9:12 AM, Kris Borchers <kris(a)redhat.com&gt; wrote: > My only issue with resourcePath is that it doesn't imply that the path is relative to the current pipe. I mean, it should be implied since you're already working with a pipe and we can be explicit about that in documentation but I still wish it was somehow in the name. I think that was the goal of using "nested" in the name but I already expressed my issue with that. Any other thoughts would be appreciated but I could be happy with resourcePath. > > On Apr 16, 2013, at 7:55 AM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: > >> +1 to resourcePath . it beats my thought of "superawesomenestedresourcethingy" >> On Apr 16, 2013, at 8:39 AM, Christos Vasilakis <cvasilak(a)gmail.com&gt; wrote: >> >>> +1 >>> >>> I think it describes the feature better. >>> >>> >>> On Apr 16, 2013, at 3:09 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >>> >>>> +1 on the "resourcePath", you nailed it ! >>>> >>>> >>>> >>>> On Tue, Apr 16, 2013 at 2:03 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >>>> Hmmm, "nestedResource" isn't terrible but not crazy about "nested" since they're not necessarily nested but just related. Hmmmmm. >>>> >>>> It's not that I hate resource, I think it kind of makes sense if you know what we're talking about. How about something like "resourcePath" to be a little more explicit in what it is? Still not crazy about that but feel like it's better/closer to something that describes what it is. >>>> >>>> On Apr 16, 2013, at 6:44 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >>>> >>>>> Well, there seems to be an agreement on option #1 , except for the name "resource" , so let's find a name that we all agree on and so we can going further with this feature. >>>>> My propositions: "nestedResource" , "fragment", "nestedURI" ... But I'm not really fan of all of my propositions ... >>>>> Seb >>>>> >>>>> >>>>> >>>>> On Thu, Apr 11, 2013 at 4:07 PM, Summers Pittman <supittma(a)redhat.com&gt; wrote: >>>>> With #1 is `resource` a URI? If so, will developers have to build the URI by hand? >>>>> >>>>> >>>>> On 04/10/2013 10:48 AM, Christos Vasilakis wrote: >>>>>> Hi >>>>>> >>>>>> I've prepared a document[1] that collectively describes the different approaches discussed in this thread for supporting the nested resources. It is split in two sections, ones that don't require modification to the existing API and ones that do >>>>>> >>>>>> Please have a look and let me know if I miss sth or interpret one approach wrong. >>>>>> >>>>>> Thanks >>>>>> Christos >>>>>> >>>>>> [1] https://gist.github.com/cvasilak/4a5f51b8d1ad9cc7f21b >>>>>> >>>>>> On Apr 9, 2013, at 10:19 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >>>>>> >>>>>>> Hey, >>>>>>> Like paging, could we start 2 gists : one with a side to side techno samples and another one with high level Specs ? I start a bit to get lost in this thread :) >>>>>>> Just one remark when reading the last messages, one "must have" is to be able to retrieve all the comments for a post without EVER retrieving the post record, so >>>>>>> /posts/1/comments will retrieve all the comments for post 1 but will actually never call posts/1 : in this covered in your last examples ? (spec could be : "by-pass parent GET resource" >>>>>>> Seb >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Apr 9, 2013 at 9:03 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Apr 8, 2013 at 7:57 PM, Summers Pittman <supittma(a)redhat.com&gt; wrote: >>>>>>> >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>> | From: "Matthias Wessendorf" <matzew(a)apache.org&gt; >>>>>>> | To: "AeroGear Developer Mailing List" <aerogear-dev(a)lists.jboss.org&gt; >>>>>>> | Sent: Monday, April 8, 2013 1:22:19 PM >>>>>>> | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for nested endpoints >>>>>>> | >>>>>>> | OK, with the following server API: >>>>>>> | >>>>>>> | http://some.server.com/posts/1 >>>>>>> | http://some.server.com/posts/1/comments >>>>>>> | (and NO 'comments' collection on the ' http://some.server.com/posts/1 ' >>>>>>> | response) >>>>>>> | >>>>>>> | Does this (today) 'myPipe.read(1)' already read the specific comments ( >>>>>>> | http://some.server.com/posts/1/comments ) ?? >>>>>>> | >>>>>>> | ======= JAVA API ======= >>>>>>> | Class Post: >>>>>>> | - string: id; >>>>>>> | - string: title; >>>>>>> | - string: postContent; >>>>>>> | - List<Comment> comments; >>>>>>> | Class Comment: >>>>>>> | - string username; >>>>>>> | - string comment; >>>>>>> | >>>>>>> | Or would the IMPL expect an 'embedded' _comments_ collection on the response >>>>>>> | of "GET http://some.server.com/posts/1 " ? >>>>>>> >>>>>>> It will not read /posts/1/comments if the Pipe's endpoint is /posts. If you have a comments collection on the post but no comments data in the response then the value for getComments will just be null. >>>>>>> >>>>>>> Ok - so this needs to be tweaked in Java too, since it's very common to model the REST endpoints like above; >>>>>>> >>>>>>> >>>>>>> >>>>>>> | >>>>>>> | >>>>>>> | >>>>>>> | On Mon, Apr 8, 2013 at 7:05 PM, Summers Pittman < supittma(a)redhat.com > >>>>>>> | wrote: >>>>>>> | >>>>>>> | >>>>>>> | No. The get of pipe 1 would have to include the comments for get comments to >>>>>>> | work >>>>>>> | >>>>>>> | Sent from my Android phone using TouchDown ( www.nitrodesk.com ) >>>>>>> | >>>>>>> | >>>>>>> | -----Original Message----- >>>>>>> | From: Matthias Wessendorf [ matzew(a)apache.org ] >>>>>>> | Received: Monday, 08 Apr 2013, 12:04PM >>>>>>> | To: AeroGear Developer Mailing List [ aerogear-dev(a)lists.jboss.org ] >>>>>>> | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for nested endpoints >>>>>>> | >>>>>>> | >>>>>>> | On Mon, Apr 8, 2013 at 5:57 PM, Summers Pittman < supittma(a)redhat.com > >>>>>>> | wrote: >>>>>>> | >>>>>>> | > >>>>>>> | > >>>>>>> | > ----- Original Message ----- >>>>>>> | > | From: "Matthias Wessendorf" < matzew(a)apache.org > >>>>>>> | > | To: "AeroGear Developer Mailing List" < aerogear-dev(a)lists.jboss.org > >>>>>>> | > | Sent: Monday, April 8, 2013 10:28:46 AM >>>>>>> | > | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for nested >>>>>>> | > endpoints >>>>>>> | > | >>>>>>> | > | or, like before said - reading "lists" (e.g. all the comments for >>>>>>> | > specific >>>>>>> | > | blog post): >>>>>>> | > | https://gist.github.com/matzew/04f069dfbed2cc77a8b4 >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | For Java.... I guess...... resolving this URL: >>>>>>> | > | http://some.server.com/posts/1/comments >>>>>>> | > | >>>>>>> | > | could be done with this - right ? >>>>>>> | > | >>>>>>> | > | ======= >>>>>>> | > | Class Post: >>>>>>> | > | - string: title; >>>>>>> | > | - string: postContent; >>>>>>> | > | - List<Comment> comments; >>>>>>> | > | Class Comment: >>>>>>> | > | - string username; >>>>>>> | > | - string comment; >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | // get all the comments for 1: >>>>>>> | > | Post myPostOne = postPipe.read("1"); >>>>>>> | > | myPostOne.getComments(); >>>>>>> | > | >>>>>>> | > | // get all the comments for 2: >>>>>>> | > | Post myPostTwo = postPipe.read("2"); >>>>>>> | > | myPostTwo.getComments(); >>>>>>> | > | ======= >>>>>>> | > >>>>>>> | > It can be done with that yes. My concern was more when we had a Pipe of >>>>>>> | > type <Post> and a readForResource(String property) method. >>>>>>> | >>>>>>> | >>>>>>> | Ok - one more question >>>>>>> | >>>>>>> | >>>>>>> | So... when doing: myPipe.read(1); does that "only" issue a GET against the ' >>>>>>> | http://some.server.com/posts/1 ' resource? >>>>>>> | >>>>>>> | A second get, for the comments collection is than issued when calling >>>>>>> | myPostOne.getComments();? >>>>>>> | (GET against ' http://some.server.com/posts/1/comments' )? >>>>>>> | >>>>>>> | >>>>>>> | >>>>>>> | >>>>>>> | > The type information of the property isn't available unless we can infer >>>>>>> | > it from the Post object. >>>>>>> | > >>>>>>> | >>>>>>> | >>>>>>> | >>>>>>> | >>>>>>> | >>>>>>> | > >>>>>>> | > >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | Greetings, >>>>>>> | > | Matthias >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | On Fri, Apr 5, 2013 at 2:37 PM, Matthias Wessendorf < matzew(a)apache.org > >>>>>>> | > | wrote: >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | Thought a bit more about it and chatted with friends, >>>>>>> | > | >>>>>>> | > | the issue with the sub pipes is: it adds state and is perhaps an API >>>>>>> | > | construct that is a bit hard to understand (see all the discussions here) >>>>>>> | > | >>>>>>> | > | Not sure - but currently we can access "kid resources", with our API - >>>>>>> | > right >>>>>>> | > | ? >>>>>>> | > | >>>>>>> | > | https://gist.github.com/matzew/6ab432e437b9a017a21d >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | Perhaps it's better to just keep it that way? This has the benefit of >>>>>>> | > using >>>>>>> | > | an established and know API, the different pipes are accessible via the >>>>>>> | > | pipeline object; >>>>>>> | > | >>>>>>> | > | And the code is not too much code; it's simply an explicit pipe ... >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | On Fri, Apr 5, 2013 at 10:56 AM, Matthias Wessendorf < matzew(a)apache.org >>>>>>> | > | > >>>>>>> | > | wrote: >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | On Fri, Apr 5, 2013 at 10:52 AM, Sebastien Blanc < scm.blanc(a)gmail.com > >>>>>>> | > | wrote: >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | On Fri, Apr 5, 2013 at 10:36 AM, Matthias Wessendorf < matzew(a)apache.org >>>>>>> | > | > >>>>>>> | > | wrote: >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | On Fri, Apr 5, 2013 at 10:14 AM, Christos Vasilakis < cvasilak(a)gmail.com >>>>>>> | > | > >>>>>>> | > | wrote: >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | Hi >>>>>>> | > | >>>>>>> | > | some comments >>>>>>> | > | >>>>>>> | > | I believe the method can't be used since you don't know the team for the >>>>>>> | > | players so you can't retrieve the pipe directly..right? >>>>>>> | > | >>>>>>> | > | Isn't that really up to the impl of the rest service? >>>>>>> | > | They could return a list of teamsHePlayed for; >>>>>>> | > | >>>>>>> | > | So, let's not tie this API to a specific, not existing RESTful service; >>>>>>> | > | >>>>>>> | > | +1, we don't need to care about that, we must just focus on how we can >>>>>>> | > | declare and call nested pipes. >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | yep >>>>>>> | > | >>>>>>> | > | I guess this is perhaps the closest we can come to : >>>>>>> | > | >>>>>>> | > | id<AGPipe> allOwnersInNewYorkPipe = [leaguesPipe subPipe:@"owners" >>>>>>> | > | for:@"newyork"]; >>>>>>> | > | >>>>>>> | > | and than.... on the 'leaguesPipe' you can access its kids with something >>>>>>> | > like >>>>>>> | > | : >>>>>>> | > | >>>>>>> | > | NSArray* kids = [leaguesPipe subPipes]; >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | However, that adds some state to a specific pipe object >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | -M >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | getPlayers ( Callback < List < Player >> callback ) { >>>>>>> | > | pipe . get ( "player" ). read ( callback ); >>>>>>> | > | } >>>>>>> | > | >>>>>>> | > | Further my questions is, how is a third (or arbitrary) nested resources >>>>>>> | > are >>>>>>> | > | supported? I mean for a url schema like this >>>>>>> | > | >>>>>>> | > | soccer.org/leagues/ {id}/teams/{id}/players/{id} >>>>>>> | > | >>>>>>> | > | first we access the leagues: >>>>>>> | > | --- >>>>>>> | > | getLeagues(Callback<List<Leagues>> callback) { >>>>>>> | > | pipe.get("leagues").read(callback); >>>>>>> | > | } >>>>>>> | > | --- >>>>>>> | > | then the teams for this league: >>>>>>> | > | --- >>>>>>> | > | getTeamsOnLeaque(Leaque league, Callback<List<Team>> callback) { >>>>>>> | > | pipe.junction("league","team").read(leaque, callback); >>>>>>> | > | } >>>>>>> | > | --- >>>>>>> | > | ..and then we access the "Players" for a "Team": >>>>>>> | > | --- >>>>>>> | > | getPlayersOnTeam(Team team, Callback<List<Player>> callback) { >>>>>>> | > | pipe.junction("team","player").read(team, callback); >>>>>>> | > | } >>>>>>> | > | --- >>>>>>> | > | But where is the "League" information to fill the "/leagues/{id}..." >>>>>>> | > path? >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | I'd assume the information is 'inherited' out of a given pipe, when >>>>>>> | > doing the >>>>>>> | > | 'join' >>>>>>> | > | >>>>>>> | > | e.g. like >>>>>>> | > | myTeamsForLeaguePipe = leaguePipe.junction("team"); >>>>>>> | > | >>>>>>> | > | not sure... >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | Unless you mean something like: >>>>>>> | > | --- >>>>>>> | > | getPlayersOnTeam(Leaque league, Team team, Callback<List<Player>> >>>>>>> | > callback) { >>>>>>> | > | pipe.junction("league", "team","player").read(league, team, callback); >>>>>>> | > | } >>>>>>> | > | >>>>>>> | > | I am not sure if that is really easy to understand/use >>>>>>> | > | >>>>>>> | > | Yes and the term "junction" is a bit confusing as it don't express >>>>>>> | > explicitly >>>>>>> | > | a parent/child relation. >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | --- >>>>>>> | > | >>>>>>> | > | probably I am missing sth.. >>>>>>> | > | >>>>>>> | > | Thanks, >>>>>>> | > | Christos >>>>>>> | > | >>>>>>> | > | On Apr 4, 2013, at 5:52 PM, Summers Pittman < supittma(a)redhat.com > >>>>>>> | > wrote: >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | What if we create a new metaphor, a Junction. >>>>>>> | > | >>>>>>> | > | https://gist.github.com/secondsun/dcf5682b6ff17c729d9a >>>>>>> | > | >>>>>>> | > | It joins two pipes together and can be used over and over again with >>>>>>> | > | different data? >>>>>>> | > | It isn't a Pipe though, but perhaps that could be changed to look more >>>>>>> | > like >>>>>>> | > | Christos's previous example. >>>>>>> | > | >>>>>>> | > | At the very least I like the words "junction" or "join" more than "of" >>>>>>> | > | >>>>>>> | > | ----- Original Message ----- >>>>>>> | > | | From: "Christos Vasilakis" < cvasilak(a)gmail.com > >>>>>>> | > | | To: "AeroGear Developer Mailing List" < aerogear-dev(a)lists.jboss.org > >>>>>>> | > | | Sent: Wednesday, April 3, 2013 3:03:02 AM >>>>>>> | > | | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for nested >>>>>>> | > | | endpoints >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | On Apr 2, 2013, at 4:03 PM, Matthias Wessendorf < matzew(a)apache.org > >>>>>>> | > | | wrote: >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | Two thoughts.... >>>>>>> | > | | >>>>>>> | > | | 1) the 'original' leaguesPipe has no clue about the subpipes, right ? >>>>>>> | > | | 2) should a pipe offer a 'getter' for all it's sub pipes ? >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | Just a thought is instead of using Pipe, to continue using Pipeline >>>>>>> | > adding >>>>>>> | > | | an >>>>>>> | > | | extra parameter " of" for specifying the parent : E.g.: >>>>>>> | > | | >>>>>>> | > | | ….. >>>>>>> | > | | id<AGPipe> leaguesPipe = [pipeline pipe@"leagues"]; >>>>>>> | > | | >>>>>>> | > | | id<AGPipe> allTeamsInSeattlePipe = [pipeline subPipe@"teams" of >>>>>>> | > | | :leaguesPipe >>>>>>> | > | | for:@"seattle"] >>>>>>> | > | | >>>>>>> | > | | id<AGPipe> allPlayersInTrebuchetPipe = [pipeline subPipe:@"players" >>>>>>> | > of: >>>>>>> | > | | allTeamsInSeattlePipe for:@"trebuchet"]; >>>>>>> | > | | ….. >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | Wdyt? >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | -M >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | Thanks, >>>>>>> | > | | Christos >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | soccer.org/leagues/seattle/teams/trebuchet/players/foo - > >>>>>>> | > | | [[pipeline pipe:@"players" pathParams:@[@"seattle", @"trebuchet"]] >>>>>>> | > read >>>>>>> | > | | :@"foo"] .. >>>>>>> | > | | ----- >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | Wdyt? >>>>>>> | > | | >>>>>>> | > | | Thanks >>>>>>> | > | | Christos >>>>>>> | > | | >>>>>>> | > | | On Mar 18, 2013, at 1:12 PM, Sebastien Blanc < scm.blanc(a)gmail.com > >>>>>>> | > wrote: >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | Well, that would not be possible, for that you will have to create a >>>>>>> | > | | "child" >>>>>>> | > | | pipe. But I agree, that is maybe no optimal ... >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | On Fri, Mar 15, 2013 at 6:44 PM, Summers Pittman < supittma(a)redhat.com >>>>>>> | > | | > >>>>>>> | > | | wrote: >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | On 03/15/2013 01:34 PM, Sebastien Blanc wrote: >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | I like the idea but I will more see that has a method/function for the >>>>>>> | > | | pipelineManager (and will be easier to implement in JS, I think) : >>>>>>> | > | | >>>>>>> | > | | var myParentPipe = >>>>>>> | > Aerogear.Pipeline({name:"parentPipe"}).pipes.parentPipe >>>>>>> | > | | >>>>>>> | > | | var myChildPipe = Aerogear.Pipeline.fromParent(myParentPipe, {options} >>>>>>> | > ) >>>>>>> | > | | What would it look like to get a child record from a parent? >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | On Fri, Mar 15, 2013 at 5:37 PM, Douglas Campos < qmx(a)qmx.me > wrote: >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | What about this? >>>>>>> | > | | >>>>>>> | > | | Pipeline<Post> postPipeline = … >>>>>>> | > | | Post post = // get from the pipeline >>>>>>> | > | | Pipeline<Comment> >>>>>>> | > | | postPipeline.childPipelineForOrOtherWeirdName(Comment.class, post) >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | On 15/03/2013, at 12:26, Summers Pittman < supittma(a)redhat.com > >>>>>>> | > wrote: >>>>>>> | > | | >>>>>>> | > | | > On 03/14/2013 04:48 AM, Matthias Wessendorf wrote: >>>>>>> | > | | >> >>>>>>> | > | | >> >>>>>>> | > | | >> On Thu, Mar 14, 2013 at 9:32 AM, Sebastien Blanc < >>>>>>> | > scm.blanc(a)gmail.com > >>>>>>> | > | | >> wrote: >>>>>>> | > | | >> Hi, >>>>>>> | > | | >> While I was playing with scaffolding and tried to build a simple >>>>>>> | > Blog >>>>>>> | > | | >> Application with Aerogear I faced the current situation : >>>>>>> | > | | >> I have a Post object which contains many Comment objects. Now I >>>>>>> | > want to >>>>>>> | > | | >> call my Post pipe to retrieve the related comments, I have >>>>>>> | > currently 2 >>>>>>> | > | | >> options : >>>>>>> | > | | >> >>>>>>> | > | | >> /posts/1 -> assuming comments will be implicitly retrieved (eager >>>>>>> | > | | >> loading) >>>>>>> | > | | >> /comments/?postid=1 >>>>>>> | > | | >> >>>>>>> | > | | >> But regarding our model the correct form should be : >>>>>>> | > | | >> >>>>>>> | > | | >> /posts/1/comments >>>>>>> | > | | >> >>>>>>> | > | | >> >>>>>>> | > | | >> +1 >>>>>>> | > | | >> that is the ideal way to model URIs for "nested" resources. >>>>>>> | > | | >> >>>>>>> | > | | >> See [1], extracted from [2] >>>>>>> | > | | >> >>>>>>> | > | | >> >>>>>>> | > | | >> >>>>>>> | > | | >> But, AFAIK, with the current API, it is not possible to define this >>>>>>> | > last >>>>>>> | > | | >> pattern (at least for JS and iOs, confirmed by Matzew). When doing a >>>>>>> | > | | >> read >>>>>>> | > | | >> we can pass an id option but as mentioned in the doc, this id will >>>>>>> | > | | >> always >>>>>>> | > | | >> be append to the endpoint. >>>>>>> | > | | >> >>>>>>> | > | | >> >>>>>>> | > | | >> Well, it is possible - but in a very (IMO) ugly way: >>>>>>> | > | | >> >>>>>>> | > | | >> https://gist.github.com/matzew/6ab432e437b9a017a21d >>>>>>> | > | | >> >>>>>>> | > | | >> >>>>>>> | > | | >> >>>>>>> | > | | >> >>>>>>> | > | | >> IMO, we should be able to support this pattern but for now I'm not >>>>>>> | > | | >> really >>>>>>> | > | | >> sure how to specify this in our API, so if you have any ideas >>>>>>> | > feedback >>>>>>> | > | | >> this thread has been made for you ! >>>>>>> | > | | >> >>>>>>> | > | | >> >>>>>>> | > | | >> >>>>>>> | > | | >> Suggestion: Enhance the read function - example: >>>>>>> | > | | >> >>>>>>> | > | | >> https://gist.github.com/matzew/04f069dfbed2cc77a8b4 >>>>>>> | > | | > I'm thinking of the inverse myself. Add a "ParentPath" property >>>>>>> | > which can >>>>>>> | > | | > be used to extract information from parent objects. >>>>>>> | > | | > >>>>>>> | > | | > https://gist.github.com/secondsun/17ce96082eda37dbd10e >>>>>>> | > | | > >>>>>>> | > | | >> >>>>>>> | > | | >> >>>>>>> | > | | >> -Matthias >>>>>>> | > | | >> >>>>>>> | > | | >> >>>>>>> | > | | >> [1] >>>>>>> | > | | >> >>>>>>> | > http://www.infoq.com/resource/articles/rest-introduction/en/resources/fig... >>>>>>> | > | | >> [2] http://www.infoq.com/articles/rest-introduction >>>>>>> | > | | >> >>>>>>> | > | | >> >>>>>>> | > | | >> >>>>>>> | > | | >> >>>>>>> | > | | >> Seb >>>>>>> | > | | >> >>>>>>> | > | | >> >>>>>>> | > | | >> _______________________________________________ >>>>>>> | > | | >> aerogear-dev mailing list >>>>>>> | > | | >> aerogear-dev(a)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 >>>>>>> | > | | >> >>>>>>> | > | | >> _______________________________________________ >>>>>>> | > | | >> aerogear-dev mailing list >>>>>>> | > | | >> >>>>>>> | > | | >> aerogear-dev(a)lists.jboss.org >>>>>>> | > | | >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> | > | | > >>>>>>> | > | | > _______________________________________________ >>>>>>> | > | | > aerogear-dev mailing list >>>>>>> | > | | > aerogear-dev(a)lists.jboss.org >>>>>>> | > | | > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> | > | | >>>>>>> | > | | -- qmx >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | _______________________________________________ >>>>>>> | > | | aerogear-dev mailing list >>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | _______________________________________________ >>>>>>> | > | | aerogear-dev mailing list aerogear-dev(a)lists.jboss.org >>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | _______________________________________________ >>>>>>> | > | | aerogear-dev mailing list >>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> | > | | >>>>>>> | > | | _______________________________________________ >>>>>>> | > | | aerogear-dev mailing list >>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | _______________________________________________ >>>>>>> | > | | aerogear-dev mailing list >>>>>>> | > | | aerogear-dev(a)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 >>>>>>> | > | | _______________________________________________ >>>>>>> | > | | aerogear-dev mailing list >>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | _______________________________________________ >>>>>>> | > | | aerogear-dev mailing list >>>>>>> | > | | aerogear-dev(a)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 >>>>>>> | > | | _______________________________________________ >>>>>>> | > | | aerogear-dev mailing list >>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | _______________________________________________ >>>>>>> | > | | aerogear-dev mailing list >>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> | > | >>>>>>> | > | _______________________________________________ >>>>>>> | > | aerogear-dev mailing list >>>>>>> | > | aerogear-dev(a)lists.jboss.org >>>>>>> | > | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | _______________________________________________ >>>>>>> | > | aerogear-dev mailing list >>>>>>> | > | aerogear-dev(a)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 >>>>>>> | > | >>>>>>> | > | _______________________________________________ >>>>>>> | > | aerogear-dev mailing list >>>>>>> | > | aerogear-dev(a)lists.jboss.org >>>>>>> | > | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | _______________________________________________ >>>>>>> | > | aerogear-dev mailing list >>>>>>> | > | aerogear-dev(a)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 >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | -- >>>>>>> | > | Matthias Wessendorf >>>>>>> | > | >>>>>>> | > | blog: http://matthiaswessendorf.wordpress.com/ >>>>>>> | > | sessions: http://www.slideshare.net/mwessendorf >>>>>>> | > | twitter: http://twitter.com/mwessendorf >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | -- >>>>>>> | > | Matthias Wessendorf >>>>>>> | > | >>>>>>> | > | blog: http://matthiaswessendorf.wordpress.com/ >>>>>>> | > | sessions: http://www.slideshare.net/mwessendorf >>>>>>> | > | twitter: http://twitter.com/mwessendorf >>>>>>> | > | >>>>>>> | > | _______________________________________________ >>>>>>> | > | aerogear-dev mailing list >>>>>>> | > | aerogear-dev(a)lists.jboss.org >>>>>>> | > | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> | > >>>>>>> | > _______________________________________________ >>>>>>> | > aerogear-dev mailing list >>>>>>> | > aerogear-dev(a)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 >>>>>>> | >>>>>>> | _______________________________________________ >>>>>>> | aerogear-dev mailing list >>>>>>> | aerogear-dev(a)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 >>>>>>> | >>>>>>> | _______________________________________________ >>>>>>> | aerogear-dev mailing list >>>>>>> | aerogear-dev(a)lists.jboss.org >>>>>>> | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev(a)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 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

I agree, when I read resourcePath I read that as a path to resource. How about pathSegment or segment as used by http://tools.ietf.org/html/rfc3986#section-3.3 ? On 16 April 2013 15:12, Kris Borchers <kris(a)redhat.com&gt; wrote: My only issue with resourcePath is that it doesn't imply that the path is relative to the current pipe. I mean, it should be implied since you're already working with a pipe and we can be explicit about that in documentation but I still wish it was somehow in the name. I think that was the goal of using "nested" in the name but I already expressed my issue with that. Any other thoughts would be appreciated but I could be happy with resourcePath. On Apr 16, 2013, at 7:55 AM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: > +1 to resourcePath . it beats my thought of "superawesomenestedresourcethingy" > On Apr 16, 2013, at 8:39 AM, Christos Vasilakis <cvasilak(a)gmail.com&gt; wrote: > >> +1 >> >> I think it describes the feature better. >> >> >> On Apr 16, 2013, at 3:09 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >> >>> +1 on the "resourcePath", you nailed it ! >>> >>> >>> >>> On Tue, Apr 16, 2013 at 2:03 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >>> Hmmm, "nestedResource" isn't terrible but not crazy about "nested" since they're not necessarily nested but just related. Hmmmmm. >>> >>> It's not that I hate resource, I think it kind of makes sense if you know what we're talking about. How about something like "resourcePath" to be a little more explicit in what it is? Still not crazy about that but feel like it's better/closer to something that describes what it is. >>> >>> On Apr 16, 2013, at 6:44 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >>> >>>> Well, there seems to be an agreement on option #1 , except for the name "resource" , so let's find a name that we all agree on and so we can going further with this feature. >>>> My propositions: "nestedResource" , "fragment", "nestedURI" ... But I'm not really fan of all of my propositions ... >>>> Seb >>>> >>>> >>>> >>>> On Thu, Apr 11, 2013 at 4:07 PM, Summers Pittman <supittma(a)redhat.com&gt; wrote: >>>> With #1 is `resource` a URI? If so, will developers have to build the URI by hand? >>>> >>>> >>>> On 04/10/2013 10:48 AM, Christos Vasilakis wrote: >>>>> Hi >>>>> >>>>> I've prepared a document[1] that collectively describes the different approaches discussed in this thread for supporting the nested resources. It is split in two sections, ones that don't require modification to the existing API and ones that do >>>>> >>>>> Please have a look and let me know if I miss sth or interpret one approach wrong. >>>>> >>>>> Thanks >>>>> Christos >>>>> >>>>> [1] https://gist.github.com/cvasilak/4a5f51b8d1ad9cc7f21b >>>>> >>>>> On Apr 9, 2013, at 10:19 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >>>>> >>>>>> Hey, >>>>>> Like paging, could we start 2 gists : one with a side to side techno samples and another one with high level Specs ? I start a bit to get lost in this thread :) >>>>>> Just one remark when reading the last messages, one "must have" is to be able to retrieve all the comments for a post without EVER retrieving the post record, so >>>>>> /posts/1/comments will retrieve all the comments for post 1 but will actually never call posts/1 : in this covered in your last examples ? (spec could be : "by-pass parent GET resource" >>>>>> Seb >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Apr 9, 2013 at 9:03 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Apr 8, 2013 at 7:57 PM, Summers Pittman <supittma(a)redhat.com&gt; wrote: >>>>>> >>>>>> >>>>>> ----- Original Message ----- >>>>>> | From: "Matthias Wessendorf" <matzew(a)apache.org&gt; >>>>>> | To: "AeroGear Developer Mailing List" <aerogear-dev(a)lists.jboss.org&gt; >>>>>> | Sent: Monday, April 8, 2013 1:22:19 PM >>>>>> | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for nested endpoints >>>>>> | >>>>>> | OK, with the following server API: >>>>>> | >>>>>> | http://some.server.com/posts/1 >>>>>> | http://some.server.com/posts/1/comments >>>>>> | (and NO 'comments' collection on the ' http://some.server.com/posts/1 ' >>>>>> | response) >>>>>> | >>>>>> | Does this (today) 'myPipe.read(1)' already read the specific comments ( >>>>>> | http://some.server.com/posts/1/comments ) ?? >>>>>> | >>>>>> | ======= JAVA API ======= >>>>>> | Class Post: >>>>>> | - string: id; >>>>>> | - string: title; >>>>>> | - string: postContent; >>>>>> | - List<Comment> comments; >>>>>> | Class Comment: >>>>>> | - string username; >>>>>> | - string comment; >>>>>> | >>>>>> | Or would the IMPL expect an 'embedded' _comments_ collection on the response >>>>>> | of "GET http://some.server.com/posts/1 " ? >>>>>> >>>>>> It will not read /posts/1/comments if the Pipe's endpoint is /posts. If you have a comments collection on the post but no comments data in the response then the value for getComments will just be null. >>>>>> >>>>>> Ok - so this needs to be tweaked in Java too, since it's very common to model the REST endpoints like above; >>>>>> >>>>>> >>>>>> >>>>>> | >>>>>> | >>>>>> | >>>>>> | On Mon, Apr 8, 2013 at 7:05 PM, Summers Pittman < supittma(a)redhat.com > >>>>>> | wrote: >>>>>> | >>>>>> | >>>>>> | No. The get of pipe 1 would have to include the comments for get comments to >>>>>> | work >>>>>> | >>>>>> | Sent from my Android phone using TouchDown ( www.nitrodesk.com ) >>>>>> | >>>>>> | >>>>>> | -----Original Message----- >>>>>> | From: Matthias Wessendorf [ matzew(a)apache.org ] >>>>>> | Received: Monday, 08 Apr 2013, 12:04PM >>>>>> | To: AeroGear Developer Mailing List [ aerogear-dev(a)lists.jboss.org ] >>>>>> | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for nested endpoints >>>>>> | >>>>>> | >>>>>> | On Mon, Apr 8, 2013 at 5:57 PM, Summers Pittman < supittma(a)redhat.com > >>>>>> | wrote: >>>>>> | >>>>>> | > >>>>>> | > >>>>>> | > ----- Original Message ----- >>>>>> | > | From: "Matthias Wessendorf" < matzew(a)apache.org > >>>>>> | > | To: "AeroGear Developer Mailing List" < aerogear-dev(a)lists.jboss.org > >>>>>> | > | Sent: Monday, April 8, 2013 10:28:46 AM >>>>>> | > | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for nested >>>>>> | > endpoints >>>>>> | > | >>>>>> | > | or, like before said - reading "lists" (e.g. all the comments for >>>>>> | > specific >>>>>> | > | blog post): >>>>>> | > | https://gist.github.com/matzew/04f069dfbed2cc77a8b4 >>>>>> | > | >>>>>> | > | >>>>>> | > | For Java.... I guess...... resolving this URL: >>>>>> | > | http://some.server.com/posts/1/comments >>>>>> | > | >>>>>> | > | could be done with this - right ? >>>>>> | > | >>>>>> | > | ======= >>>>>> | > | Class Post: >>>>>> | > | - string: title; >>>>>> | > | - string: postContent; >>>>>> | > | - List<Comment> comments; >>>>>> | > | Class Comment: >>>>>> | > | - string username; >>>>>> | > | - string comment; >>>>>> | > | >>>>>> | > | >>>>>> | > | // get all the comments for 1: >>>>>> | > | Post myPostOne = postPipe.read("1"); >>>>>> | > | myPostOne.getComments(); >>>>>> | > | >>>>>> | > | // get all the comments for 2: >>>>>> | > | Post myPostTwo = postPipe.read("2"); >>>>>> | > | myPostTwo.getComments(); >>>>>> | > | ======= >>>>>> | > >>>>>> | > It can be done with that yes. My concern was more when we had a Pipe of >>>>>> | > type <Post> and a readForResource(String property) method. >>>>>> | >>>>>> | >>>>>> | Ok - one more question >>>>>> | >>>>>> | >>>>>> | So... when doing: myPipe.read(1); does that "only" issue a GET against the ' >>>>>> | http://some.server.com/posts/1 ' resource? >>>>>> | >>>>>> | A second get, for the comments collection is than issued when calling >>>>>> | myPostOne.getComments();? >>>>>> | (GET against ' http://some.server.com/posts/1/comments' )? >>>>>> | >>>>>> | >>>>>> | >>>>>> | >>>>>> | > The type information of the property isn't available unless we can infer >>>>>> | > it from the Post object. >>>>>> | > >>>>>> | >>>>>> | >>>>>> | >>>>>> | >>>>>> | >>>>>> | > >>>>>> | > >>>>>> | > | >>>>>> | > | >>>>>> | > | Greetings, >>>>>> | > | Matthias >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | On Fri, Apr 5, 2013 at 2:37 PM, Matthias Wessendorf < matzew(a)apache.org > >>>>>> | > | wrote: >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | Thought a bit more about it and chatted with friends, >>>>>> | > | >>>>>> | > | the issue with the sub pipes is: it adds state and is perhaps an API >>>>>> | > | construct that is a bit hard to understand (see all the discussions here) >>>>>> | > | >>>>>> | > | Not sure - but currently we can access "kid resources", with our API - >>>>>> | > right >>>>>> | > | ? >>>>>> | > | >>>>>> | > | https://gist.github.com/matzew/6ab432e437b9a017a21d >>>>>> | > | >>>>>> | > | >>>>>> | > | Perhaps it's better to just keep it that way? This has the benefit of >>>>>> | > using >>>>>> | > | an established and know API, the different pipes are accessible via the >>>>>> | > | pipeline object; >>>>>> | > | >>>>>> | > | And the code is not too much code; it's simply an explicit pipe ... >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | On Fri, Apr 5, 2013 at 10:56 AM, Matthias Wessendorf < matzew(a)apache.org >>>>>> | > | > >>>>>> | > | wrote: >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | On Fri, Apr 5, 2013 at 10:52 AM, Sebastien Blanc < scm.blanc(a)gmail.com > >>>>>> | > | wrote: >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | On Fri, Apr 5, 2013 at 10:36 AM, Matthias Wessendorf < matzew(a)apache.org >>>>>> | > | > >>>>>> | > | wrote: >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | On Fri, Apr 5, 2013 at 10:14 AM, Christos Vasilakis < cvasilak(a)gmail.com >>>>>> | > | > >>>>>> | > | wrote: >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | Hi >>>>>> | > | >>>>>> | > | some comments >>>>>> | > | >>>>>> | > | I believe the method can't be used since you don't know the team for the >>>>>> | > | players so you can't retrieve the pipe directly..right? >>>>>> | > | >>>>>> | > | Isn't that really up to the impl of the rest service? >>>>>> | > | They could return a list of teamsHePlayed for; >>>>>> | > | >>>>>> | > | So, let's not tie this API to a specific, not existing RESTful service; >>>>>> | > | >>>>>> | > | +1, we don't need to care about that, we must just focus on how we can >>>>>> | > | declare and call nested pipes. >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | yep >>>>>> | > | >>>>>> | > | I guess this is perhaps the closest we can come to : >>>>>> | > | >>>>>> | > | id<AGPipe> allOwnersInNewYorkPipe = [leaguesPipe subPipe:@"owners" >>>>>> | > | for:@"newyork"]; >>>>>> | > | >>>>>> | > | and than.... on the 'leaguesPipe' you can access its kids with something >>>>>> | > like >>>>>> | > | : >>>>>> | > | >>>>>> | > | NSArray* kids = [leaguesPipe subPipes]; >>>>>> | > | >>>>>> | > | >>>>>> | > | However, that adds some state to a specific pipe object >>>>>> | > | >>>>>> | > | >>>>>> | > | -M >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | getPlayers ( Callback < List < Player >> callback ) { >>>>>> | > | pipe . get ( "player" ). read ( callback ); >>>>>> | > | } >>>>>> | > | >>>>>> | > | Further my questions is, how is a third (or arbitrary) nested resources >>>>>> | > are >>>>>> | > | supported? I mean for a url schema like this >>>>>> | > | >>>>>> | > | soccer.org/leagues/ {id}/teams/{id}/players/{id} >>>>>> | > | >>>>>> | > | first we access the leagues: >>>>>> | > | --- >>>>>> | > | getLeagues(Callback<List<Leagues>> callback) { >>>>>> | > | pipe.get("leagues").read(callback); >>>>>> | > | } >>>>>> | > | --- >>>>>> | > | then the teams for this league: >>>>>> | > | --- >>>>>> | > | getTeamsOnLeaque(Leaque league, Callback<List<Team>> callback) { >>>>>> | > | pipe.junction("league","team").read(leaque, callback); >>>>>> | > | } >>>>>> | > | --- >>>>>> | > | ..and then we access the "Players" for a "Team": >>>>>> | > | --- >>>>>> | > | getPlayersOnTeam(Team team, Callback<List<Player>> callback) { >>>>>> | > | pipe.junction("team","player").read(team, callback); >>>>>> | > | } >>>>>> | > | --- >>>>>> | > | But where is the "League" information to fill the "/leagues/{id}..." >>>>>> | > path? >>>>>> | > | >>>>>> | > | >>>>>> | > | I'd assume the information is 'inherited' out of a given pipe, when >>>>>> | > doing the >>>>>> | > | 'join' >>>>>> | > | >>>>>> | > | e.g. like >>>>>> | > | myTeamsForLeaguePipe = leaguePipe.junction("team"); >>>>>> | > | >>>>>> | > | not sure... >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | Unless you mean something like: >>>>>> | > | --- >>>>>> | > | getPlayersOnTeam(Leaque league, Team team, Callback<List<Player>> >>>>>> | > callback) { >>>>>> | > | pipe.junction("league", "team","player").read(league, team, callback); >>>>>> | > | } >>>>>> | > | >>>>>> | > | I am not sure if that is really easy to understand/use >>>>>> | > | >>>>>> | > | Yes and the term "junction" is a bit confusing as it don't express >>>>>> | > explicitly >>>>>> | > | a parent/child relation. >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | --- >>>>>> | > | >>>>>> | > | probably I am missing sth.. >>>>>> | > | >>>>>> | > | Thanks, >>>>>> | > | Christos >>>>>> | > | >>>>>> | > | On Apr 4, 2013, at 5:52 PM, Summers Pittman < supittma(a)redhat.com > >>>>>> | > wrote: >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | What if we create a new metaphor, a Junction. >>>>>> | > | >>>>>> | > | https://gist.github.com/secondsun/dcf5682b6ff17c729d9a >>>>>> | > | >>>>>> | > | It joins two pipes together and can be used over and over again with >>>>>> | > | different data? >>>>>> | > | It isn't a Pipe though, but perhaps that could be changed to look more >>>>>> | > like >>>>>> | > | Christos's previous example. >>>>>> | > | >>>>>> | > | At the very least I like the words "junction" or "join" more than "of" >>>>>> | > | >>>>>> | > | ----- Original Message ----- >>>>>> | > | | From: "Christos Vasilakis" < cvasilak(a)gmail.com > >>>>>> | > | | To: "AeroGear Developer Mailing List" < aerogear-dev(a)lists.jboss.org > >>>>>> | > | | Sent: Wednesday, April 3, 2013 3:03:02 AM >>>>>> | > | | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for nested >>>>>> | > | | endpoints >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | On Apr 2, 2013, at 4:03 PM, Matthias Wessendorf < matzew(a)apache.org > >>>>>> | > | | wrote: >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | Two thoughts.... >>>>>> | > | | >>>>>> | > | | 1) the 'original' leaguesPipe has no clue about the subpipes, right ? >>>>>> | > | | 2) should a pipe offer a 'getter' for all it's sub pipes ? >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | Just a thought is instead of using Pipe, to continue using Pipeline >>>>>> | > adding >>>>>> | > | | an >>>>>> | > | | extra parameter " of" for specifying the parent : E.g.: >>>>>> | > | | >>>>>> | > | | ….. >>>>>> | > | | id<AGPipe> leaguesPipe = [pipeline pipe@"leagues"]; >>>>>> | > | | >>>>>> | > | | id<AGPipe> allTeamsInSeattlePipe = [pipeline subPipe@"teams" of >>>>>> | > | | :leaguesPipe >>>>>> | > | | for:@"seattle"] >>>>>> | > | | >>>>>> | > | | id<AGPipe> allPlayersInTrebuchetPipe = [pipeline subPipe:@"players" >>>>>> | > of: >>>>>> | > | | allTeamsInSeattlePipe for:@"trebuchet"]; >>>>>> | > | | ….. >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | Wdyt? >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | -M >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | Thanks, >>>>>> | > | | Christos >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | soccer.org/leagues/seattle/teams/trebuchet/players/foo - > >>>>>> | > | | [[pipeline pipe:@"players" pathParams:@[@"seattle", @"trebuchet"]] >>>>>> | > read >>>>>> | > | | :@"foo"] .. >>>>>> | > | | ----- >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | Wdyt? >>>>>> | > | | >>>>>> | > | | Thanks >>>>>> | > | | Christos >>>>>> | > | | >>>>>> | > | | On Mar 18, 2013, at 1:12 PM, Sebastien Blanc < scm.blanc(a)gmail.com > >>>>>> | > wrote: >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | Well, that would not be possible, for that you will have to create a >>>>>> | > | | "child" >>>>>> | > | | pipe. But I agree, that is maybe no optimal ... >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | On Fri, Mar 15, 2013 at 6:44 PM, Summers Pittman < supittma(a)redhat.com >>>>>> | > | | > >>>>>> | > | | wrote: >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | On 03/15/2013 01:34 PM, Sebastien Blanc wrote: >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | I like the idea but I will more see that has a method/function for the >>>>>> | > | | pipelineManager (and will be easier to implement in JS, I think) : >>>>>> | > | | >>>>>> | > | | var myParentPipe = >>>>>> | > Aerogear.Pipeline({name:"parentPipe"}).pipes.parentPipe >>>>>> | > | | >>>>>> | > | | var myChildPipe = Aerogear.Pipeline.fromParent(myParentPipe, {options} >>>>>> | > ) >>>>>> | > | | What would it look like to get a child record from a parent? >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | On Fri, Mar 15, 2013 at 5:37 PM, Douglas Campos < qmx(a)qmx.me > wrote: >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | What about this? >>>>>> | > | | >>>>>> | > | | Pipeline<Post> postPipeline = … >>>>>> | > | | Post post = // get from the pipeline >>>>>> | > | | Pipeline<Comment> >>>>>> | > | | postPipeline.childPipelineForOrOtherWeirdName(Comment.class, post) >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | On 15/03/2013, at 12:26, Summers Pittman < supittma(a)redhat.com > >>>>>> | > wrote: >>>>>> | > | | >>>>>> | > | | > On 03/14/2013 04:48 AM, Matthias Wessendorf wrote: >>>>>> | > | | >> >>>>>> | > | | >> >>>>>> | > | | >> On Thu, Mar 14, 2013 at 9:32 AM, Sebastien Blanc < >>>>>> | > scm.blanc(a)gmail.com > >>>>>> | > | | >> wrote: >>>>>> | > | | >> Hi, >>>>>> | > | | >> While I was playing with scaffolding and tried to build a simple >>>>>> | > Blog >>>>>> | > | | >> Application with Aerogear I faced the current situation : >>>>>> | > | | >> I have a Post object which contains many Comment objects. Now I >>>>>> | > want to >>>>>> | > | | >> call my Post pipe to retrieve the related comments, I have >>>>>> | > currently 2 >>>>>> | > | | >> options : >>>>>> | > | | >> >>>>>> | > | | >> /posts/1 -> assuming comments will be implicitly retrieved (eager >>>>>> | > | | >> loading) >>>>>> | > | | >> /comments/?postid=1 >>>>>> | > | | >> >>>>>> | > | | >> But regarding our model the correct form should be : >>>>>> | > | | >> >>>>>> | > | | >> /posts/1/comments >>>>>> | > | | >> >>>>>> | > | | >> >>>>>> | > | | >> +1 >>>>>> | > | | >> that is the ideal way to model URIs for "nested" resources. >>>>>> | > | | >> >>>>>> | > | | >> See [1], extracted from [2] >>>>>> | > | | >> >>>>>> | > | | >> >>>>>> | > | | >> >>>>>> | > | | >> But, AFAIK, with the current API, it is not possible to define this >>>>>> | > last >>>>>> | > | | >> pattern (at least for JS and iOs, confirmed by Matzew). When doing a >>>>>> | > | | >> read >>>>>> | > | | >> we can pass an id option but as mentioned in the doc, this id will >>>>>> | > | | >> always >>>>>> | > | | >> be append to the endpoint. >>>>>> | > | | >> >>>>>> | > | | >> >>>>>> | > | | >> Well, it is possible - but in a very (IMO) ugly way: >>>>>> | > | | >> >>>>>> | > | | >> https://gist.github.com/matzew/6ab432e437b9a017a21d >>>>>> | > | | >> >>>>>> | > | | >> >>>>>> | > | | >> >>>>>> | > | | >> >>>>>> | > | | >> IMO, we should be able to support this pattern but for now I'm not >>>>>> | > | | >> really >>>>>> | > | | >> sure how to specify this in our API, so if you have any ideas >>>>>> | > feedback >>>>>> | > | | >> this thread has been made for you ! >>>>>> | > | | >> >>>>>> | > | | >> >>>>>> | > | | >> >>>>>> | > | | >> Suggestion: Enhance the read function - example: >>>>>> | > | | >> >>>>>> | > | | >> https://gist.github.com/matzew/04f069dfbed2cc77a8b4 >>>>>> | > | | > I'm thinking of the inverse myself. Add a "ParentPath" property >>>>>> | > which can >>>>>> | > | | > be used to extract information from parent objects. >>>>>> | > | | > >>>>>> | > | | > https://gist.github.com/secondsun/17ce96082eda37dbd10e >>>>>> | > | | > >>>>>> | > | | >> >>>>>> | > | | >> >>>>>> | > | | >> -Matthias >>>>>> | > | | >> >>>>>> | > | | >> >>>>>> | > | | >> [1] >>>>>> | > | | >> >>>>>> | > http://www.infoq.com/resource/articles/rest-introduction/en/resources/fig... >>>>>> | > | | >> [2] http://www.infoq.com/articles/rest-introduction >>>>>> | > | | >> >>>>>> | > | | >> >>>>>> | > | | >> >>>>>> | > | | >> >>>>>> | > | | >> Seb >>>>>> | > | | >> >>>>>> | > | | >> >>>>>> | > | | >> _______________________________________________ >>>>>> | > | | >> aerogear-dev mailing list >>>>>> | > | | >> aerogear-dev(a)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 >>>>>> | > | | >> >>>>>> | > | | >> _______________________________________________ >>>>>> | > | | >> aerogear-dev mailing list >>>>>> | > | | >> >>>>>> | > | | >> aerogear-dev(a)lists.jboss.org >>>>>> | > | | >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> | > | | > >>>>>> | > | | > _______________________________________________ >>>>>> | > | | > aerogear-dev mailing list >>>>>> | > | | > aerogear-dev(a)lists.jboss.org >>>>>> | > | | > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> | > | | >>>>>> | > | | -- qmx >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | _______________________________________________ >>>>>> | > | | aerogear-dev mailing list >>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | _______________________________________________ >>>>>> | > | | aerogear-dev mailing list aerogear-dev(a)lists.jboss.org >>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | _______________________________________________ >>>>>> | > | | aerogear-dev mailing list >>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> | > | | >>>>>> | > | | _______________________________________________ >>>>>> | > | | aerogear-dev mailing list >>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | _______________________________________________ >>>>>> | > | | aerogear-dev mailing list >>>>>> | > | | aerogear-dev(a)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 >>>>>> | > | | _______________________________________________ >>>>>> | > | | aerogear-dev mailing list >>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | _______________________________________________ >>>>>> | > | | aerogear-dev mailing list >>>>>> | > | | aerogear-dev(a)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 >>>>>> | > | | _______________________________________________ >>>>>> | > | | aerogear-dev mailing list >>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> | > | | >>>>>> | > | | >>>>>> | > | | _______________________________________________ >>>>>> | > | | aerogear-dev mailing list >>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> | > | >>>>>> | > | _______________________________________________ >>>>>> | > | aerogear-dev mailing list >>>>>> | > | aerogear-dev(a)lists.jboss.org >>>>>> | > | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> | > | >>>>>> | > | >>>>>> | > | _______________________________________________ >>>>>> | > | aerogear-dev mailing list >>>>>> | > | aerogear-dev(a)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 >>>>>> | > | >>>>>> | > | _______________________________________________ >>>>>> | > | aerogear-dev mailing list >>>>>> | > | aerogear-dev(a)lists.jboss.org >>>>>> | > | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> | > | >>>>>> | > | >>>>>> | > | _______________________________________________ >>>>>> | > | aerogear-dev mailing list >>>>>> | > | aerogear-dev(a)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 >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | -- >>>>>> | > | Matthias Wessendorf >>>>>> | > | >>>>>> | > | blog: http://matthiaswessendorf.wordpress.com/ >>>>>> | > | sessions: http://www.slideshare.net/mwessendorf >>>>>> | > | twitter: http://twitter.com/mwessendorf >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | -- >>>>>> | > | Matthias Wessendorf >>>>>> | > | >>>>>> | > | blog: http://matthiaswessendorf.wordpress.com/ >>>>>> | > | sessions: http://www.slideshare.net/mwessendorf >>>>>> | > | twitter: http://twitter.com/mwessendorf >>>>>> | > | >>>>>> | > | _______________________________________________ >>>>>> | > | aerogear-dev mailing list >>>>>> | > | aerogear-dev(a)lists.jboss.org >>>>>> | > | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> | > >>>>>> | > _______________________________________________ >>>>>> | > aerogear-dev mailing list >>>>>> | > aerogear-dev(a)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 >>>>>> | >>>>>> | _______________________________________________ >>>>>> | aerogear-dev mailing list >>>>>> | aerogear-dev(a)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 >>>>>> | >>>>>> | _______________________________________________ >>>>>> | aerogear-dev mailing list >>>>>> | aerogear-dev(a)lists.jboss.org >>>>>> | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev(a)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 >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

doh! Sorry. I was just looking at the first examples in the gist and did not realize these could have multiple segments. On 16 April 2013 15:18, Kris Borchers <kris(a)redhat.com&gt; wrote: Hmm, I like the idea of looking to standards but if I'm reading it right, segment there means just a portion of the URI between slashes, not multiple slash-separated segments. On Apr 16, 2013, at 8:14 AM, Daniel Bevenius <daniel.bevenius(a)gmail.com&gt; wrote: > I agree, when I read resourcePath I read that as a path to resource. How about pathSegment or segment as used by http://tools.ietf.org/html/rfc3986#section-3.3 ? > > > On 16 April 2013 15:12, Kris Borchers <kris(a)redhat.com&gt; wrote: > My only issue with resourcePath is that it doesn't imply that the path is relative to the current pipe. I mean, it should be implied since you're already working with a pipe and we can be explicit about that in documentation but I still wish it was somehow in the name. I think that was the goal of using "nested" in the name but I already expressed my issue with that. Any other thoughts would be appreciated but I could be happy with resourcePath. > > On Apr 16, 2013, at 7:55 AM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: > >> +1 to resourcePath . it beats my thought of "superawesomenestedresourcethingy" >> On Apr 16, 2013, at 8:39 AM, Christos Vasilakis <cvasilak(a)gmail.com&gt; wrote: >> >>> +1 >>> >>> I think it describes the feature better. >>> >>> >>> On Apr 16, 2013, at 3:09 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >>> >>>> +1 on the "resourcePath", you nailed it ! >>>> >>>> >>>> >>>> On Tue, Apr 16, 2013 at 2:03 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >>>> Hmmm, "nestedResource" isn't terrible but not crazy about "nested" since they're not necessarily nested but just related. Hmmmmm. >>>> >>>> It's not that I hate resource, I think it kind of makes sense if you know what we're talking about. How about something like "resourcePath" to be a little more explicit in what it is? Still not crazy about that but feel like it's better/closer to something that describes what it is. >>>> >>>> On Apr 16, 2013, at 6:44 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >>>> >>>>> Well, there seems to be an agreement on option #1 , except for the name "resource" , so let's find a name that we all agree on and so we can going further with this feature. >>>>> My propositions: "nestedResource" , "fragment", "nestedURI" ... But I'm not really fan of all of my propositions ... >>>>> Seb >>>>> >>>>> >>>>> >>>>> On Thu, Apr 11, 2013 at 4:07 PM, Summers Pittman <supittma(a)redhat.com&gt; wrote: >>>>> With #1 is `resource` a URI? If so, will developers have to build the URI by hand? >>>>> >>>>> >>>>> On 04/10/2013 10:48 AM, Christos Vasilakis wrote: >>>>>> Hi >>>>>> >>>>>> I've prepared a document[1] that collectively describes the different approaches discussed in this thread for supporting the nested resources. It is split in two sections, ones that don't require modification to the existing API and ones that do >>>>>> >>>>>> Please have a look and let me know if I miss sth or interpret one approach wrong. >>>>>> >>>>>> Thanks >>>>>> Christos >>>>>> >>>>>> [1] https://gist.github.com/cvasilak/4a5f51b8d1ad9cc7f21b >>>>>> >>>>>> On Apr 9, 2013, at 10:19 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >>>>>> >>>>>>> Hey, >>>>>>> Like paging, could we start 2 gists : one with a side to side techno samples and another one with high level Specs ? I start a bit to get lost in this thread :) >>>>>>> Just one remark when reading the last messages, one "must have" is to be able to retrieve all the comments for a post without EVER retrieving the post record, so >>>>>>> /posts/1/comments will retrieve all the comments for post 1 but will actually never call posts/1 : in this covered in your last examples ? (spec could be : "by-pass parent GET resource" >>>>>>> Seb >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Apr 9, 2013 at 9:03 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Apr 8, 2013 at 7:57 PM, Summers Pittman <supittma(a)redhat.com&gt; wrote: >>>>>>> >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>> | From: "Matthias Wessendorf" <matzew(a)apache.org&gt; >>>>>>> | To: "AeroGear Developer Mailing List" <aerogear-dev(a)lists.jboss.org&gt; >>>>>>> | Sent: Monday, April 8, 2013 1:22:19 PM >>>>>>> | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for nested endpoints >>>>>>> | >>>>>>> | OK, with the following server API: >>>>>>> | >>>>>>> | http://some.server.com/posts/1 >>>>>>> | http://some.server.com/posts/1/comments >>>>>>> | (and NO 'comments' collection on the ' http://some.server.com/posts/1 ' >>>>>>> | response) >>>>>>> | >>>>>>> | Does this (today) 'myPipe.read(1)' already read the specific comments ( >>>>>>> | http://some.server.com/posts/1/comments ) ?? >>>>>>> | >>>>>>> | ======= JAVA API ======= >>>>>>> | Class Post: >>>>>>> | - string: id; >>>>>>> | - string: title; >>>>>>> | - string: postContent; >>>>>>> | - List<Comment> comments; >>>>>>> | Class Comment: >>>>>>> | - string username; >>>>>>> | - string comment; >>>>>>> | >>>>>>> | Or would the IMPL expect an 'embedded' _comments_ collection on the response >>>>>>> | of "GET http://some.server.com/posts/1 " ? >>>>>>> >>>>>>> It will not read /posts/1/comments if the Pipe's endpoint is /posts. If you have a comments collection on the post but no comments data in the response then the value for getComments will just be null. >>>>>>> >>>>>>> Ok - so this needs to be tweaked in Java too, since it's very common to model the REST endpoints like above; >>>>>>> >>>>>>> >>>>>>> >>>>>>> | >>>>>>> | >>>>>>> | >>>>>>> | On Mon, Apr 8, 2013 at 7:05 PM, Summers Pittman < supittma(a)redhat.com > >>>>>>> | wrote: >>>>>>> | >>>>>>> | >>>>>>> | No. The get of pipe 1 would have to include the comments for get comments to >>>>>>> | work >>>>>>> | >>>>>>> | Sent from my Android phone using TouchDown ( www.nitrodesk.com ) >>>>>>> | >>>>>>> | >>>>>>> | -----Original Message----- >>>>>>> | From: Matthias Wessendorf [ matzew(a)apache.org ] >>>>>>> | Received: Monday, 08 Apr 2013, 12:04PM >>>>>>> | To: AeroGear Developer Mailing List [ aerogear-dev(a)lists.jboss.org ] >>>>>>> | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for nested endpoints >>>>>>> | >>>>>>> | >>>>>>> | On Mon, Apr 8, 2013 at 5:57 PM, Summers Pittman < supittma(a)redhat.com > >>>>>>> | wrote: >>>>>>> | >>>>>>> | > >>>>>>> | > >>>>>>> | > ----- Original Message ----- >>>>>>> | > | From: "Matthias Wessendorf" < matzew(a)apache.org > >>>>>>> | > | To: "AeroGear Developer Mailing List" < aerogear-dev(a)lists.jboss.org > >>>>>>> | > | Sent: Monday, April 8, 2013 10:28:46 AM >>>>>>> | > | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for nested >>>>>>> | > endpoints >>>>>>> | > | >>>>>>> | > | or, like before said - reading "lists" (e.g. all the comments for >>>>>>> | > specific >>>>>>> | > | blog post): >>>>>>> | > | https://gist.github.com/matzew/04f069dfbed2cc77a8b4 >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | For Java.... I guess...... resolving this URL: >>>>>>> | > | http://some.server.com/posts/1/comments >>>>>>> | > | >>>>>>> | > | could be done with this - right ? >>>>>>> | > | >>>>>>> | > | ======= >>>>>>> | > | Class Post: >>>>>>> | > | - string: title; >>>>>>> | > | - string: postContent; >>>>>>> | > | - List<Comment> comments; >>>>>>> | > | Class Comment: >>>>>>> | > | - string username; >>>>>>> | > | - string comment; >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | // get all the comments for 1: >>>>>>> | > | Post myPostOne = postPipe.read("1"); >>>>>>> | > | myPostOne.getComments(); >>>>>>> | > | >>>>>>> | > | // get all the comments for 2: >>>>>>> | > | Post myPostTwo = postPipe.read("2"); >>>>>>> | > | myPostTwo.getComments(); >>>>>>> | > | ======= >>>>>>> | > >>>>>>> | > It can be done with that yes. My concern was more when we had a Pipe of >>>>>>> | > type <Post> and a readForResource(String property) method. >>>>>>> | >>>>>>> | >>>>>>> | Ok - one more question >>>>>>> | >>>>>>> | >>>>>>> | So... when doing: myPipe.read(1); does that "only" issue a GET against the ' >>>>>>> | http://some.server.com/posts/1 ' resource? >>>>>>> | >>>>>>> | A second get, for the comments collection is than issued when calling >>>>>>> | myPostOne.getComments();? >>>>>>> | (GET against ' http://some.server.com/posts/1/comments' )? >>>>>>> | >>>>>>> | >>>>>>> | >>>>>>> | >>>>>>> | > The type information of the property isn't available unless we can infer >>>>>>> | > it from the Post object. >>>>>>> | > >>>>>>> | >>>>>>> | >>>>>>> | >>>>>>> | >>>>>>> | >>>>>>> | > >>>>>>> | > >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | Greetings, >>>>>>> | > | Matthias >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | On Fri, Apr 5, 2013 at 2:37 PM, Matthias Wessendorf < matzew(a)apache.org > >>>>>>> | > | wrote: >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | Thought a bit more about it and chatted with friends, >>>>>>> | > | >>>>>>> | > | the issue with the sub pipes is: it adds state and is perhaps an API >>>>>>> | > | construct that is a bit hard to understand (see all the discussions here) >>>>>>> | > | >>>>>>> | > | Not sure - but currently we can access "kid resources", with our API - >>>>>>> | > right >>>>>>> | > | ? >>>>>>> | > | >>>>>>> | > | https://gist.github.com/matzew/6ab432e437b9a017a21d >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | Perhaps it's better to just keep it that way? This has the benefit of >>>>>>> | > using >>>>>>> | > | an established and know API, the different pipes are accessible via the >>>>>>> | > | pipeline object; >>>>>>> | > | >>>>>>> | > | And the code is not too much code; it's simply an explicit pipe ... >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | On Fri, Apr 5, 2013 at 10:56 AM, Matthias Wessendorf < matzew(a)apache.org >>>>>>> | > | > >>>>>>> | > | wrote: >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | On Fri, Apr 5, 2013 at 10:52 AM, Sebastien Blanc < scm.blanc(a)gmail.com > >>>>>>> | > | wrote: >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | On Fri, Apr 5, 2013 at 10:36 AM, Matthias Wessendorf < matzew(a)apache.org >>>>>>> | > | > >>>>>>> | > | wrote: >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | On Fri, Apr 5, 2013 at 10:14 AM, Christos Vasilakis < cvasilak(a)gmail.com >>>>>>> | > | > >>>>>>> | > | wrote: >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | Hi >>>>>>> | > | >>>>>>> | > | some comments >>>>>>> | > | >>>>>>> | > | I believe the method can't be used since you don't know the team for the >>>>>>> | > | players so you can't retrieve the pipe directly..right? >>>>>>> | > | >>>>>>> | > | Isn't that really up to the impl of the rest service? >>>>>>> | > | They could return a list of teamsHePlayed for; >>>>>>> | > | >>>>>>> | > | So, let's not tie this API to a specific, not existing RESTful service; >>>>>>> | > | >>>>>>> | > | +1, we don't need to care about that, we must just focus on how we can >>>>>>> | > | declare and call nested pipes. >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | yep >>>>>>> | > | >>>>>>> | > | I guess this is perhaps the closest we can come to : >>>>>>> | > | >>>>>>> | > | id<AGPipe> allOwnersInNewYorkPipe = [leaguesPipe subPipe:@"owners" >>>>>>> | > | for:@"newyork"]; >>>>>>> | > | >>>>>>> | > | and than.... on the 'leaguesPipe' you can access its kids with something >>>>>>> | > like >>>>>>> | > | : >>>>>>> | > | >>>>>>> | > | NSArray* kids = [leaguesPipe subPipes]; >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | However, that adds some state to a specific pipe object >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | -M >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | getPlayers ( Callback < List < Player >> callback ) { >>>>>>> | > | pipe . get ( "player" ). read ( callback ); >>>>>>> | > | } >>>>>>> | > | >>>>>>> | > | Further my questions is, how is a third (or arbitrary) nested resources >>>>>>> | > are >>>>>>> | > | supported? I mean for a url schema like this >>>>>>> | > | >>>>>>> | > | soccer.org/leagues/ {id}/teams/{id}/players/{id} >>>>>>> | > | >>>>>>> | > | first we access the leagues: >>>>>>> | > | --- >>>>>>> | > | getLeagues(Callback<List<Leagues>> callback) { >>>>>>> | > | pipe.get("leagues").read(callback); >>>>>>> | > | } >>>>>>> | > | --- >>>>>>> | > | then the teams for this league: >>>>>>> | > | --- >>>>>>> | > | getTeamsOnLeaque(Leaque league, Callback<List<Team>> callback) { >>>>>>> | > | pipe.junction("league","team").read(leaque, callback); >>>>>>> | > | } >>>>>>> | > | --- >>>>>>> | > | ..and then we access the "Players" for a "Team": >>>>>>> | > | --- >>>>>>> | > | getPlayersOnTeam(Team team, Callback<List<Player>> callback) { >>>>>>> | > | pipe.junction("team","player").read(team, callback); >>>>>>> | > | } >>>>>>> | > | --- >>>>>>> | > | But where is the "League" information to fill the "/leagues/{id}..." >>>>>>> | > path? >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | I'd assume the information is 'inherited' out of a given pipe, when >>>>>>> | > doing the >>>>>>> | > | 'join' >>>>>>> | > | >>>>>>> | > | e.g. like >>>>>>> | > | myTeamsForLeaguePipe = leaguePipe.junction("team"); >>>>>>> | > | >>>>>>> | > | not sure... >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | Unless you mean something like: >>>>>>> | > | --- >>>>>>> | > | getPlayersOnTeam(Leaque league, Team team, Callback<List<Player>> >>>>>>> | > callback) { >>>>>>> | > | pipe.junction("league", "team","player").read(league, team, callback); >>>>>>> | > | } >>>>>>> | > | >>>>>>> | > | I am not sure if that is really easy to understand/use >>>>>>> | > | >>>>>>> | > | Yes and the term "junction" is a bit confusing as it don't express >>>>>>> | > explicitly >>>>>>> | > | a parent/child relation. >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | --- >>>>>>> | > | >>>>>>> | > | probably I am missing sth.. >>>>>>> | > | >>>>>>> | > | Thanks, >>>>>>> | > | Christos >>>>>>> | > | >>>>>>> | > | On Apr 4, 2013, at 5:52 PM, Summers Pittman < supittma(a)redhat.com > >>>>>>> | > wrote: >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | What if we create a new metaphor, a Junction. >>>>>>> | > | >>>>>>> | > | https://gist.github.com/secondsun/dcf5682b6ff17c729d9a >>>>>>> | > | >>>>>>> | > | It joins two pipes together and can be used over and over again with >>>>>>> | > | different data? >>>>>>> | > | It isn't a Pipe though, but perhaps that could be changed to look more >>>>>>> | > like >>>>>>> | > | Christos's previous example. >>>>>>> | > | >>>>>>> | > | At the very least I like the words "junction" or "join" more than "of" >>>>>>> | > | >>>>>>> | > | ----- Original Message ----- >>>>>>> | > | | From: "Christos Vasilakis" < cvasilak(a)gmail.com > >>>>>>> | > | | To: "AeroGear Developer Mailing List" < aerogear-dev(a)lists.jboss.org > >>>>>>> | > | | Sent: Wednesday, April 3, 2013 3:03:02 AM >>>>>>> | > | | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for nested >>>>>>> | > | | endpoints >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | On Apr 2, 2013, at 4:03 PM, Matthias Wessendorf < matzew(a)apache.org > >>>>>>> | > | | wrote: >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | Two thoughts.... >>>>>>> | > | | >>>>>>> | > | | 1) the 'original' leaguesPipe has no clue about the subpipes, right ? >>>>>>> | > | | 2) should a pipe offer a 'getter' for all it's sub pipes ? >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | Just a thought is instead of using Pipe, to continue using Pipeline >>>>>>> | > adding >>>>>>> | > | | an >>>>>>> | > | | extra parameter " of" for specifying the parent : E.g.: >>>>>>> | > | | >>>>>>> | > | | ….. >>>>>>> | > | | id<AGPipe> leaguesPipe = [pipeline pipe@"leagues"]; >>>>>>> | > | | >>>>>>> | > | | id<AGPipe> allTeamsInSeattlePipe = [pipeline subPipe@"teams" of >>>>>>> | > | | :leaguesPipe >>>>>>> | > | | for:@"seattle"] >>>>>>> | > | | >>>>>>> | > | | id<AGPipe> allPlayersInTrebuchetPipe = [pipeline subPipe:@"players" >>>>>>> | > of: >>>>>>> | > | | allTeamsInSeattlePipe for:@"trebuchet"]; >>>>>>> | > | | ….. >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | Wdyt? >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | -M >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | Thanks, >>>>>>> | > | | Christos >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | soccer.org/leagues/seattle/teams/trebuchet/players/foo - > >>>>>>> | > | | [[pipeline pipe:@"players" pathParams:@[@"seattle", @"trebuchet"]] >>>>>>> | > read >>>>>>> | > | | :@"foo"] .. >>>>>>> | > | | ----- >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | Wdyt? >>>>>>> | > | | >>>>>>> | > | | Thanks >>>>>>> | > | | Christos >>>>>>> | > | | >>>>>>> | > | | On Mar 18, 2013, at 1:12 PM, Sebastien Blanc < scm.blanc(a)gmail.com > >>>>>>> | > wrote: >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | Well, that would not be possible, for that you will have to create a >>>>>>> | > | | "child" >>>>>>> | > | | pipe. But I agree, that is maybe no optimal ... >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | On Fri, Mar 15, 2013 at 6:44 PM, Summers Pittman < supittma(a)redhat.com >>>>>>> | > | | > >>>>>>> | > | | wrote: >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | On 03/15/2013 01:34 PM, Sebastien Blanc wrote: >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | I like the idea but I will more see that has a method/function for the >>>>>>> | > | | pipelineManager (and will be easier to implement in JS, I think) : >>>>>>> | > | | >>>>>>> | > | | var myParentPipe = >>>>>>> | > Aerogear.Pipeline({name:"parentPipe"}).pipes.parentPipe >>>>>>> | > | | >>>>>>> | > | | var myChildPipe = Aerogear.Pipeline.fromParent(myParentPipe, {options} >>>>>>> | > ) >>>>>>> | > | | What would it look like to get a child record from a parent? >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | On Fri, Mar 15, 2013 at 5:37 PM, Douglas Campos < qmx(a)qmx.me > wrote: >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | What about this? >>>>>>> | > | | >>>>>>> | > | | Pipeline<Post> postPipeline = … >>>>>>> | > | | Post post = // get from the pipeline >>>>>>> | > | | Pipeline<Comment> >>>>>>> | > | | postPipeline.childPipelineForOrOtherWeirdName(Comment.class, post) >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | On 15/03/2013, at 12:26, Summers Pittman < supittma(a)redhat.com > >>>>>>> | > wrote: >>>>>>> | > | | >>>>>>> | > | | > On 03/14/2013 04:48 AM, Matthias Wessendorf wrote: >>>>>>> | > | | >> >>>>>>> | > | | >> >>>>>>> | > | | >> On Thu, Mar 14, 2013 at 9:32 AM, Sebastien Blanc < >>>>>>> | > scm.blanc(a)gmail.com > >>>>>>> | > | | >> wrote: >>>>>>> | > | | >> Hi, >>>>>>> | > | | >> While I was playing with scaffolding and tried to build a simple >>>>>>> | > Blog >>>>>>> | > | | >> Application with Aerogear I faced the current situation : >>>>>>> | > | | >> I have a Post object which contains many Comment objects. Now I >>>>>>> | > want to >>>>>>> | > | | >> call my Post pipe to retrieve the related comments, I have >>>>>>> | > currently 2 >>>>>>> | > | | >> options : >>>>>>> | > | | >> >>>>>>> | > | | >> /posts/1 -> assuming comments will be implicitly retrieved (eager >>>>>>> | > | | >> loading) >>>>>>> | > | | >> /comments/?postid=1 >>>>>>> | > | | >> >>>>>>> | > | | >> But regarding our model the correct form should be : >>>>>>> | > | | >> >>>>>>> | > | | >> /posts/1/comments >>>>>>> | > | | >> >>>>>>> | > | | >> >>>>>>> | > | | >> +1 >>>>>>> | > | | >> that is the ideal way to model URIs for "nested" resources. >>>>>>> | > | | >> >>>>>>> | > | | >> See [1], extracted from [2] >>>>>>> | > | | >> >>>>>>> | > | | >> >>>>>>> | > | | >> >>>>>>> | > | | >> But, AFAIK, with the current API, it is not possible to define this >>>>>>> | > last >>>>>>> | > | | >> pattern (at least for JS and iOs, confirmed by Matzew). When doing a >>>>>>> | > | | >> read >>>>>>> | > | | >> we can pass an id option but as mentioned in the doc, this id will >>>>>>> | > | | >> always >>>>>>> | > | | >> be append to the endpoint. >>>>>>> | > | | >> >>>>>>> | > | | >> >>>>>>> | > | | >> Well, it is possible - but in a very (IMO) ugly way: >>>>>>> | > | | >> >>>>>>> | > | | >> https://gist.github.com/matzew/6ab432e437b9a017a21d >>>>>>> | > | | >> >>>>>>> | > | | >> >>>>>>> | > | | >> >>>>>>> | > | | >> >>>>>>> | > | | >> IMO, we should be able to support this pattern but for now I'm not >>>>>>> | > | | >> really >>>>>>> | > | | >> sure how to specify this in our API, so if you have any ideas >>>>>>> | > feedback >>>>>>> | > | | >> this thread has been made for you ! >>>>>>> | > | | >> >>>>>>> | > | | >> >>>>>>> | > | | >> >>>>>>> | > | | >> Suggestion: Enhance the read function - example: >>>>>>> | > | | >> >>>>>>> | > | | >> https://gist.github.com/matzew/04f069dfbed2cc77a8b4 >>>>>>> | > | | > I'm thinking of the inverse myself. Add a "ParentPath" property >>>>>>> | > which can >>>>>>> | > | | > be used to extract information from parent objects. >>>>>>> | > | | > >>>>>>> | > | | > https://gist.github.com/secondsun/17ce96082eda37dbd10e >>>>>>> | > | | > >>>>>>> | > | | >> >>>>>>> | > | | >> >>>>>>> | > | | >> -Matthias >>>>>>> | > | | >> >>>>>>> | > | | >> >>>>>>> | > | | >> [1] >>>>>>> | > | | >> >>>>>>> | > http://www.infoq.com/resource/articles/rest-introduction/en/resources/fig... >>>>>>> | > | | >> [2] http://www.infoq.com/articles/rest-introduction >>>>>>> | > | | >> >>>>>>> | > | | >> >>>>>>> | > | | >> >>>>>>> | > | | >> >>>>>>> | > | | >> Seb >>>>>>> | > | | >> >>>>>>> | > | | >> >>>>>>> | > | | >> _______________________________________________ >>>>>>> | > | | >> aerogear-dev mailing list >>>>>>> | > | | >> aerogear-dev(a)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 >>>>>>> | > | | >> >>>>>>> | > | | >> _______________________________________________ >>>>>>> | > | | >> aerogear-dev mailing list >>>>>>> | > | | >> >>>>>>> | > | | >> aerogear-dev(a)lists.jboss.org >>>>>>> | > | | >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> | > | | > >>>>>>> | > | | > _______________________________________________ >>>>>>> | > | | > aerogear-dev mailing list >>>>>>> | > | | > aerogear-dev(a)lists.jboss.org >>>>>>> | > | | > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> | > | | >>>>>>> | > | | -- qmx >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | _______________________________________________ >>>>>>> | > | | aerogear-dev mailing list >>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | _______________________________________________ >>>>>>> | > | | aerogear-dev mailing list aerogear-dev(a)lists.jboss.org >>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | _______________________________________________ >>>>>>> | > | | aerogear-dev mailing list >>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> | > | | >>>>>>> | > | | _______________________________________________ >>>>>>> | > | | aerogear-dev mailing list >>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | _______________________________________________ >>>>>>> | > | | aerogear-dev mailing list >>>>>>> | > | | aerogear-dev(a)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 >>>>>>> | > | | _______________________________________________ >>>>>>> | > | | aerogear-dev mailing list >>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | _______________________________________________ >>>>>>> | > | | aerogear-dev mailing list >>>>>>> | > | | aerogear-dev(a)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 >>>>>>> | > | | _______________________________________________ >>>>>>> | > | | aerogear-dev mailing list >>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> | > | | >>>>>>> | > | | >>>>>>> | > | | _______________________________________________ >>>>>>> | > | | aerogear-dev mailing list >>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> | > | >>>>>>> | > | _______________________________________________ >>>>>>> | > | aerogear-dev mailing list >>>>>>> | > | aerogear-dev(a)lists.jboss.org >>>>>>> | > | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | _______________________________________________ >>>>>>> | > | aerogear-dev mailing list >>>>>>> | > | aerogear-dev(a)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 >>>>>>> | > | >>>>>>> | > | _______________________________________________ >>>>>>> | > | aerogear-dev mailing list >>>>>>> | > | aerogear-dev(a)lists.jboss.org >>>>>>> | > | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | _______________________________________________ >>>>>>> | > | aerogear-dev mailing list >>>>>>> | > | aerogear-dev(a)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 >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | -- >>>>>>> | > | Matthias Wessendorf >>>>>>> | > | >>>>>>> | > | blog: http://matthiaswessendorf.wordpress.com/ >>>>>>> | > | sessions: http://www.slideshare.net/mwessendorf >>>>>>> | > | twitter: http://twitter.com/mwessendorf >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | >>>>>>> | > | -- >>>>>>> | > | Matthias Wessendorf >>>>>>> | > | >>>>>>> | > | blog: http://matthiaswessendorf.wordpress.com/ >>>>>>> | > | sessions: http://www.slideshare.net/mwessendorf >>>>>>> | > | twitter: http://twitter.com/mwessendorf >>>>>>> | > | >>>>>>> | > | _______________________________________________ >>>>>>> | > | aerogear-dev mailing list >>>>>>> | > | aerogear-dev(a)lists.jboss.org >>>>>>> | > | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> | > >>>>>>> | > _______________________________________________ >>>>>>> | > aerogear-dev mailing list >>>>>>> | > aerogear-dev(a)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 >>>>>>> | >>>>>>> | _______________________________________________ >>>>>>> | aerogear-dev mailing list >>>>>>> | aerogear-dev(a)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 >>>>>>> | >>>>>>> | _______________________________________________ >>>>>>> | aerogear-dev mailing list >>>>>>> | aerogear-dev(a)lists.jboss.org >>>>>>> | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev(a)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 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

So we all agreed on "resourcePath" ? On Thu, Apr 18, 2013 at 4:54 PM, Christos Vasilakis <cvasilak(a)gmail.com&gt; wrote: Hi, have created the epic to track this, feel free to edit https://issues.jboss.org/browse/AEROGEAR-1123 - Christos On Apr 16, 2013, at 4:23 PM, Daniel Bevenius <daniel.bevenius(a)gmail.com&gt; wrote: > doh! Sorry. I was just looking at the first examples in the gist and did not realize these could have multiple segments. > > > On 16 April 2013 15:18, Kris Borchers <kris(a)redhat.com&gt; wrote: > Hmm, I like the idea of looking to standards but if I'm reading it right, segment there means just a portion of the URI between slashes, not multiple slash-separated segments. > > On Apr 16, 2013, at 8:14 AM, Daniel Bevenius <daniel.bevenius(a)gmail.com&gt; wrote: > >> I agree, when I read resourcePath I read that as a path to resource. How about pathSegment or segment as used by http://tools.ietf.org/html/rfc3986#section-3.3 ? >> >> >> On 16 April 2013 15:12, Kris Borchers <kris(a)redhat.com&gt; wrote: >> My only issue with resourcePath is that it doesn't imply that the path is relative to the current pipe. I mean, it should be implied since you're already working with a pipe and we can be explicit about that in documentation but I still wish it was somehow in the name. I think that was the goal of using "nested" in the name but I already expressed my issue with that. Any other thoughts would be appreciated but I could be happy with resourcePath. >> >> On Apr 16, 2013, at 7:55 AM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: >> >>> +1 to resourcePath . it beats my thought of "superawesomenestedresourcethingy" >>> On Apr 16, 2013, at 8:39 AM, Christos Vasilakis <cvasilak(a)gmail.com&gt; wrote: >>> >>>> +1 >>>> >>>> I think it describes the feature better. >>>> >>>> >>>> On Apr 16, 2013, at 3:09 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >>>> >>>>> +1 on the "resourcePath", you nailed it ! >>>>> >>>>> >>>>> >>>>> On Tue, Apr 16, 2013 at 2:03 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >>>>> Hmmm, "nestedResource" isn't terrible but not crazy about "nested" since they're not necessarily nested but just related. Hmmmmm. >>>>> >>>>> It's not that I hate resource, I think it kind of makes sense if you know what we're talking about. How about something like "resourcePath" to be a little more explicit in what it is? Still not crazy about that but feel like it's better/closer to something that describes what it is. >>>>> >>>>> On Apr 16, 2013, at 6:44 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >>>>> >>>>>> Well, there seems to be an agreement on option #1 , except for the name "resource" , so let's find a name that we all agree on and so we can going further with this feature. >>>>>> My propositions: "nestedResource" , "fragment", "nestedURI" ... But I'm not really fan of all of my propositions ... >>>>>> Seb >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Apr 11, 2013 at 4:07 PM, Summers Pittman <supittma(a)redhat.com&gt; wrote: >>>>>> With #1 is `resource` a URI? If so, will developers have to build the URI by hand? >>>>>> >>>>>> >>>>>> On 04/10/2013 10:48 AM, Christos Vasilakis wrote: >>>>>>> Hi >>>>>>> >>>>>>> I've prepared a document[1] that collectively describes the different approaches discussed in this thread for supporting the nested resources. It is split in two sections, ones that don't require modification to the existing API and ones that do >>>>>>> >>>>>>> Please have a look and let me know if I miss sth or interpret one approach wrong. >>>>>>> >>>>>>> Thanks >>>>>>> Christos >>>>>>> >>>>>>> [1] https://gist.github.com/cvasilak/4a5f51b8d1ad9cc7f21b >>>>>>> >>>>>>> On Apr 9, 2013, at 10:19 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >>>>>>> >>>>>>>> Hey, >>>>>>>> Like paging, could we start 2 gists : one with a side to side techno samples and another one with high level Specs ? I start a bit to get lost in this thread :) >>>>>>>> Just one remark when reading the last messages, one "must have" is to be able to retrieve all the comments for a post without EVER retrieving the post record, so >>>>>>>> /posts/1/comments will retrieve all the comments for post 1 but will actually never call posts/1 : in this covered in your last examples ? (spec could be : "by-pass parent GET resource" >>>>>>>> Seb >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Apr 9, 2013 at 9:03 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Apr 8, 2013 at 7:57 PM, Summers Pittman <supittma(a)redhat.com&gt; wrote: >>>>>>>> >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>> | From: "Matthias Wessendorf" <matzew(a)apache.org&gt; >>>>>>>> | To: "AeroGear Developer Mailing List" <aerogear-dev(a)lists.jboss.org&gt; >>>>>>>> | Sent: Monday, April 8, 2013 1:22:19 PM >>>>>>>> | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for nested endpoints >>>>>>>> | >>>>>>>> | OK, with the following server API: >>>>>>>> | >>>>>>>> | http://some.server.com/posts/1 >>>>>>>> | http://some.server.com/posts/1/comments >>>>>>>> | (and NO 'comments' collection on the ' http://some.server.com/posts/1 ' >>>>>>>> | response) >>>>>>>> | >>>>>>>> | Does this (today) 'myPipe.read(1)' already read the specific comments ( >>>>>>>> | http://some.server.com/posts/1/comments ) ?? >>>>>>>> | >>>>>>>> | ======= JAVA API ======= >>>>>>>> | Class Post: >>>>>>>> | - string: id; >>>>>>>> | - string: title; >>>>>>>> | - string: postContent; >>>>>>>> | - List<Comment> comments; >>>>>>>> | Class Comment: >>>>>>>> | - string username; >>>>>>>> | - string comment; >>>>>>>> | >>>>>>>> | Or would the IMPL expect an 'embedded' _comments_ collection on the response >>>>>>>> | of "GET http://some.server.com/posts/1 " ? >>>>>>>> >>>>>>>> It will not read /posts/1/comments if the Pipe's endpoint is /posts. If you have a comments collection on the post but no comments data in the response then the value for getComments will just be null. >>>>>>>> >>>>>>>> Ok - so this needs to be tweaked in Java too, since it's very common to model the REST endpoints like above; >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> | >>>>>>>> | >>>>>>>> | >>>>>>>> | On Mon, Apr 8, 2013 at 7:05 PM, Summers Pittman < supittma(a)redhat.com > >>>>>>>> | wrote: >>>>>>>> | >>>>>>>> | >>>>>>>> | No. The get of pipe 1 would have to include the comments for get comments to >>>>>>>> | work >>>>>>>> | >>>>>>>> | Sent from my Android phone using TouchDown ( www.nitrodesk.com ) >>>>>>>> | >>>>>>>> | >>>>>>>> | -----Original Message----- >>>>>>>> | From: Matthias Wessendorf [ matzew(a)apache.org ] >>>>>>>> | Received: Monday, 08 Apr 2013, 12:04PM >>>>>>>> | To: AeroGear Developer Mailing List [ aerogear-dev(a)lists.jboss.org ] >>>>>>>> | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for nested endpoints >>>>>>>> | >>>>>>>> | >>>>>>>> | On Mon, Apr 8, 2013 at 5:57 PM, Summers Pittman < supittma(a)redhat.com > >>>>>>>> | wrote: >>>>>>>> | >>>>>>>> | > >>>>>>>> | > >>>>>>>> | > ----- Original Message ----- >>>>>>>> | > | From: "Matthias Wessendorf" < matzew(a)apache.org > >>>>>>>> | > | To: "AeroGear Developer Mailing List" < aerogear-dev(a)lists.jboss.org > >>>>>>>> | > | Sent: Monday, April 8, 2013 10:28:46 AM >>>>>>>> | > | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for nested >>>>>>>> | > endpoints >>>>>>>> | > | >>>>>>>> | > | or, like before said - reading "lists" (e.g. all the comments for >>>>>>>> | > specific >>>>>>>> | > | blog post): >>>>>>>> | > | https://gist.github.com/matzew/04f069dfbed2cc77a8b4 >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | For Java.... I guess...... resolving this URL: >>>>>>>> | > | http://some.server.com/posts/1/comments >>>>>>>> | > | >>>>>>>> | > | could be done with this - right ? >>>>>>>> | > | >>>>>>>> | > | ======= >>>>>>>> | > | Class Post: >>>>>>>> | > | - string: title; >>>>>>>> | > | - string: postContent; >>>>>>>> | > | - List<Comment> comments; >>>>>>>> | > | Class Comment: >>>>>>>> | > | - string username; >>>>>>>> | > | - string comment; >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | // get all the comments for 1: >>>>>>>> | > | Post myPostOne = postPipe.read("1"); >>>>>>>> | > | myPostOne.getComments(); >>>>>>>> | > | >>>>>>>> | > | // get all the comments for 2: >>>>>>>> | > | Post myPostTwo = postPipe.read("2"); >>>>>>>> | > | myPostTwo.getComments(); >>>>>>>> | > | ======= >>>>>>>> | > >>>>>>>> | > It can be done with that yes. My concern was more when we had a Pipe of >>>>>>>> | > type <Post> and a readForResource(String property) method. >>>>>>>> | >>>>>>>> | >>>>>>>> | Ok - one more question >>>>>>>> | >>>>>>>> | >>>>>>>> | So... when doing: myPipe.read(1); does that "only" issue a GET against the ' >>>>>>>> | http://some.server.com/posts/1 ' resource? >>>>>>>> | >>>>>>>> | A second get, for the comments collection is than issued when calling >>>>>>>> | myPostOne.getComments();? >>>>>>>> | (GET against ' http://some.server.com/posts/1/comments' )? >>>>>>>> | >>>>>>>> | >>>>>>>> | >>>>>>>> | >>>>>>>> | > The type information of the property isn't available unless we can infer >>>>>>>> | > it from the Post object. >>>>>>>> | > >>>>>>>> | >>>>>>>> | >>>>>>>> | >>>>>>>> | >>>>>>>> | >>>>>>>> | > >>>>>>>> | > >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | Greetings, >>>>>>>> | > | Matthias >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | On Fri, Apr 5, 2013 at 2:37 PM, Matthias Wessendorf < matzew(a)apache.org > >>>>>>>> | > | wrote: >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | Thought a bit more about it and chatted with friends, >>>>>>>> | > | >>>>>>>> | > | the issue with the sub pipes is: it adds state and is perhaps an API >>>>>>>> | > | construct that is a bit hard to understand (see all the discussions here) >>>>>>>> | > | >>>>>>>> | > | Not sure - but currently we can access "kid resources", with our API - >>>>>>>> | > right >>>>>>>> | > | ? >>>>>>>> | > | >>>>>>>> | > | https://gist.github.com/matzew/6ab432e437b9a017a21d >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | Perhaps it's better to just keep it that way? This has the benefit of >>>>>>>> | > using >>>>>>>> | > | an established and know API, the different pipes are accessible via the >>>>>>>> | > | pipeline object; >>>>>>>> | > | >>>>>>>> | > | And the code is not too much code; it's simply an explicit pipe ... >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | On Fri, Apr 5, 2013 at 10:56 AM, Matthias Wessendorf < matzew(a)apache.org >>>>>>>> | > | > >>>>>>>> | > | wrote: >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | On Fri, Apr 5, 2013 at 10:52 AM, Sebastien Blanc < scm.blanc(a)gmail.com > >>>>>>>> | > | wrote: >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | On Fri, Apr 5, 2013 at 10:36 AM, Matthias Wessendorf < matzew(a)apache.org >>>>>>>> | > | > >>>>>>>> | > | wrote: >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | On Fri, Apr 5, 2013 at 10:14 AM, Christos Vasilakis < cvasilak(a)gmail.com >>>>>>>> | > | > >>>>>>>> | > | wrote: >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | Hi >>>>>>>> | > | >>>>>>>> | > | some comments >>>>>>>> | > | >>>>>>>> | > | I believe the method can't be used since you don't know the team for the >>>>>>>> | > | players so you can't retrieve the pipe directly..right? >>>>>>>> | > | >>>>>>>> | > | Isn't that really up to the impl of the rest service? >>>>>>>> | > | They could return a list of teamsHePlayed for; >>>>>>>> | > | >>>>>>>> | > | So, let's not tie this API to a specific, not existing RESTful service; >>>>>>>> | > | >>>>>>>> | > | +1, we don't need to care about that, we must just focus on how we can >>>>>>>> | > | declare and call nested pipes. >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | yep >>>>>>>> | > | >>>>>>>> | > | I guess this is perhaps the closest we can come to : >>>>>>>> | > | >>>>>>>> | > | id<AGPipe> allOwnersInNewYorkPipe = [leaguesPipe subPipe:@"owners" >>>>>>>> | > | for:@"newyork"]; >>>>>>>> | > | >>>>>>>> | > | and than.... on the 'leaguesPipe' you can access its kids with something >>>>>>>> | > like >>>>>>>> | > | : >>>>>>>> | > | >>>>>>>> | > | NSArray* kids = [leaguesPipe subPipes]; >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | However, that adds some state to a specific pipe object >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | -M >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | getPlayers ( Callback < List < Player >> callback ) { >>>>>>>> | > | pipe . get ( "player" ). read ( callback ); >>>>>>>> | > | } >>>>>>>> | > | >>>>>>>> | > | Further my questions is, how is a third (or arbitrary) nested resources >>>>>>>> | > are >>>>>>>> | > | supported? I mean for a url schema like this >>>>>>>> | > | >>>>>>>> | > | soccer.org/leagues/ {id}/teams/{id}/players/{id} >>>>>>>> | > | >>>>>>>> | > | first we access the leagues: >>>>>>>> | > | --- >>>>>>>> | > | getLeagues(Callback<List<Leagues>> callback) { >>>>>>>> | > | pipe.get("leagues").read(callback); >>>>>>>> | > | } >>>>>>>> | > | --- >>>>>>>> | > | then the teams for this league: >>>>>>>> | > | --- >>>>>>>> | > | getTeamsOnLeaque(Leaque league, Callback<List<Team>> callback) { >>>>>>>> | > | pipe.junction("league","team").read(leaque, callback); >>>>>>>> | > | } >>>>>>>> | > | --- >>>>>>>> | > | ..and then we access the "Players" for a "Team": >>>>>>>> | > | --- >>>>>>>> | > | getPlayersOnTeam(Team team, Callback<List<Player>> callback) { >>>>>>>> | > | pipe.junction("team","player").read(team, callback); >>>>>>>> | > | } >>>>>>>> | > | --- >>>>>>>> | > | But where is the "League" information to fill the "/leagues/{id}..." >>>>>>>> | > path? >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | I'd assume the information is 'inherited' out of a given pipe, when >>>>>>>> | > doing the >>>>>>>> | > | 'join' >>>>>>>> | > | >>>>>>>> | > | e.g. like >>>>>>>> | > | myTeamsForLeaguePipe = leaguePipe.junction("team"); >>>>>>>> | > | >>>>>>>> | > | not sure... >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | Unless you mean something like: >>>>>>>> | > | --- >>>>>>>> | > | getPlayersOnTeam(Leaque league, Team team, Callback<List<Player>> >>>>>>>> | > callback) { >>>>>>>> | > | pipe.junction("league", "team","player").read(league, team, callback); >>>>>>>> | > | } >>>>>>>> | > | >>>>>>>> | > | I am not sure if that is really easy to understand/use >>>>>>>> | > | >>>>>>>> | > | Yes and the term "junction" is a bit confusing as it don't express >>>>>>>> | > explicitly >>>>>>>> | > | a parent/child relation. >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | --- >>>>>>>> | > | >>>>>>>> | > | probably I am missing sth.. >>>>>>>> | > | >>>>>>>> | > | Thanks, >>>>>>>> | > | Christos >>>>>>>> | > | >>>>>>>> | > | On Apr 4, 2013, at 5:52 PM, Summers Pittman < supittma(a)redhat.com > >>>>>>>> | > wrote: >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | What if we create a new metaphor, a Junction. >>>>>>>> | > | >>>>>>>> | > | https://gist.github.com/secondsun/dcf5682b6ff17c729d9a >>>>>>>> | > | >>>>>>>> | > | It joins two pipes together and can be used over and over again with >>>>>>>> | > | different data? >>>>>>>> | > | It isn't a Pipe though, but perhaps that could be changed to look more >>>>>>>> | > like >>>>>>>> | > | Christos's previous example. >>>>>>>> | > | >>>>>>>> | > | At the very least I like the words "junction" or "join" more than "of" >>>>>>>> | > | >>>>>>>> | > | ----- Original Message ----- >>>>>>>> | > | | From: "Christos Vasilakis" < cvasilak(a)gmail.com > >>>>>>>> | > | | To: "AeroGear Developer Mailing List" < aerogear-dev(a)lists.jboss.org > >>>>>>>> | > | | Sent: Wednesday, April 3, 2013 3:03:02 AM >>>>>>>> | > | | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for nested >>>>>>>> | > | | endpoints >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | On Apr 2, 2013, at 4:03 PM, Matthias Wessendorf < matzew(a)apache.org > >>>>>>>> | > | | wrote: >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | Two thoughts.... >>>>>>>> | > | | >>>>>>>> | > | | 1) the 'original' leaguesPipe has no clue about the subpipes, right ? >>>>>>>> | > | | 2) should a pipe offer a 'getter' for all it's sub pipes ? >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | Just a thought is instead of using Pipe, to continue using Pipeline >>>>>>>> | > adding >>>>>>>> | > | | an >>>>>>>> | > | | extra parameter " of" for specifying the parent : E.g.: >>>>>>>> | > | | >>>>>>>> | > | | ….. >>>>>>>> | > | | id<AGPipe> leaguesPipe = [pipeline pipe@"leagues"]; >>>>>>>> | > | | >>>>>>>> | > | | id<AGPipe> allTeamsInSeattlePipe = [pipeline subPipe@"teams" of >>>>>>>> | > | | :leaguesPipe >>>>>>>> | > | | for:@"seattle"] >>>>>>>> | > | | >>>>>>>> | > | | id<AGPipe> allPlayersInTrebuchetPipe = [pipeline subPipe:@"players" >>>>>>>> | > of: >>>>>>>> | > | | allTeamsInSeattlePipe for:@"trebuchet"]; >>>>>>>> | > | | ….. >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | Wdyt? >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | -M >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | Thanks, >>>>>>>> | > | | Christos >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | soccer.org/leagues/seattle/teams/trebuchet/players/foo - > >>>>>>>> | > | | [[pipeline pipe:@"players" pathParams:@[@"seattle", @"trebuchet"]] >>>>>>>> | > read >>>>>>>> | > | | :@"foo"] .. >>>>>>>> | > | | ----- >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | Wdyt? >>>>>>>> | > | | >>>>>>>> | > | | Thanks >>>>>>>> | > | | Christos >>>>>>>> | > | | >>>>>>>> | > | | On Mar 18, 2013, at 1:12 PM, Sebastien Blanc < scm.blanc(a)gmail.com > >>>>>>>> | > wrote: >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | Well, that would not be possible, for that you will have to create a >>>>>>>> | > | | "child" >>>>>>>> | > | | pipe. But I agree, that is maybe no optimal ... >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | On Fri, Mar 15, 2013 at 6:44 PM, Summers Pittman < supittma(a)redhat.com >>>>>>>> | > | | > >>>>>>>> | > | | wrote: >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | On 03/15/2013 01:34 PM, Sebastien Blanc wrote: >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | I like the idea but I will more see that has a method/function for the >>>>>>>> | > | | pipelineManager (and will be easier to implement in JS, I think) : >>>>>>>> | > | | >>>>>>>> | > | | var myParentPipe = >>>>>>>> | > Aerogear.Pipeline({name:"parentPipe"}).pipes.parentPipe >>>>>>>> | > | | >>>>>>>> | > | | var myChildPipe = Aerogear.Pipeline.fromParent(myParentPipe, {options} >>>>>>>> | > ) >>>>>>>> | > | | What would it look like to get a child record from a parent? >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | On Fri, Mar 15, 2013 at 5:37 PM, Douglas Campos < qmx(a)qmx.me > wrote: >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | What about this? >>>>>>>> | > | | >>>>>>>> | > | | Pipeline<Post> postPipeline = … >>>>>>>> | > | | Post post = // get from the pipeline >>>>>>>> | > | | Pipeline<Comment> >>>>>>>> | > | | postPipeline.childPipelineForOrOtherWeirdName(Comment.class, post) >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | On 15/03/2013, at 12:26, Summers Pittman < supittma(a)redhat.com > >>>>>>>> | > wrote: >>>>>>>> | > | | >>>>>>>> | > | | > On 03/14/2013 04:48 AM, Matthias Wessendorf wrote: >>>>>>>> | > | | >> >>>>>>>> | > | | >> >>>>>>>> | > | | >> On Thu, Mar 14, 2013 at 9:32 AM, Sebastien Blanc < >>>>>>>> | > scm.blanc(a)gmail.com > >>>>>>>> | > | | >> wrote: >>>>>>>> | > | | >> Hi, >>>>>>>> | > | | >> While I was playing with scaffolding and tried to build a simple >>>>>>>> | > Blog >>>>>>>> | > | | >> Application with Aerogear I faced the current situation : >>>>>>>> | > | | >> I have a Post object which contains many Comment objects. Now I >>>>>>>> | > want to >>>>>>>> | > | | >> call my Post pipe to retrieve the related comments, I have >>>>>>>> | > currently 2 >>>>>>>> | > | | >> options : >>>>>>>> | > | | >> >>>>>>>> | > | | >> /posts/1 -> assuming comments will be implicitly retrieved (eager >>>>>>>> | > | | >> loading) >>>>>>>> | > | | >> /comments/?postid=1 >>>>>>>> | > | | >> >>>>>>>> | > | | >> But regarding our model the correct form should be : >>>>>>>> | > | | >> >>>>>>>> | > | | >> /posts/1/comments >>>>>>>> | > | | >> >>>>>>>> | > | | >> >>>>>>>> | > | | >> +1 >>>>>>>> | > | | >> that is the ideal way to model URIs for "nested" resources. >>>>>>>> | > | | >> >>>>>>>> | > | | >> See [1], extracted from [2] >>>>>>>> | > | | >> >>>>>>>> | > | | >> >>>>>>>> | > | | >> >>>>>>>> | > | | >> But, AFAIK, with the current API, it is not possible to define this >>>>>>>> | > last >>>>>>>> | > | | >> pattern (at least for JS and iOs, confirmed by Matzew). When doing a >>>>>>>> | > | | >> read >>>>>>>> | > | | >> we can pass an id option but as mentioned in the doc, this id will >>>>>>>> | > | | >> always >>>>>>>> | > | | >> be append to the endpoint. >>>>>>>> | > | | >> >>>>>>>> | > | | >> >>>>>>>> | > | | >> Well, it is possible - but in a very (IMO) ugly way: >>>>>>>> | > | | >> >>>>>>>> | > | | >> https://gist.github.com/matzew/6ab432e437b9a017a21d >>>>>>>> | > | | >> >>>>>>>> | > | | >> >>>>>>>> | > | | >> >>>>>>>> | > | | >> >>>>>>>> | > | | >> IMO, we should be able to support this pattern but for now I'm not >>>>>>>> | > | | >> really >>>>>>>> | > | | >> sure how to specify this in our API, so if you have any ideas >>>>>>>> | > feedback >>>>>>>> | > | | >> this thread has been made for you ! >>>>>>>> | > | | >> >>>>>>>> | > | | >> >>>>>>>> | > | | >> >>>>>>>> | > | | >> Suggestion: Enhance the read function - example: >>>>>>>> | > | | >> >>>>>>>> | > | | >> https://gist.github.com/matzew/04f069dfbed2cc77a8b4 >>>>>>>> | > | | > I'm thinking of the inverse myself. Add a "ParentPath" property >>>>>>>> | > which can >>>>>>>> | > | | > be used to extract information from parent objects. >>>>>>>> | > | | > >>>>>>>> | > | | > https://gist.github.com/secondsun/17ce96082eda37dbd10e >>>>>>>> | > | | > >>>>>>>> | > | | >> >>>>>>>> | > | | >> >>>>>>>> | > | | >> -Matthias >>>>>>>> | > | | >> >>>>>>>> | > | | >> >>>>>>>> | > | | >> [1] >>>>>>>> | > | | >> >>>>>>>> | > http://www.infoq.com/resource/articles/rest-introduction/en/resources/fig... >>>>>>>> | > | | >> [2] http://www.infoq.com/articles/rest-introduction >>>>>>>> | > | | >> >>>>>>>> | > | | >> >>>>>>>> | > | | >> >>>>>>>> | > | | >> >>>>>>>> | > | | >> Seb >>>>>>>> | > | | >> >>>>>>>> | > | | >> >>>>>>>> | > | | >> _______________________________________________ >>>>>>>> | > | | >> aerogear-dev mailing list >>>>>>>> | > | | >> aerogear-dev(a)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 >>>>>>>> | > | | >> >>>>>>>> | > | | >> _______________________________________________ >>>>>>>> | > | | >> aerogear-dev mailing list >>>>>>>> | > | | >> >>>>>>>> | > | | >> aerogear-dev(a)lists.jboss.org >>>>>>>> | > | | >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> | > | | > >>>>>>>> | > | | > _______________________________________________ >>>>>>>> | > | | > aerogear-dev mailing list >>>>>>>> | > | | > aerogear-dev(a)lists.jboss.org >>>>>>>> | > | | > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> | > | | >>>>>>>> | > | | -- qmx >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | _______________________________________________ >>>>>>>> | > | | aerogear-dev mailing list >>>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | _______________________________________________ >>>>>>>> | > | | aerogear-dev mailing list aerogear-dev(a)lists.jboss.org >>>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | _______________________________________________ >>>>>>>> | > | | aerogear-dev mailing list >>>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> | > | | >>>>>>>> | > | | _______________________________________________ >>>>>>>> | > | | aerogear-dev mailing list >>>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | _______________________________________________ >>>>>>>> | > | | aerogear-dev mailing list >>>>>>>> | > | | aerogear-dev(a)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 >>>>>>>> | > | | _______________________________________________ >>>>>>>> | > | | aerogear-dev mailing list >>>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | _______________________________________________ >>>>>>>> | > | | aerogear-dev mailing list >>>>>>>> | > | | aerogear-dev(a)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 >>>>>>>> | > | | _______________________________________________ >>>>>>>> | > | | aerogear-dev mailing list >>>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | _______________________________________________ >>>>>>>> | > | | aerogear-dev mailing list >>>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> | > | >>>>>>>> | > | _______________________________________________ >>>>>>>> | > | aerogear-dev mailing list >>>>>>>> | > | aerogear-dev(a)lists.jboss.org >>>>>>>> | > | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | _______________________________________________ >>>>>>>> | > | aerogear-dev mailing list >>>>>>>> | > | aerogear-dev(a)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 >>>>>>>> | > | >>>>>>>> | > | _______________________________________________ >>>>>>>> | > | aerogear-dev mailing list >>>>>>>> | > | aerogear-dev(a)lists.jboss.org >>>>>>>> | > | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | _______________________________________________ >>>>>>>> | > | aerogear-dev mailing list >>>>>>>> | > | aerogear-dev(a)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 >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | -- >>>>>>>> | > | Matthias Wessendorf >>>>>>>> | > | >>>>>>>> | > | blog: http://matthiaswessendorf.wordpress.com/ >>>>>>>> | > | sessions: http://www.slideshare.net/mwessendorf >>>>>>>> | > | twitter: http://twitter.com/mwessendorf >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | -- >>>>>>>> | > | Matthias Wessendorf >>>>>>>> | > | >>>>>>>> | > | blog: http://matthiaswessendorf.wordpress.com/ >>>>>>>> | > | sessions: http://www.slideshare.net/mwessendorf >>>>>>>> | > | twitter: http://twitter.com/mwessendorf >>>>>>>> | > | >>>>>>>> | > | _______________________________________________ >>>>>>>> | > | aerogear-dev mailing list >>>>>>>> | > | aerogear-dev(a)lists.jboss.org >>>>>>>> | > | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> | > >>>>>>>> | > _______________________________________________ >>>>>>>> | > aerogear-dev mailing list >>>>>>>> | > aerogear-dev(a)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 >>>>>>>> | >>>>>>>> | _______________________________________________ >>>>>>>> | aerogear-dev mailing list >>>>>>>> | aerogear-dev(a)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 >>>>>>>> | >>>>>>>> | _______________________________________________ >>>>>>>> | aerogear-dev mailing list >>>>>>>> | aerogear-dev(a)lists.jboss.org >>>>>>>> | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing list >>>>>>>> aerogear-dev(a)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 >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing list >>>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing list >>>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Yeah, I'm all for 'resourcePath' now that I'm not as confused anymore :) On 18 April 2013 17:37, Christos Vasilakis <cvasilak(a)gmail.com&gt; wrote: I think If no alternative comes along, let's stick to 'resourcePath' for now.. On Apr 18, 2013, at 6:23 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > So we all agreed on "resourcePath" ? > > > > On Thu, Apr 18, 2013 at 4:54 PM, Christos Vasilakis <cvasilak(a)gmail.com&gt; wrote: > Hi, > > have created the epic to track this, feel free to edit > > https://issues.jboss.org/browse/AEROGEAR-1123 > > - > Christos > > On Apr 16, 2013, at 4:23 PM, Daniel Bevenius <daniel.bevenius(a)gmail.com&gt; wrote: > >> doh! Sorry. I was just looking at the first examples in the gist and did not realize these could have multiple segments. >> >> >> On 16 April 2013 15:18, Kris Borchers <kris(a)redhat.com&gt; wrote: >> Hmm, I like the idea of looking to standards but if I'm reading it right, segment there means just a portion of the URI between slashes, not multiple slash-separated segments. >> >> On Apr 16, 2013, at 8:14 AM, Daniel Bevenius <daniel.bevenius(a)gmail.com&gt; wrote: >> >>> I agree, when I read resourcePath I read that as a path to resource. How about pathSegment or segment as used by http://tools.ietf.org/html/rfc3986#section-3.3 ? >>> >>> >>> On 16 April 2013 15:12, Kris Borchers <kris(a)redhat.com&gt; wrote: >>> My only issue with resourcePath is that it doesn't imply that the path is relative to the current pipe. I mean, it should be implied since you're already working with a pipe and we can be explicit about that in documentation but I still wish it was somehow in the name. I think that was the goal of using "nested" in the name but I already expressed my issue with that. Any other thoughts would be appreciated but I could be happy with resourcePath. >>> >>> On Apr 16, 2013, at 7:55 AM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: >>> >>>> +1 to resourcePath . it beats my thought of "superawesomenestedresourcethingy" >>>> On Apr 16, 2013, at 8:39 AM, Christos Vasilakis <cvasilak(a)gmail.com&gt; wrote: >>>> >>>>> +1 >>>>> >>>>> I think it describes the feature better. >>>>> >>>>> >>>>> On Apr 16, 2013, at 3:09 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >>>>> >>>>>> +1 on the "resourcePath", you nailed it ! >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Apr 16, 2013 at 2:03 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >>>>>> Hmmm, "nestedResource" isn't terrible but not crazy about "nested" since they're not necessarily nested but just related. Hmmmmm. >>>>>> >>>>>> It's not that I hate resource, I think it kind of makes sense if you know what we're talking about. How about something like "resourcePath" to be a little more explicit in what it is? Still not crazy about that but feel like it's better/closer to something that describes what it is. >>>>>> >>>>>> On Apr 16, 2013, at 6:44 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >>>>>> >>>>>>> Well, there seems to be an agreement on option #1 , except for the name "resource" , so let's find a name that we all agree on and so we can going further with this feature. >>>>>>> My propositions: "nestedResource" , "fragment", "nestedURI" ... But I'm not really fan of all of my propositions ... >>>>>>> Seb >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Apr 11, 2013 at 4:07 PM, Summers Pittman <supittma(a)redhat.com&gt; wrote: >>>>>>> With #1 is `resource` a URI? If so, will developers have to build the URI by hand? >>>>>>> >>>>>>> >>>>>>> On 04/10/2013 10:48 AM, Christos Vasilakis wrote: >>>>>>>> Hi >>>>>>>> >>>>>>>> I've prepared a document[1] that collectively describes the different approaches discussed in this thread for supporting the nested resources. It is split in two sections, ones that don't require modification to the existing API and ones that do >>>>>>>> >>>>>>>> Please have a look and let me know if I miss sth or interpret one approach wrong. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Christos >>>>>>>> >>>>>>>> [1] https://gist.github.com/cvasilak/4a5f51b8d1ad9cc7f21b >>>>>>>> >>>>>>>> On Apr 9, 2013, at 10:19 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >>>>>>>> >>>>>>>>> Hey, >>>>>>>>> Like paging, could we start 2 gists : one with a side to side techno samples and another one with high level Specs ? I start a bit to get lost in this thread :) >>>>>>>>> Just one remark when reading the last messages, one "must have" is to be able to retrieve all the comments for a post without EVER retrieving the post record, so >>>>>>>>> /posts/1/comments will retrieve all the comments for post 1 but will actually never call posts/1 : in this covered in your last examples ? (spec could be : "by-pass parent GET resource" >>>>>>>>> Seb >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Apr 9, 2013 at 9:03 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Apr 8, 2013 at 7:57 PM, Summers Pittman <supittma(a)redhat.com&gt; wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> ----- Original Message ----- >>>>>>>>> | From: "Matthias Wessendorf" <matzew(a)apache.org&gt; >>>>>>>>> | To: "AeroGear Developer Mailing List" <aerogear-dev(a)lists.jboss.org&gt; >>>>>>>>> | Sent: Monday, April 8, 2013 1:22:19 PM >>>>>>>>> | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for nested endpoints >>>>>>>>> | >>>>>>>>> | OK, with the following server API: >>>>>>>>> | >>>>>>>>> | http://some.server.com/posts/1 >>>>>>>>> | http://some.server.com/posts/1/comments >>>>>>>>> | (and NO 'comments' collection on the ' http://some.server.com/posts/1 ' >>>>>>>>> | response) >>>>>>>>> | >>>>>>>>> | Does this (today) 'myPipe.read(1)' already read the specific comments ( >>>>>>>>> | http://some.server.com/posts/1/comments ) ?? >>>>>>>>> | >>>>>>>>> | ======= JAVA API ======= >>>>>>>>> | Class Post: >>>>>>>>> | - string: id; >>>>>>>>> | - string: title; >>>>>>>>> | - string: postContent; >>>>>>>>> | - List<Comment> comments; >>>>>>>>> | Class Comment: >>>>>>>>> | - string username; >>>>>>>>> | - string comment; >>>>>>>>> | >>>>>>>>> | Or would the IMPL expect an 'embedded' _comments_ collection on the response >>>>>>>>> | of "GET http://some.server.com/posts/1 " ? >>>>>>>>> >>>>>>>>> It will not read /posts/1/comments if the Pipe's endpoint is /posts. If you have a comments collection on the post but no comments data in the response then the value for getComments will just be null. >>>>>>>>> >>>>>>>>> Ok - so this needs to be tweaked in Java too, since it's very common to model the REST endpoints like above; >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> | >>>>>>>>> | >>>>>>>>> | >>>>>>>>> | On Mon, Apr 8, 2013 at 7:05 PM, Summers Pittman < supittma(a)redhat.com > >>>>>>>>> | wrote: >>>>>>>>> | >>>>>>>>> | >>>>>>>>> | No. The get of pipe 1 would have to include the comments for get comments to >>>>>>>>> | work >>>>>>>>> | >>>>>>>>> | Sent from my Android phone using TouchDown ( www.nitrodesk.com ) >>>>>>>>> | >>>>>>>>> | >>>>>>>>> | -----Original Message----- >>>>>>>>> | From: Matthias Wessendorf [ matzew(a)apache.org ] >>>>>>>>> | Received: Monday, 08 Apr 2013, 12:04PM >>>>>>>>> | To: AeroGear Developer Mailing List [ aerogear-dev(a)lists.jboss.org ] >>>>>>>>> | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for nested endpoints >>>>>>>>> | >>>>>>>>> | >>>>>>>>> | On Mon, Apr 8, 2013 at 5:57 PM, Summers Pittman < supittma(a)redhat.com > >>>>>>>>> | wrote: >>>>>>>>> | >>>>>>>>> | > >>>>>>>>> | > >>>>>>>>> | > ----- Original Message ----- >>>>>>>>> | > | From: "Matthias Wessendorf" < matzew(a)apache.org > >>>>>>>>> | > | To: "AeroGear Developer Mailing List" < aerogear-dev(a)lists.jboss.org > >>>>>>>>> | > | Sent: Monday, April 8, 2013 10:28:46 AM >>>>>>>>> | > | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for nested >>>>>>>>> | > endpoints >>>>>>>>> | > | >>>>>>>>> | > | or, like before said - reading "lists" (e.g. all the comments for >>>>>>>>> | > specific >>>>>>>>> | > | blog post): >>>>>>>>> | > | https://gist.github.com/matzew/04f069dfbed2cc77a8b4 >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | For Java.... I guess...... resolving this URL: >>>>>>>>> | > | http://some.server.com/posts/1/comments >>>>>>>>> | > | >>>>>>>>> | > | could be done with this - right ? >>>>>>>>> | > | >>>>>>>>> | > | ======= >>>>>>>>> | > | Class Post: >>>>>>>>> | > | - string: title; >>>>>>>>> | > | - string: postContent; >>>>>>>>> | > | - List<Comment> comments; >>>>>>>>> | > | Class Comment: >>>>>>>>> | > | - string username; >>>>>>>>> | > | - string comment; >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | // get all the comments for 1: >>>>>>>>> | > | Post myPostOne = postPipe.read("1"); >>>>>>>>> | > | myPostOne.getComments(); >>>>>>>>> | > | >>>>>>>>> | > | // get all the comments for 2: >>>>>>>>> | > | Post myPostTwo = postPipe.read("2"); >>>>>>>>> | > | myPostTwo.getComments(); >>>>>>>>> | > | ======= >>>>>>>>> | > >>>>>>>>> | > It can be done with that yes. My concern was more when we had a Pipe of >>>>>>>>> | > type <Post> and a readForResource(String property) method. >>>>>>>>> | >>>>>>>>> | >>>>>>>>> | Ok - one more question >>>>>>>>> | >>>>>>>>> | >>>>>>>>> | So... when doing: myPipe.read(1); does that "only" issue a GET against the ' >>>>>>>>> | http://some.server.com/posts/1 ' resource? >>>>>>>>> | >>>>>>>>> | A second get, for the comments collection is than issued when calling >>>>>>>>> | myPostOne.getComments();? >>>>>>>>> | (GET against ' http://some.server.com/posts/1/comments' )? >>>>>>>>> | >>>>>>>>> | >>>>>>>>> | >>>>>>>>> | >>>>>>>>> | > The type information of the property isn't available unless we can infer >>>>>>>>> | > it from the Post object. >>>>>>>>> | > >>>>>>>>> | >>>>>>>>> | >>>>>>>>> | >>>>>>>>> | >>>>>>>>> | >>>>>>>>> | > >>>>>>>>> | > >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | Greetings, >>>>>>>>> | > | Matthias >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | On Fri, Apr 5, 2013 at 2:37 PM, Matthias Wessendorf < matzew(a)apache.org > >>>>>>>>> | > | wrote: >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | Thought a bit more about it and chatted with friends, >>>>>>>>> | > | >>>>>>>>> | > | the issue with the sub pipes is: it adds state and is perhaps an API >>>>>>>>> | > | construct that is a bit hard to understand (see all the discussions here) >>>>>>>>> | > | >>>>>>>>> | > | Not sure - but currently we can access "kid resources", with our API - >>>>>>>>> | > right >>>>>>>>> | > | ? >>>>>>>>> | > | >>>>>>>>> | > | https://gist.github.com/matzew/6ab432e437b9a017a21d >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | Perhaps it's better to just keep it that way? This has the benefit of >>>>>>>>> | > using >>>>>>>>> | > | an established and know API, the different pipes are accessible via the >>>>>>>>> | > | pipeline object; >>>>>>>>> | > | >>>>>>>>> | > | And the code is not too much code; it's simply an explicit pipe ... >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | On Fri, Apr 5, 2013 at 10:56 AM, Matthias Wessendorf < matzew(a)apache.org >>>>>>>>> | > | > >>>>>>>>> | > | wrote: >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | On Fri, Apr 5, 2013 at 10:52 AM, Sebastien Blanc < scm.blanc(a)gmail.com > >>>>>>>>> | > | wrote: >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | On Fri, Apr 5, 2013 at 10:36 AM, Matthias Wessendorf < matzew(a)apache.org >>>>>>>>> | > | > >>>>>>>>> | > | wrote: >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | On Fri, Apr 5, 2013 at 10:14 AM, Christos Vasilakis < cvasilak(a)gmail.com >>>>>>>>> | > | > >>>>>>>>> | > | wrote: >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | Hi >>>>>>>>> | > | >>>>>>>>> | > | some comments >>>>>>>>> | > | >>>>>>>>> | > | I believe the method can't be used since you don't know the team for the >>>>>>>>> | > | players so you can't retrieve the pipe directly..right? >>>>>>>>> | > | >>>>>>>>> | > | Isn't that really up to the impl of the rest service? >>>>>>>>> | > | They could return a list of teamsHePlayed for; >>>>>>>>> | > | >>>>>>>>> | > | So, let's not tie this API to a specific, not existing RESTful service; >>>>>>>>> | > | >>>>>>>>> | > | +1, we don't need to care about that, we must just focus on how we can >>>>>>>>> | > | declare and call nested pipes. >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | yep >>>>>>>>> | > | >>>>>>>>> | > | I guess this is perhaps the closest we can come to : >>>>>>>>> | > | >>>>>>>>> | > | id<AGPipe> allOwnersInNewYorkPipe = [leaguesPipe subPipe:@"owners" >>>>>>>>> | > | for:@"newyork"]; >>>>>>>>> | > | >>>>>>>>> | > | and than.... on the 'leaguesPipe' you can access its kids with something >>>>>>>>> | > like >>>>>>>>> | > | : >>>>>>>>> | > | >>>>>>>>> | > | NSArray* kids = [leaguesPipe subPipes]; >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | However, that adds some state to a specific pipe object >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | -M >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | getPlayers ( Callback < List < Player >> callback ) { >>>>>>>>> | > | pipe . get ( "player" ). read ( callback ); >>>>>>>>> | > | } >>>>>>>>> | > | >>>>>>>>> | > | Further my questions is, how is a third (or arbitrary) nested resources >>>>>>>>> | > are >>>>>>>>> | > | supported? I mean for a url schema like this >>>>>>>>> | > | >>>>>>>>> | > | soccer.org/leagues/ {id}/teams/{id}/players/{id} >>>>>>>>> | > | >>>>>>>>> | > | first we access the leagues: >>>>>>>>> | > | --- >>>>>>>>> | > | getLeagues(Callback<List<Leagues>> callback) { >>>>>>>>> | > | pipe.get("leagues").read(callback); >>>>>>>>> | > | } >>>>>>>>> | > | --- >>>>>>>>> | > | then the teams for this league: >>>>>>>>> | > | --- >>>>>>>>> | > | getTeamsOnLeaque(Leaque league, Callback<List<Team>> callback) { >>>>>>>>> | > | pipe.junction("league","team").read(leaque, callback); >>>>>>>>> | > | } >>>>>>>>> | > | --- >>>>>>>>> | > | ..and then we access the "Players" for a "Team": >>>>>>>>> | > | --- >>>>>>>>> | > | getPlayersOnTeam(Team team, Callback<List<Player>> callback) { >>>>>>>>> | > | pipe.junction("team","player").read(team, callback); >>>>>>>>> | > | } >>>>>>>>> | > | --- >>>>>>>>> | > | But where is the "League" information to fill the "/leagues/{id}..." >>>>>>>>> | > path? >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | I'd assume the information is 'inherited' out of a given pipe, when >>>>>>>>> | > doing the >>>>>>>>> | > | 'join' >>>>>>>>> | > | >>>>>>>>> | > | e.g. like >>>>>>>>> | > | myTeamsForLeaguePipe = leaguePipe.junction("team"); >>>>>>>>> | > | >>>>>>>>> | > | not sure... >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | Unless you mean something like: >>>>>>>>> | > | --- >>>>>>>>> | > | getPlayersOnTeam(Leaque league, Team team, Callback<List<Player>> >>>>>>>>> | > callback) { >>>>>>>>> | > | pipe.junction("league", "team","player").read(league, team, callback); >>>>>>>>> | > | } >>>>>>>>> | > | >>>>>>>>> | > | I am not sure if that is really easy to understand/use >>>>>>>>> | > | >>>>>>>>> | > | Yes and the term "junction" is a bit confusing as it don't express >>>>>>>>> | > explicitly >>>>>>>>> | > | a parent/child relation. >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | --- >>>>>>>>> | > | >>>>>>>>> | > | probably I am missing sth.. >>>>>>>>> | > | >>>>>>>>> | > | Thanks, >>>>>>>>> | > | Christos >>>>>>>>> | > | >>>>>>>>> | > | On Apr 4, 2013, at 5:52 PM, Summers Pittman < supittma(a)redhat.com > >>>>>>>>> | > wrote: >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | What if we create a new metaphor, a Junction. >>>>>>>>> | > | >>>>>>>>> | > | https://gist.github.com/secondsun/dcf5682b6ff17c729d9a >>>>>>>>> | > | >>>>>>>>> | > | It joins two pipes together and can be used over and over again with >>>>>>>>> | > | different data? >>>>>>>>> | > | It isn't a Pipe though, but perhaps that could be changed to look more >>>>>>>>> | > like >>>>>>>>> | > | Christos's previous example. >>>>>>>>> | > | >>>>>>>>> | > | At the very least I like the words "junction" or "join" more than "of" >>>>>>>>> | > | >>>>>>>>> | > | ----- Original Message ----- >>>>>>>>> | > | | From: "Christos Vasilakis" < cvasilak(a)gmail.com > >>>>>>>>> | > | | To: "AeroGear Developer Mailing List" < aerogear-dev(a)lists.jboss.org > >>>>>>>>> | > | | Sent: Wednesday, April 3, 2013 3:03:02 AM >>>>>>>>> | > | | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for nested >>>>>>>>> | > | | endpoints >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | On Apr 2, 2013, at 4:03 PM, Matthias Wessendorf < matzew(a)apache.org > >>>>>>>>> | > | | wrote: >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | Two thoughts.... >>>>>>>>> | > | | >>>>>>>>> | > | | 1) the 'original' leaguesPipe has no clue about the subpipes, right ? >>>>>>>>> | > | | 2) should a pipe offer a 'getter' for all it's sub pipes ? >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | Just a thought is instead of using Pipe, to continue using Pipeline >>>>>>>>> | > adding >>>>>>>>> | > | | an >>>>>>>>> | > | | extra parameter " of" for specifying the parent : E.g.: >>>>>>>>> | > | | >>>>>>>>> | > | | ….. >>>>>>>>> | > | | id<AGPipe> leaguesPipe = [pipeline pipe@"leagues"]; >>>>>>>>> | > | | >>>>>>>>> | > | | id<AGPipe> allTeamsInSeattlePipe = [pipeline subPipe@"teams" of >>>>>>>>> | > | | :leaguesPipe >>>>>>>>> | > | | for:@"seattle"] >>>>>>>>> | > | | >>>>>>>>> | > | | id<AGPipe> allPlayersInTrebuchetPipe = [pipeline subPipe:@"players" >>>>>>>>> | > of: >>>>>>>>> | > | | allTeamsInSeattlePipe for:@"trebuchet"]; >>>>>>>>> | > | | ….. >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | Wdyt? >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | -M >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | Thanks, >>>>>>>>> | > | | Christos >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | soccer.org/leagues/seattle/teams/trebuchet/players/foo - > >>>>>>>>> | > | | [[pipeline pipe:@"players" pathParams:@[@"seattle", @"trebuchet"]] >>>>>>>>> | > read >>>>>>>>> | > | | :@"foo"] .. >>>>>>>>> | > | | ----- >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | Wdyt? >>>>>>>>> | > | | >>>>>>>>> | > | | Thanks >>>>>>>>> | > | | Christos >>>>>>>>> | > | | >>>>>>>>> | > | | On Mar 18, 2013, at 1:12 PM, Sebastien Blanc < scm.blanc(a)gmail.com > >>>>>>>>> | > wrote: >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | Well, that would not be possible, for that you will have to create a >>>>>>>>> | > | | "child" >>>>>>>>> | > | | pipe. But I agree, that is maybe no optimal ... >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | On Fri, Mar 15, 2013 at 6:44 PM, Summers Pittman < supittma(a)redhat.com >>>>>>>>> | > | | > >>>>>>>>> | > | | wrote: >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | On 03/15/2013 01:34 PM, Sebastien Blanc wrote: >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | I like the idea but I will more see that has a method/function for the >>>>>>>>> | > | | pipelineManager (and will be easier to implement in JS, I think) : >>>>>>>>> | > | | >>>>>>>>> | > | | var myParentPipe = >>>>>>>>> | > Aerogear.Pipeline({name:"parentPipe"}).pipes.parentPipe >>>>>>>>> | > | | >>>>>>>>> | > | | var myChildPipe = Aerogear.Pipeline.fromParent(myParentPipe, {options} >>>>>>>>> | > ) >>>>>>>>> | > | | What would it look like to get a child record from a parent? >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | On Fri, Mar 15, 2013 at 5:37 PM, Douglas Campos < qmx(a)qmx.me > wrote: >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | What about this? >>>>>>>>> | > | | >>>>>>>>> | > | | Pipeline<Post> postPipeline = … >>>>>>>>> | > | | Post post = // get from the pipeline >>>>>>>>> | > | | Pipeline<Comment> >>>>>>>>> | > | | postPipeline.childPipelineForOrOtherWeirdName(Comment.class, post) >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | On 15/03/2013, at 12:26, Summers Pittman < supittma(a)redhat.com > >>>>>>>>> | > wrote: >>>>>>>>> | > | | >>>>>>>>> | > | | > On 03/14/2013 04:48 AM, Matthias Wessendorf wrote: >>>>>>>>> | > | | >> >>>>>>>>> | > | | >> >>>>>>>>> | > | | >> On Thu, Mar 14, 2013 at 9:32 AM, Sebastien Blanc < >>>>>>>>> | > scm.blanc(a)gmail.com > >>>>>>>>> | > | | >> wrote: >>>>>>>>> | > | | >> Hi, >>>>>>>>> | > | | >> While I was playing with scaffolding and tried to build a simple >>>>>>>>> | > Blog >>>>>>>>> | > | | >> Application with Aerogear I faced the current situation : >>>>>>>>> | > | | >> I have a Post object which contains many Comment objects. Now I >>>>>>>>> | > want to >>>>>>>>> | > | | >> call my Post pipe to retrieve the related comments, I have >>>>>>>>> | > currently 2 >>>>>>>>> | > | | >> options : >>>>>>>>> | > | | >> >>>>>>>>> | > | | >> /posts/1 -> assuming comments will be implicitly retrieved (eager >>>>>>>>> | > | | >> loading) >>>>>>>>> | > | | >> /comments/?postid=1 >>>>>>>>> | > | | >> >>>>>>>>> | > | | >> But regarding our model the correct form should be : >>>>>>>>> | > | | >> >>>>>>>>> | > | | >> /posts/1/comments >>>>>>>>> | > | | >> >>>>>>>>> | > | | >> >>>>>>>>> | > | | >> +1 >>>>>>>>> | > | | >> that is the ideal way to model URIs for "nested" resources. >>>>>>>>> | > | | >> >>>>>>>>> | > | | >> See [1], extracted from [2] >>>>>>>>> | > | | >> >>>>>>>>> | > | | >> >>>>>>>>> | > | | >> >>>>>>>>> | > | | >> But, AFAIK, with the current API, it is not possible to define this >>>>>>>>> | > last >>>>>>>>> | > | | >> pattern (at least for JS and iOs, confirmed by Matzew). When doing a >>>>>>>>> | > | | >> read >>>>>>>>> | > | | >> we can pass an id option but as mentioned in the doc, this id will >>>>>>>>> | > | | >> always >>>>>>>>> | > | | >> be append to the endpoint. >>>>>>>>> | > | | >> >>>>>>>>> | > | | >> >>>>>>>>> | > | | >> Well, it is possible - but in a very (IMO) ugly way: >>>>>>>>> | > | | >> >>>>>>>>> | > | | >> https://gist.github.com/matzew/6ab432e437b9a017a21d >>>>>>>>> | > | | >> >>>>>>>>> | > | | >> >>>>>>>>> | > | | >> >>>>>>>>> | > | | >> >>>>>>>>> | > | | >> IMO, we should be able to support this pattern but for now I'm not >>>>>>>>> | > | | >> really >>>>>>>>> | > | | >> sure how to specify this in our API, so if you have any ideas >>>>>>>>> | > feedback >>>>>>>>> | > | | >> this thread has been made for you ! >>>>>>>>> | > | | >> >>>>>>>>> | > | | >> >>>>>>>>> | > | | >> >>>>>>>>> | > | | >> Suggestion: Enhance the read function - example: >>>>>>>>> | > | | >> >>>>>>>>> | > | | >> https://gist.github.com/matzew/04f069dfbed2cc77a8b4 >>>>>>>>> | > | | > I'm thinking of the inverse myself. Add a "ParentPath" property >>>>>>>>> | > which can >>>>>>>>> | > | | > be used to extract information from parent objects. >>>>>>>>> | > | | > >>>>>>>>> | > | | > https://gist.github.com/secondsun/17ce96082eda37dbd10e >>>>>>>>> | > | | > >>>>>>>>> | > | | >> >>>>>>>>> | > | | >> >>>>>>>>> | > | | >> -Matthias >>>>>>>>> | > | | >> >>>>>>>>> | > | | >> >>>>>>>>> | > | | >> [1] >>>>>>>>> | > | | >> >>>>>>>>> | > http://www.infoq.com/resource/articles/rest-introduction/en/resources/fig... >>>>>>>>> | > | | >> [2] http://www.infoq.com/articles/rest-introduction >>>>>>>>> | > | | >> >>>>>>>>> | > | | >> >>>>>>>>> | > | | >> >>>>>>>>> | > | | >> >>>>>>>>> | > | | >> Seb >>>>>>>>> | > | | >> >>>>>>>>> | > | | >> >>>>>>>>> | > | | >> _______________________________________________ >>>>>>>>> | > | | >> aerogear-dev mailing list >>>>>>>>> | > | | >> aerogear-dev(a)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 >>>>>>>>> | > | | >> >>>>>>>>> | > | | >> _______________________________________________ >>>>>>>>> | > | | >> aerogear-dev mailing list >>>>>>>>> | > | | >> >>>>>>>>> | > | | >> aerogear-dev(a)lists.jboss.org >>>>>>>>> | > | | >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>> | > | | > >>>>>>>>> | > | | > _______________________________________________ >>>>>>>>> | > | | > aerogear-dev mailing list >>>>>>>>> | > | | > aerogear-dev(a)lists.jboss.org >>>>>>>>> | > | | > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>> | > | | >>>>>>>>> | > | | -- qmx >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | _______________________________________________ >>>>>>>>> | > | | aerogear-dev mailing list >>>>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | _______________________________________________ >>>>>>>>> | > | | aerogear-dev mailing list aerogear-dev(a)lists.jboss.org >>>>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | _______________________________________________ >>>>>>>>> | > | | aerogear-dev mailing list >>>>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>> | > | | >>>>>>>>> | > | | _______________________________________________ >>>>>>>>> | > | | aerogear-dev mailing list >>>>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | _______________________________________________ >>>>>>>>> | > | | aerogear-dev mailing list >>>>>>>>> | > | | aerogear-dev(a)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 >>>>>>>>> | > | | _______________________________________________ >>>>>>>>> | > | | aerogear-dev mailing list >>>>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | _______________________________________________ >>>>>>>>> | > | | aerogear-dev mailing list >>>>>>>>> | > | | aerogear-dev(a)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 >>>>>>>>> | > | | _______________________________________________ >>>>>>>>> | > | | aerogear-dev mailing list >>>>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>> | > | | >>>>>>>>> | > | | >>>>>>>>> | > | | _______________________________________________ >>>>>>>>> | > | | aerogear-dev mailing list >>>>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>> | > | >>>>>>>>> | > | _______________________________________________ >>>>>>>>> | > | aerogear-dev mailing list >>>>>>>>> | > | aerogear-dev(a)lists.jboss.org >>>>>>>>> | > | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | _______________________________________________ >>>>>>>>> | > | aerogear-dev mailing list >>>>>>>>> | > | aerogear-dev(a)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 >>>>>>>>> | > | >>>>>>>>> | > | _______________________________________________ >>>>>>>>> | > | aerogear-dev mailing list >>>>>>>>> | > | aerogear-dev(a)lists.jboss.org >>>>>>>>> | > | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | _______________________________________________ >>>>>>>>> | > | aerogear-dev mailing list >>>>>>>>> | > | aerogear-dev(a)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 >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | -- >>>>>>>>> | > | Matthias Wessendorf >>>>>>>>> | > | >>>>>>>>> | > | blog: http://matthiaswessendorf.wordpress.com/ >>>>>>>>> | > | sessions: http://www.slideshare.net/mwessendorf >>>>>>>>> | > | twitter: http://twitter.com/mwessendorf >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | >>>>>>>>> | > | -- >>>>>>>>> | > | Matthias Wessendorf >>>>>>>>> | > | >>>>>>>>> | > | blog: http://matthiaswessendorf.wordpress.com/ >>>>>>>>> | > | sessions: http://www.slideshare.net/mwessendorf >>>>>>>>> | > | twitter: http://twitter.com/mwessendorf >>>>>>>>> | > | >>>>>>>>> | > | _______________________________________________ >>>>>>>>> | > | aerogear-dev mailing list >>>>>>>>> | > | aerogear-dev(a)lists.jboss.org >>>>>>>>> | > | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>> | > >>>>>>>>> | > _______________________________________________ >>>>>>>>> | > aerogear-dev mailing list >>>>>>>>> | > aerogear-dev(a)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 >>>>>>>>> | >>>>>>>>> | _______________________________________________ >>>>>>>>> | aerogear-dev mailing list >>>>>>>>> | aerogear-dev(a)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 >>>>>>>>> | >>>>>>>>> | _______________________________________________ >>>>>>>>> | aerogear-dev mailing list >>>>>>>>> | aerogear-dev(a)lists.jboss.org >>>>>>>>> | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> aerogear-dev mailing list >>>>>>>>> aerogear-dev(a)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 >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> aerogear-dev mailing list >>>>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> aerogear-dev mailing list >>>>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing list >>>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

This is the same issue I pointed out this morning on Sebi's implementation. I need to think more about a solution.

On Apr 23, 2013, at 7:33 AM, Christos Vasilakis <cvasilak(a)gmail.com&gt; wrote: Hi, as I implement the iOS support for nested paths, and in particular 'save' and 'remove' a situation arises. Consider the 'save' operation for a new team in the following path (a pipe has been instantiated that points to 'leagues') : soccer.org/leagues/foo/teams To save a new team, the user must: [leaguesPipe save:teamObject resourcePath:"/foo/teams"] Notice that now, we NEED to pass the id of the league in the resourcePath for this to work("foo"). To update an existing team, the user must: [leaguesPipe save:teamObject resourcePath:"/foo/teams"] Again the id of the leagues needs to be passed on the resourcePath NOTE: For the update to work, teamObject is implied to have the config.idset (here we assume that the teamObject has similar config_id name with league for this to work ??) Similar for remove: [leaguesPipe remove:teamObject resourcePath:"/foo/teams"] So, for cases of 'save' and 'remove', the resourcePath endpoint with the Pipe id SET must come first, and then we append the object's endpoint. Thoughts? Thanks Christos On Apr 18, 2013, at 6:39 PM, Daniel Bevenius <daniel.bevenius(a)gmail.com&gt; wrote: Yeah, I'm all for 'resourcePath' now that I'm not as confused anymore :) On 18 April 2013 17:37, Christos Vasilakis <cvasilak(a)gmail.com&gt; wrote: > I think If no alternative comes along, let's stick to 'resourcePath' for > now.. > > > On Apr 18, 2013, at 6:23 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > > So we all agreed on "resourcePath" ? > > > > On Thu, Apr 18, 2013 at 4:54 PM, Christos Vasilakis <cvasilak(a)gmail.com&gt;wrote: > >> Hi, >> >> have created the epic to track this, feel free to edit >> >> https://issues.jboss.org/browse/AEROGEAR-1123 >> >> - >> Christos >> >> On Apr 16, 2013, at 4:23 PM, Daniel Bevenius <daniel.bevenius(a)gmail.com&gt; >> wrote: >> >> doh! Sorry. I was just looking at the first examples in the gist and did >> not realize these could have multiple segments. >> >> >> On 16 April 2013 15:18, Kris Borchers <kris(a)redhat.com&gt; wrote: >> >>> Hmm, I like the idea of looking to standards but if I'm reading it >>> right, segment there means just a portion of the URI between slashes, not >>> multiple slash-separated segments. >>> >>> On Apr 16, 2013, at 8:14 AM, Daniel Bevenius <daniel.bevenius(a)gmail.com&gt; >>> wrote: >>> >>> I agree, when I read resourcePath I read that as a path to resource. >>> How about pathSegment or segment as used by >>> http://tools.ietf.org/html/rfc3986#section-3.3 ? >>> >>> >>> On 16 April 2013 15:12, Kris Borchers <kris(a)redhat.com&gt; wrote: >>> >>>> My only issue with resourcePath is that it doesn't imply that the path >>>> is relative to the current pipe. I mean, it should be implied since you're >>>> already working with a pipe and we can be explicit about that in >>>> documentation but I still wish it was somehow in the name. I think that was >>>> the goal of using "nested" in the name but I already expressed my issue >>>> with that. Any other thoughts would be appreciated but I could be happy >>>> with resourcePath. >>>> >>>> On Apr 16, 2013, at 7:55 AM, Lucas Holmquist <lholmqui(a)redhat.com&gt; >>>> wrote: >>>> >>>> +1 to resourcePath . it beats my thought of >>>> "superawesomenestedresourcethingy" >>>> On Apr 16, 2013, at 8:39 AM, Christos Vasilakis <cvasilak(a)gmail.com&gt; >>>> wrote: >>>> >>>> +1 >>>> >>>> I think it describes the feature better. >>>> >>>> >>>> On Apr 16, 2013, at 3:09 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; >>>> wrote: >>>> >>>> +1 on the "resourcePath", you nailed it ! >>>> >>>> >>>> >>>> On Tue, Apr 16, 2013 at 2:03 PM, Kris Borchers <kris(a)redhat.com&gt;wrote: >>>> >>>>> Hmmm, "nestedResource" isn't terrible but not crazy about "nested" >>>>> since they're not necessarily nested but just related. Hmmmmm. >>>>> >>>>> It's not that I hate resource, I think it kind of makes sense if you >>>>> know what we're talking about. How about something like "resourcePath" to >>>>> be a little more explicit in what it is? Still not crazy about that but >>>>> feel like it's better/closer to something that describes what it is. >>>>> >>>>> On Apr 16, 2013, at 6:44 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; >>>>> wrote: >>>>> >>>>> Well, there seems to be an agreement on option #1 , except for the >>>>> name "resource" , so let's find a name that we all agree on and so we can >>>>> going further with this feature. >>>>> My propositions: "nestedResource" , "fragment", "nestedURI" ... But >>>>> I'm not really fan of all of my propositions ... >>>>> Seb >>>>> >>>>> >>>>> >>>>> On Thu, Apr 11, 2013 at 4:07 PM, Summers Pittman <supittma(a)redhat.com >>>>> > wrote: >>>>> >>>>>> With #1 is `resource` a URI? If so, will developers have to build >>>>>> the URI by hand? >>>>>> >>>>>> >>>>>> On 04/10/2013 10:48 AM, Christos Vasilakis wrote: >>>>>> >>>>>> Hi >>>>>> >>>>>> I've prepared a document[1] that collectively describes the >>>>>> different approaches discussed in this thread for supporting the nested >>>>>> resources. It is split in two sections, ones that don't require >>>>>> modification to the existing API and ones that do >>>>>> >>>>>> Please have a look and let me know if I miss sth or interpret one >>>>>> approach wrong. >>>>>> >>>>>> Thanks >>>>>> Christos >>>>>> >>>>>> [1] https://gist.github.com/cvasilak/4a5f51b8d1ad9cc7f21b >>>>>> >>>>>> On Apr 9, 2013, at 10:19 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; >>>>>> wrote: >>>>>> >>>>>> Hey, >>>>>> Like paging, could we start 2 gists : one with a side to side techno >>>>>> samples and another one with high level Specs ? I start a bit to get lost >>>>>> in this thread :) >>>>>> Just one remark when reading the last messages, one "must have" is >>>>>> to be able to retrieve all the comments for a post without EVER retrieving >>>>>> the post record, so >>>>>> /posts/1/comments will retrieve all the comments for post 1 but >>>>>> will actually never call posts/1 : in this covered in your last examples ? >>>>>> (spec could be : "by-pass parent GET resource" >>>>>> Seb >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Apr 9, 2013 at 9:03 AM, Matthias Wessendorf < >>>>>> matzew(a)apache.org&gt; wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Apr 8, 2013 at 7:57 PM, Summers Pittman < >>>>>>> supittma(a)redhat.com&gt; wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>> | From: "Matthias Wessendorf" <matzew(a)apache.org&gt; >>>>>>>> | To: "AeroGear Developer Mailing List" < >>>>>>>> aerogear-dev(a)lists.jboss.org&gt; >>>>>>>> | Sent: Monday, April 8, 2013 1:22:19 PM >>>>>>>> | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for >>>>>>>> nested endpoints >>>>>>>> | >>>>>>>> | OK, with the following server API: >>>>>>>> | >>>>>>>> | http://some.server.com/posts/1 >>>>>>>> | http://some.server.com/posts/1/comments >>>>>>>> | (and NO 'comments' collection on the ' >>>>>>>> http://some.server.com/posts/1 ' >>>>>>>> | response) >>>>>>>> | >>>>>>>> | Does this (today) 'myPipe.read(1)' already read the specific >>>>>>>> comments ( >>>>>>>> | http://some.server.com/posts/1/comments ) ?? >>>>>>>> | >>>>>>>> | ======= JAVA API ======= >>>>>>>> | Class Post: >>>>>>>> | - string: id; >>>>>>>> | - string: title; >>>>>>>> | - string: postContent; >>>>>>>> | - List<Comment> comments; >>>>>>>> | Class Comment: >>>>>>>> | - string username; >>>>>>>> | - string comment; >>>>>>>> | >>>>>>>> | Or would the IMPL expect an 'embedded' _comments_ collection on >>>>>>>> the response >>>>>>>> | of "GET http://some.server.com/posts/1 " ? >>>>>>>> >>>>>>>> >>>>>>> It will not read /posts/1/comments if the Pipe's endpoint is >>>>>>>> /posts. If you have a comments collection on the post but no comments data >>>>>>>> in the response then the value for getComments will just be null. >>>>>>>> >>>>>>> >>>>>>> Ok - so this needs to be tweaked in Java too, since it's very >>>>>>> common to model the REST endpoints like above; >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> | >>>>>>>> | >>>>>>>> | >>>>>>>> | On Mon, Apr 8, 2013 at 7:05 PM, Summers Pittman < >>>>>>>> supittma(a)redhat.com > >>>>>>>> | wrote: >>>>>>>> | >>>>>>>> | >>>>>>>> | No. The get of pipe 1 would have to include the comments for get >>>>>>>> comments to >>>>>>>> | work >>>>>>>> | >>>>>>>> | Sent from my Android phone using TouchDown ( www.nitrodesk.com ) >>>>>>>> | >>>>>>>> | >>>>>>>> | -----Original Message----- >>>>>>>> | From: Matthias Wessendorf [ matzew(a)apache.org ] >>>>>>>> | Received: Monday, 08 Apr 2013, 12:04PM >>>>>>>> | To: AeroGear Developer Mailing List [ >>>>>>>> aerogear-dev(a)lists.jboss.org ] >>>>>>>> | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for >>>>>>>> nested endpoints >>>>>>>> | >>>>>>>> | >>>>>>>> | On Mon, Apr 8, 2013 at 5:57 PM, Summers Pittman < >>>>>>>> supittma(a)redhat.com > >>>>>>>> | wrote: >>>>>>>> | >>>>>>>> | > >>>>>>>> | > >>>>>>>> | > ----- Original Message ----- >>>>>>>> | > | From: "Matthias Wessendorf" < matzew(a)apache.org > >>>>>>>> | > | To: "AeroGear Developer Mailing List" < >>>>>>>> aerogear-dev(a)lists.jboss.org > >>>>>>>> | > | Sent: Monday, April 8, 2013 10:28:46 AM >>>>>>>> | > | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for >>>>>>>> nested >>>>>>>> | > endpoints >>>>>>>> | > | >>>>>>>> | > | or, like before said - reading "lists" (e.g. all the >>>>>>>> comments for >>>>>>>> | > specific >>>>>>>> | > | blog post): >>>>>>>> | > | https://gist.github.com/matzew/04f069dfbed2cc77a8b4 >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | For Java.... I guess...... resolving this URL: >>>>>>>> | > | http://some.server.com/posts/1/comments >>>>>>>> | > | >>>>>>>> | > | could be done with this - right ? >>>>>>>> | > | >>>>>>>> | > | ======= >>>>>>>> | > | Class Post: >>>>>>>> | > | - string: title; >>>>>>>> | > | - string: postContent; >>>>>>>> | > | - List<Comment> comments; >>>>>>>> | > | Class Comment: >>>>>>>> | > | - string username; >>>>>>>> | > | - string comment; >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | // get all the comments for 1: >>>>>>>> | > | Post myPostOne = postPipe.read("1"); >>>>>>>> | > | myPostOne.getComments(); >>>>>>>> | > | >>>>>>>> | > | // get all the comments for 2: >>>>>>>> | > | Post myPostTwo = postPipe.read("2"); >>>>>>>> | > | myPostTwo.getComments(); >>>>>>>> | > | ======= >>>>>>>> | > >>>>>>>> | > It can be done with that yes. My concern was more when we had >>>>>>>> a Pipe of >>>>>>>> | > type <Post> and a readForResource(String property) method. >>>>>>>> | >>>>>>>> | >>>>>>>> | Ok - one more question >>>>>>>> | >>>>>>>> | >>>>>>>> | So... when doing: myPipe.read(1); does that "only" issue a GET >>>>>>>> against the ' >>>>>>>> | http://some.server.com/posts/1 ' resource? >>>>>>>> | >>>>>>>> | A second get, for the comments collection is than issued when >>>>>>>> calling >>>>>>>> | myPostOne.getComments();? >>>>>>>> | (GET against ' http://some.server.com/posts/1/comments' )? >>>>>>>> | >>>>>>>> | >>>>>>>> | >>>>>>>> | >>>>>>>> | > The type information of the property isn't available unless we >>>>>>>> can infer >>>>>>>> | > it from the Post object. >>>>>>>> | > >>>>>>>> | >>>>>>>> | >>>>>>>> | >>>>>>>> | >>>>>>>> | >>>>>>>> | > >>>>>>>> | > >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | Greetings, >>>>>>>> | > | Matthias >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | On Fri, Apr 5, 2013 at 2:37 PM, Matthias Wessendorf < >>>>>>>> matzew(a)apache.org > >>>>>>>> | > | wrote: >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | Thought a bit more about it and chatted with friends, >>>>>>>> | > | >>>>>>>> | > | the issue with the sub pipes is: it adds state and is >>>>>>>> perhaps an API >>>>>>>> | > | construct that is a bit hard to understand (see all the >>>>>>>> discussions here) >>>>>>>> | > | >>>>>>>> | > | Not sure - but currently we can access "kid resources", with >>>>>>>> our API - >>>>>>>> | > right >>>>>>>> | > | ? >>>>>>>> | > | >>>>>>>> | > | https://gist.github.com/matzew/6ab432e437b9a017a21d >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | Perhaps it's better to just keep it that way? This has the >>>>>>>> benefit of >>>>>>>> | > using >>>>>>>> | > | an established and know API, the different pipes are >>>>>>>> accessible via the >>>>>>>> | > | pipeline object; >>>>>>>> | > | >>>>>>>> | > | And the code is not too much code; it's simply an explicit >>>>>>>> pipe ... >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | On Fri, Apr 5, 2013 at 10:56 AM, Matthias Wessendorf < >>>>>>>> matzew(a)apache.org >>>>>>>> | > | > >>>>>>>> | > | wrote: >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | On Fri, Apr 5, 2013 at 10:52 AM, Sebastien Blanc < >>>>>>>> scm.blanc(a)gmail.com > >>>>>>>> | > | wrote: >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | On Fri, Apr 5, 2013 at 10:36 AM, Matthias Wessendorf < >>>>>>>> matzew(a)apache.org >>>>>>>> | > | > >>>>>>>> | > | wrote: >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | On Fri, Apr 5, 2013 at 10:14 AM, Christos Vasilakis < >>>>>>>> cvasilak(a)gmail.com >>>>>>>> | > | > >>>>>>>> | > | wrote: >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | Hi >>>>>>>> | > | >>>>>>>> | > | some comments >>>>>>>> | > | >>>>>>>> | > | I believe the method can't be used since you don't know the >>>>>>>> team for the >>>>>>>> | > | players so you can't retrieve the pipe directly..right? >>>>>>>> | > | >>>>>>>> | > | Isn't that really up to the impl of the rest service? >>>>>>>> | > | They could return a list of teamsHePlayed for; >>>>>>>> | > | >>>>>>>> | > | So, let's not tie this API to a specific, not existing >>>>>>>> RESTful service; >>>>>>>> | > | >>>>>>>> | > | +1, we don't need to care about that, we must just focus on >>>>>>>> how we can >>>>>>>> | > | declare and call nested pipes. >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | yep >>>>>>>> | > | >>>>>>>> | > | I guess this is perhaps the closest we can come to : >>>>>>>> | > | >>>>>>>> | > | id<AGPipe> allOwnersInNewYorkPipe = [leaguesPipe subPipe:@ >>>>>>>> "owners" >>>>>>>> | > | for:@"newyork"]; >>>>>>>> | > | >>>>>>>> | > | and than.... on the 'leaguesPipe' you can access its kids >>>>>>>> with something >>>>>>>> | > like >>>>>>>> | > | : >>>>>>>> | > | >>>>>>>> | > | NSArray* kids = [leaguesPipe subPipes]; >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | However, that adds some state to a specific pipe object >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | -M >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | getPlayers ( Callback < List < Player >> callback ) { >>>>>>>> | > | pipe . get ( "player" ). read ( callback ); >>>>>>>> | > | } >>>>>>>> | > | >>>>>>>> | > | Further my questions is, how is a third (or arbitrary) >>>>>>>> nested resources >>>>>>>> | > are >>>>>>>> | > | supported? I mean for a url schema like this >>>>>>>> | > | >>>>>>>> | > | soccer.org/leagues/ {id}/teams/{id}/players/{id} >>>>>>>> | > | >>>>>>>> | > | first we access the leagues: >>>>>>>> | > | --- >>>>>>>> | > | getLeagues(Callback<List<Leagues>> callback) { >>>>>>>> | > | pipe.get("leagues").read(callback); >>>>>>>> | > | } >>>>>>>> | > | --- >>>>>>>> | > | then the teams for this league: >>>>>>>> | > | --- >>>>>>>> | > | getTeamsOnLeaque(Leaque league, Callback<List<Team>> >>>>>>>> callback) { >>>>>>>> | > | pipe.junction("league","team").read(leaque, callback); >>>>>>>> | > | } >>>>>>>> | > | --- >>>>>>>> | > | ..and then we access the "Players" for a "Team": >>>>>>>> | > | --- >>>>>>>> | > | getPlayersOnTeam(Team team, Callback<List<Player>> callback) >>>>>>>> { >>>>>>>> | > | pipe.junction("team","player").read(team, callback); >>>>>>>> | > | } >>>>>>>> | > | --- >>>>>>>> | > | But where is the "League" information to fill the >>>>>>>> "/leagues/{id}..." >>>>>>>> | > path? >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | I'd assume the information is 'inherited' out of a given >>>>>>>> pipe, when >>>>>>>> | > doing the >>>>>>>> | > | 'join' >>>>>>>> | > | >>>>>>>> | > | e.g. like >>>>>>>> | > | myTeamsForLeaguePipe = leaguePipe.junction("team"); >>>>>>>> | > | >>>>>>>> | > | not sure... >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | Unless you mean something like: >>>>>>>> | > | --- >>>>>>>> | > | getPlayersOnTeam(Leaque league, Team team, >>>>>>>> Callback<List<Player>> >>>>>>>> | > callback) { >>>>>>>> | > | pipe.junction("league", "team","player").read(league, team, >>>>>>>> callback); >>>>>>>> | > | } >>>>>>>> | > | >>>>>>>> | > | I am not sure if that is really easy to understand/use >>>>>>>> | > | >>>>>>>> | > | Yes and the term "junction" is a bit confusing as it don't >>>>>>>> express >>>>>>>> | > explicitly >>>>>>>> | > | a parent/child relation. >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | --- >>>>>>>> | > | >>>>>>>> | > | probably I am missing sth.. >>>>>>>> | > | >>>>>>>> | > | Thanks, >>>>>>>> | > | Christos >>>>>>>> | > | >>>>>>>> | > | On Apr 4, 2013, at 5:52 PM, Summers Pittman < >>>>>>>> supittma(a)redhat.com > >>>>>>>> | > wrote: >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | What if we create a new metaphor, a Junction. >>>>>>>> | > | >>>>>>>> | > | https://gist.github.com/secondsun/dcf5682b6ff17c729d9a >>>>>>>> | > | >>>>>>>> | > | It joins two pipes together and can be used over and over >>>>>>>> again with >>>>>>>> | > | different data? >>>>>>>> | > | It isn't a Pipe though, but perhaps that could be changed to >>>>>>>> look more >>>>>>>> | > like >>>>>>>> | > | Christos's previous example. >>>>>>>> | > | >>>>>>>> | > | At the very least I like the words "junction" or "join" more >>>>>>>> than "of" >>>>>>>> | > | >>>>>>>> | > | ----- Original Message ----- >>>>>>>> | > | | From: "Christos Vasilakis" < cvasilak(a)gmail.com > >>>>>>>> | > | | To: "AeroGear Developer Mailing List" < >>>>>>>> aerogear-dev(a)lists.jboss.org > >>>>>>>> | > | | Sent: Wednesday, April 3, 2013 3:03:02 AM >>>>>>>> | > | | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support >>>>>>>> for nested >>>>>>>> | > | | endpoints >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | On Apr 2, 2013, at 4:03 PM, Matthias Wessendorf < >>>>>>>> matzew(a)apache.org > >>>>>>>> | > | | wrote: >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | Two thoughts.... >>>>>>>> | > | | >>>>>>>> | > | | 1) the 'original' leaguesPipe has no clue about the >>>>>>>> subpipes, right ? >>>>>>>> | > | | 2) should a pipe offer a 'getter' for all it's sub pipes ? >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | Just a thought is instead of using Pipe, to continue using >>>>>>>> Pipeline >>>>>>>> | > adding >>>>>>>> | > | | an >>>>>>>> | > | | extra parameter " of" for specifying the parent : E.g.: >>>>>>>> | > | | >>>>>>>> | > | | ….. >>>>>>>> | > | | id<AGPipe> leaguesPipe = [pipeline pipe@"leagues"]; >>>>>>>> | > | | >>>>>>>> | > | | id<AGPipe> allTeamsInSeattlePipe = [pipeline subPipe@"teams" >>>>>>>> of >>>>>>>> | > | | :leaguesPipe >>>>>>>> | > | | for:@"seattle"] >>>>>>>> | > | | >>>>>>>> | > | | id<AGPipe> allPlayersInTrebuchetPipe = [pipeline subPipe:@ >>>>>>>> "players" >>>>>>>> | > of: >>>>>>>> | > | | allTeamsInSeattlePipe for:@"trebuchet"]; >>>>>>>> | > | | ….. >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | Wdyt? >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | -M >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | Thanks, >>>>>>>> | > | | Christos >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | soccer.org/leagues/seattle/teams/trebuchet/players/foo - > >>>>>>>> | > | | [[pipeline pipe:@"players" pathParams:@[@"seattle", >>>>>>>> @"trebuchet"]] >>>>>>>> | > read >>>>>>>> | > | | :@"foo"] .. >>>>>>>> | > | | ----- >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | Wdyt? >>>>>>>> | > | | >>>>>>>> | > | | Thanks >>>>>>>> | > | | Christos >>>>>>>> | > | | >>>>>>>> | > | | On Mar 18, 2013, at 1:12 PM, Sebastien Blanc < >>>>>>>> scm.blanc(a)gmail.com > >>>>>>>> | > wrote: >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | Well, that would not be possible, for that you will have >>>>>>>> to create a >>>>>>>> | > | | "child" >>>>>>>> | > | | pipe. But I agree, that is maybe no optimal ... >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | On Fri, Mar 15, 2013 at 6:44 PM, Summers Pittman < >>>>>>>> supittma(a)redhat.com >>>>>>>> | > | | > >>>>>>>> | > | | wrote: >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | On 03/15/2013 01:34 PM, Sebastien Blanc wrote: >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | I like the idea but I will more see that has a >>>>>>>> method/function for the >>>>>>>> | > | | pipelineManager (and will be easier to implement in JS, I >>>>>>>> think) : >>>>>>>> | > | | >>>>>>>> | > | | var myParentPipe = >>>>>>>> | > Aerogear.Pipeline({name:"parentPipe"}).pipes.parentPipe >>>>>>>> | > | | >>>>>>>> | > | | var myChildPipe = >>>>>>>> Aerogear.Pipeline.fromParent(myParentPipe, {options} >>>>>>>> | > ) >>>>>>>> | > | | What would it look like to get a child record from a >>>>>>>> parent? >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | On Fri, Mar 15, 2013 at 5:37 PM, Douglas Campos < >>>>>>>> qmx(a)qmx.me > wrote: >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | What about this? >>>>>>>> | > | | >>>>>>>> | > | | Pipeline<Post> postPipeline = … >>>>>>>> | > | | Post post = // get from the pipeline >>>>>>>> | > | | Pipeline<Comment> >>>>>>>> | > | | >>>>>>>> postPipeline.childPipelineForOrOtherWeirdName(Comment.class, post) >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | On 15/03/2013, at 12:26, Summers Pittman < >>>>>>>> supittma(a)redhat.com > >>>>>>>> | > wrote: >>>>>>>> | > | | >>>>>>>> | > | | > On 03/14/2013 04:48 AM, Matthias Wessendorf wrote: >>>>>>>> | > | | >> >>>>>>>> | > | | >> >>>>>>>> | > | | >> On Thu, Mar 14, 2013 at 9:32 AM, Sebastien Blanc < >>>>>>>> | > scm.blanc(a)gmail.com > >>>>>>>> | > | | >> wrote: >>>>>>>> | > | | >> Hi, >>>>>>>> | > | | >> While I was playing with scaffolding and tried to build >>>>>>>> a simple >>>>>>>> | > Blog >>>>>>>> | > | | >> Application with Aerogear I faced the current situation >>>>>>>> : >>>>>>>> | > | | >> I have a Post object which contains many Comment >>>>>>>> objects. Now I >>>>>>>> | > want to >>>>>>>> | > | | >> call my Post pipe to retrieve the related comments, I >>>>>>>> have >>>>>>>> | > currently 2 >>>>>>>> | > | | >> options : >>>>>>>> | > | | >> >>>>>>>> | > | | >> /posts/1 -> assuming comments will be implicitly >>>>>>>> retrieved (eager >>>>>>>> | > | | >> loading) >>>>>>>> | > | | >> /comments/?postid=1 >>>>>>>> | > | | >> >>>>>>>> | > | | >> But regarding our model the correct form should be : >>>>>>>> | > | | >> >>>>>>>> | > | | >> /posts/1/comments >>>>>>>> | > | | >> >>>>>>>> | > | | >> >>>>>>>> | > | | >> +1 >>>>>>>> | > | | >> that is the ideal way to model URIs for "nested" >>>>>>>> resources. >>>>>>>> | > | | >> >>>>>>>> | > | | >> See [1], extracted from [2] >>>>>>>> | > | | >> >>>>>>>> | > | | >> >>>>>>>> | > | | >> >>>>>>>> | > | | >> But, AFAIK, with the current API, it is not possible to >>>>>>>> define this >>>>>>>> | > last >>>>>>>> | > | | >> pattern (at least for JS and iOs, confirmed by Matzew). >>>>>>>> When doing a >>>>>>>> | > | | >> read >>>>>>>> | > | | >> we can pass an id option but as mentioned in the doc, >>>>>>>> this id will >>>>>>>> | > | | >> always >>>>>>>> | > | | >> be append to the endpoint. >>>>>>>> | > | | >> >>>>>>>> | > | | >> >>>>>>>> | > | | >> Well, it is possible - but in a very (IMO) ugly way: >>>>>>>> | > | | >> >>>>>>>> | > | | >> https://gist.github.com/matzew/6ab432e437b9a017a21d >>>>>>>> | > | | >> >>>>>>>> | > | | >> >>>>>>>> | > | | >> >>>>>>>> | > | | >> >>>>>>>> | > | | >> IMO, we should be able to support this pattern but for >>>>>>>> now I'm not >>>>>>>> | > | | >> really >>>>>>>> | > | | >> sure how to specify this in our API, so if you have any >>>>>>>> ideas >>>>>>>> | > feedback >>>>>>>> | > | | >> this thread has been made for you ! >>>>>>>> | > | | >> >>>>>>>> | > | | >> >>>>>>>> | > | | >> >>>>>>>> | > | | >> Suggestion: Enhance the read function - example: >>>>>>>> | > | | >> >>>>>>>> | > | | >> https://gist.github.com/matzew/04f069dfbed2cc77a8b4 >>>>>>>> | > | | > I'm thinking of the inverse myself. Add a "ParentPath" >>>>>>>> property >>>>>>>> | > which can >>>>>>>> | > | | > be used to extract information from parent objects. >>>>>>>> | > | | > >>>>>>>> | > | | > https://gist.github.com/secondsun/17ce96082eda37dbd10e >>>>>>>> | > | | > >>>>>>>> | > | | >> >>>>>>>> | > | | >> >>>>>>>> | > | | >> -Matthias >>>>>>>> | > | | >> >>>>>>>> | > | | >> >>>>>>>> | > | | >> [1] >>>>>>>> | > | | >> >>>>>>>> | > >>>>>>>> http://www.infoq.com/resource/articles/rest-introduction/en/resources/fig... >>>>>>>> | > | | >> [2] http://www.infoq.com/articles/rest-introduction >>>>>>>> | > | | >> >>>>>>>> | > | | >> >>>>>>>> | > | | >> >>>>>>>> | > | | >> >>>>>>>> | > | | >> Seb >>>>>>>> | > | | >> >>>>>>>> | > | | >> >>>>>>>> | > | | >> _______________________________________________ >>>>>>>> | > | | >> aerogear-dev mailing list >>>>>>>> | > | | >> aerogear-dev(a)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 >>>>>>>> | > | | >> >>>>>>>> | > | | >> _______________________________________________ >>>>>>>> | > | | >> aerogear-dev mailing list >>>>>>>> | > | | >> >>>>>>>> | > | | >> aerogear-dev(a)lists.jboss.org >>>>>>>> | > | | >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> | > | | > >>>>>>>> | > | | > _______________________________________________ >>>>>>>> | > | | > aerogear-dev mailing list >>>>>>>> | > | | > aerogear-dev(a)lists.jboss.org >>>>>>>> | > | | > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> | > | | >>>>>>>> | > | | -- qmx >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | _______________________________________________ >>>>>>>> | > | | aerogear-dev mailing list >>>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | _______________________________________________ >>>>>>>> | > | | aerogear-dev mailing list aerogear-dev(a)lists.jboss.org >>>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | _______________________________________________ >>>>>>>> | > | | aerogear-dev mailing list >>>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> | > | | >>>>>>>> | > | | _______________________________________________ >>>>>>>> | > | | aerogear-dev mailing list >>>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | _______________________________________________ >>>>>>>> | > | | aerogear-dev mailing list >>>>>>>> | > | | aerogear-dev(a)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 >>>>>>>> | > | | _______________________________________________ >>>>>>>> | > | | aerogear-dev mailing list >>>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | _______________________________________________ >>>>>>>> | > | | aerogear-dev mailing list >>>>>>>> | > | | aerogear-dev(a)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 >>>>>>>> | > | | _______________________________________________ >>>>>>>> | > | | aerogear-dev mailing list >>>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> | > | | >>>>>>>> | > | | >>>>>>>> | > | | _______________________________________________ >>>>>>>> | > | | aerogear-dev mailing list >>>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> | > | >>>>>>>> | > | _______________________________________________ >>>>>>>> | > | aerogear-dev mailing list >>>>>>>> | > | aerogear-dev(a)lists.jboss.org >>>>>>>> | > | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | _______________________________________________ >>>>>>>> | > | aerogear-dev mailing list >>>>>>>> | > | aerogear-dev(a)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 >>>>>>>> | > | >>>>>>>> | > | _______________________________________________ >>>>>>>> | > | aerogear-dev mailing list >>>>>>>> | > | aerogear-dev(a)lists.jboss.org >>>>>>>> | > | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | _______________________________________________ >>>>>>>> | > | aerogear-dev mailing list >>>>>>>> | > | aerogear-dev(a)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 >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | -- >>>>>>>> | > | Matthias Wessendorf >>>>>>>> | > | >>>>>>>> | > | blog: http://matthiaswessendorf.wordpress.com/ >>>>>>>> | > | sessions: http://www.slideshare.net/mwessendorf >>>>>>>> | > | twitter: http://twitter.com/mwessendorf >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | >>>>>>>> | > | -- >>>>>>>> | > | Matthias Wessendorf >>>>>>>> | > | >>>>>>>> | > | blog: http://matthiaswessendorf.wordpress.com/ >>>>>>>> | > | sessions: http://www.slideshare.net/mwessendorf >>>>>>>> | > | twitter: http://twitter.com/mwessendorf >>>>>>>> | > | >>>>>>>> | > | _______________________________________________ >>>>>>>> | > | aerogear-dev mailing list >>>>>>>> | > | aerogear-dev(a)lists.jboss.org >>>>>>>> | > | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> | > >>>>>>>> | > _______________________________________________ >>>>>>>> | > aerogear-dev mailing list >>>>>>>> | > aerogear-dev(a)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 >>>>>>>> | >>>>>>>> | _______________________________________________ >>>>>>>> | aerogear-dev mailing list >>>>>>>> | aerogear-dev(a)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 >>>>>>>> | >>>>>>>> | _______________________________________________ >>>>>>>> | aerogear-dev mailing list >>>>>>>> | aerogear-dev(a)lists.jboss.org >>>>>>>> | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing list >>>>>>>> aerogear-dev(a)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 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing listaerogear-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Yes , i.e a common use case, we want to delete comment with id 5 from blog post with id 2 : DELETE /post/2/comment/5 With the nested endpoints has we have defined it will be something like : pipe.remove( 2 , { resourcePath:"comment/5" } ); Which is indeed not crystal clear. But in the same time we really need to provide a solution. We could maybe introduce a "resourcePathId" ? pipe.remove( 2 , { resourcePath: "comment", resourcePathId: 5 } ); But that would only make sense for a "one level" nested resource ...

On Tue, Apr 30, 2013 at 9:43 AM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: > > > > On Tue, Apr 23, 2013 at 2:38 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > >> This is the same issue I pointed out this morning on Sebi's >> implementation. I need to think more about a solution. >> > > > I agree that the 'save' and the 'remove' are a bit weird (hard to > understand). > > -Matthias > > > >> >> On Apr 23, 2013, at 7:33 AM, Christos Vasilakis <cvasilak(a)gmail.com&gt; >> wrote: >> >> Hi, >> >> as I implement the iOS support for nested paths, and in particular >> 'save' and 'remove' a situation arises. >> >> Consider the 'save' operation for a new team in the following path >> (a pipe has been instantiated that points to 'leagues') : >> >> soccer.org/leagues/foo/teams >> >> To save a new team, the user must: >> >> [leaguesPipe save:teamObject resourcePath:"/foo/teams"] >> >> Notice that now, we NEED to pass the id of the league in the >> resourcePath for this to work("foo"). >> >> To update an existing team, the user must: >> >> [leaguesPipe save:teamObject resourcePath:"/foo/teams"] >> >> Again the id of the leagues needs to be passed on the resourcePath >> >> NOTE: For the update to work, teamObject is implied to have the >> config.id set (here we assume that the teamObject has similar config_id >> name with league for this to work ??) >> >> Similar for remove: >> >> [leaguesPipe remove:teamObject resourcePath:"/foo/teams"] >> >> So, for cases of 'save' and 'remove', the resourcePath endpoint with the >> Pipe id SET must come first, and then we append the object's endpoint. >> >> Thoughts? >> >> Thanks >> Christos >> >> On Apr 18, 2013, at 6:39 PM, Daniel Bevenius <daniel.bevenius(a)gmail.com&gt; >> wrote: >> >> Yeah, I'm all for 'resourcePath' now that I'm not as confused anymore :) >> >> >> On 18 April 2013 17:37, Christos Vasilakis <cvasilak(a)gmail.com&gt; wrote: >> >>> I think If no alternative comes along, let's stick to 'resourcePath' >>> for now.. >>> >>> >>> On Apr 18, 2013, at 6:23 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; >>> wrote: >>> >>> So we all agreed on "resourcePath" ? >>> >>> >>> >>> On Thu, Apr 18, 2013 at 4:54 PM, Christos Vasilakis <cvasilak(a)gmail.com >>> > wrote: >>> >>>> Hi, >>>> >>>> have created the epic to track this, feel free to edit >>>> >>>> https://issues.jboss.org/browse/AEROGEAR-1123 >>>> >>>> - >>>> Christos >>>> >>>> On Apr 16, 2013, at 4:23 PM, Daniel Bevenius < >>>> daniel.bevenius(a)gmail.com&gt; wrote: >>>> >>>> doh! Sorry. I was just looking at the first examples in the gist and >>>> did not realize these could have multiple segments. >>>> >>>> >>>> On 16 April 2013 15:18, Kris Borchers <kris(a)redhat.com&gt; wrote: >>>> >>>>> Hmm, I like the idea of looking to standards but if I'm reading it >>>>> right, segment there means just a portion of the URI between slashes, not >>>>> multiple slash-separated segments. >>>>> >>>>> On Apr 16, 2013, at 8:14 AM, Daniel Bevenius < >>>>> daniel.bevenius(a)gmail.com&gt; wrote: >>>>> >>>>> I agree, when I read resourcePath I read that as a path to resource. >>>>> How about pathSegment or segment as used by >>>>> http://tools.ietf.org/html/rfc3986#section-3.3 ? >>>>> >>>>> >>>>> On 16 April 2013 15:12, Kris Borchers <kris(a)redhat.com&gt; wrote: >>>>> >>>>>> My only issue with resourcePath is that it doesn't imply that the >>>>>> path is relative to the current pipe. I mean, it should be implied since >>>>>> you're already working with a pipe and we can be explicit about that in >>>>>> documentation but I still wish it was somehow in the name. I think that was >>>>>> the goal of using "nested" in the name but I already expressed my issue >>>>>> with that. Any other thoughts would be appreciated but I could be happy >>>>>> with resourcePath. >>>>>> >>>>>> On Apr 16, 2013, at 7:55 AM, Lucas Holmquist <lholmqui(a)redhat.com&gt; >>>>>> wrote: >>>>>> >>>>>> +1 to resourcePath . it beats my thought of >>>>>> "superawesomenestedresourcethingy" >>>>>> On Apr 16, 2013, at 8:39 AM, Christos Vasilakis <cvasilak(a)gmail.com&gt; >>>>>> wrote: >>>>>> >>>>>> +1 >>>>>> >>>>>> I think it describes the feature better. >>>>>> >>>>>> >>>>>> On Apr 16, 2013, at 3:09 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; >>>>>> wrote: >>>>>> >>>>>> +1 on the "resourcePath", you nailed it ! >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Apr 16, 2013 at 2:03 PM, Kris Borchers <kris(a)redhat.com&gt;wrote: >>>>>> >>>>>>> Hmmm, "nestedResource" isn't terrible but not crazy about "nested" >>>>>>> since they're not necessarily nested but just related. Hmmmmm. >>>>>>> >>>>>>> It's not that I hate resource, I think it kind of makes sense if >>>>>>> you know what we're talking about. How about something like "resourcePath" >>>>>>> to be a little more explicit in what it is? Still not crazy about that but >>>>>>> feel like it's better/closer to something that describes what it is. >>>>>>> >>>>>>> On Apr 16, 2013, at 6:44 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; >>>>>>> wrote: >>>>>>> >>>>>>> Well, there seems to be an agreement on option #1 , except for the >>>>>>> name "resource" , so let's find a name that we all agree on and so we can >>>>>>> going further with this feature. >>>>>>> My propositions: "nestedResource" , "fragment", "nestedURI" ... >>>>>>> But I'm not really fan of all of my propositions ... >>>>>>> Seb >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Apr 11, 2013 at 4:07 PM, Summers Pittman < >>>>>>> supittma(a)redhat.com&gt; wrote: >>>>>>> >>>>>>>> With #1 is `resource` a URI? If so, will developers have to >>>>>>>> build the URI by hand? >>>>>>>> >>>>>>>> >>>>>>>> On 04/10/2013 10:48 AM, Christos Vasilakis wrote: >>>>>>>> >>>>>>>> Hi >>>>>>>> >>>>>>>> I've prepared a document[1] that collectively describes the >>>>>>>> different approaches discussed in this thread for supporting the nested >>>>>>>> resources. It is split in two sections, ones that don't require >>>>>>>> modification to the existing API and ones that do >>>>>>>> >>>>>>>> Please have a look and let me know if I miss sth or interpret >>>>>>>> one approach wrong. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Christos >>>>>>>> >>>>>>>> [1] https://gist.github.com/cvasilak/4a5f51b8d1ad9cc7f21b >>>>>>>> >>>>>>>> On Apr 9, 2013, at 10:19 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hey, >>>>>>>> Like paging, could we start 2 gists : one with a side to side >>>>>>>> techno samples and another one with high level Specs ? I start a bit to get >>>>>>>> lost in this thread :) >>>>>>>> Just one remark when reading the last messages, one "must have" is >>>>>>>> to be able to retrieve all the comments for a post without EVER retrieving >>>>>>>> the post record, so >>>>>>>> /posts/1/comments will retrieve all the comments for post 1 but >>>>>>>> will actually never call posts/1 : in this covered in your last examples ? >>>>>>>> (spec could be : "by-pass parent GET resource" >>>>>>>> Seb >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Apr 9, 2013 at 9:03 AM, Matthias Wessendorf < >>>>>>>> matzew(a)apache.org&gt; wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Apr 8, 2013 at 7:57 PM, Summers Pittman < >>>>>>>>> supittma(a)redhat.com&gt; wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ----- Original Message ----- >>>>>>>>>> | From: "Matthias Wessendorf" <matzew(a)apache.org&gt; >>>>>>>>>> | To: "AeroGear Developer Mailing List" < >>>>>>>>>> aerogear-dev(a)lists.jboss.org&gt; >>>>>>>>>> | Sent: Monday, April 8, 2013 1:22:19 PM >>>>>>>>>> | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for >>>>>>>>>> nested endpoints >>>>>>>>>> | >>>>>>>>>> | OK, with the following server API: >>>>>>>>>> | >>>>>>>>>> | http://some.server.com/posts/1 >>>>>>>>>> | http://some.server.com/posts/1/comments >>>>>>>>>> | (and NO 'comments' collection on the ' >>>>>>>>>> http://some.server.com/posts/1 ' >>>>>>>>>> | response) >>>>>>>>>> | >>>>>>>>>> | Does this (today) 'myPipe.read(1)' already read the specific >>>>>>>>>> comments ( >>>>>>>>>> | http://some.server.com/posts/1/comments ) ?? >>>>>>>>>> | >>>>>>>>>> | ======= JAVA API ======= >>>>>>>>>> | Class Post: >>>>>>>>>> | - string: id; >>>>>>>>>> | - string: title; >>>>>>>>>> | - string: postContent; >>>>>>>>>> | - List<Comment> comments; >>>>>>>>>> | Class Comment: >>>>>>>>>> | - string username; >>>>>>>>>> | - string comment; >>>>>>>>>> | >>>>>>>>>> | Or would the IMPL expect an 'embedded' _comments_ collection >>>>>>>>>> on the response >>>>>>>>>> | of "GET http://some.server.com/posts/1 " ? >>>>>>>>>> >>>>>>>>>> >>>>>>>>> It will not read /posts/1/comments if the Pipe's endpoint is >>>>>>>>>> /posts. If you have a comments collection on the post but no comments data >>>>>>>>>> in the response then the value for getComments will just be null. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Ok - so this needs to be tweaked in Java too, since it's very >>>>>>>>> common to model the REST endpoints like above; >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> | >>>>>>>>>> | >>>>>>>>>> | >>>>>>>>>> | On Mon, Apr 8, 2013 at 7:05 PM, Summers Pittman < >>>>>>>>>> supittma(a)redhat.com > >>>>>>>>>> | wrote: >>>>>>>>>> | >>>>>>>>>> | >>>>>>>>>> | No. The get of pipe 1 would have to include the comments for >>>>>>>>>> get comments to >>>>>>>>>> | work >>>>>>>>>> | >>>>>>>>>> | Sent from my Android phone using TouchDown ( www.nitrodesk.com) >>>>>>>>>> | >>>>>>>>>> | >>>>>>>>>> | -----Original Message----- >>>>>>>>>> | From: Matthias Wessendorf [ matzew(a)apache.org ] >>>>>>>>>> | Received: Monday, 08 Apr 2013, 12:04PM >>>>>>>>>> | To: AeroGear Developer Mailing List [ >>>>>>>>>> aerogear-dev(a)lists.jboss.org ] >>>>>>>>>> | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for >>>>>>>>>> nested endpoints >>>>>>>>>> | >>>>>>>>>> | >>>>>>>>>> | On Mon, Apr 8, 2013 at 5:57 PM, Summers Pittman < >>>>>>>>>> supittma(a)redhat.com > >>>>>>>>>> | wrote: >>>>>>>>>> | >>>>>>>>>> | > >>>>>>>>>> | > >>>>>>>>>> | > ----- Original Message ----- >>>>>>>>>> | > | From: "Matthias Wessendorf" < matzew(a)apache.org > >>>>>>>>>> | > | To: "AeroGear Developer Mailing List" < >>>>>>>>>> aerogear-dev(a)lists.jboss.org > >>>>>>>>>> | > | Sent: Monday, April 8, 2013 10:28:46 AM >>>>>>>>>> | > | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support >>>>>>>>>> for nested >>>>>>>>>> | > endpoints >>>>>>>>>> | > | >>>>>>>>>> | > | or, like before said - reading "lists" (e.g. all the >>>>>>>>>> comments for >>>>>>>>>> | > specific >>>>>>>>>> | > | blog post): >>>>>>>>>> | > | https://gist.github.com/matzew/04f069dfbed2cc77a8b4 >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | For Java.... I guess...... resolving this URL: >>>>>>>>>> | > | http://some.server.com/posts/1/comments >>>>>>>>>> | > | >>>>>>>>>> | > | could be done with this - right ? >>>>>>>>>> | > | >>>>>>>>>> | > | ======= >>>>>>>>>> | > | Class Post: >>>>>>>>>> | > | - string: title; >>>>>>>>>> | > | - string: postContent; >>>>>>>>>> | > | - List<Comment> comments; >>>>>>>>>> | > | Class Comment: >>>>>>>>>> | > | - string username; >>>>>>>>>> | > | - string comment; >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | // get all the comments for 1: >>>>>>>>>> | > | Post myPostOne = postPipe.read("1"); >>>>>>>>>> | > | myPostOne.getComments(); >>>>>>>>>> | > | >>>>>>>>>> | > | // get all the comments for 2: >>>>>>>>>> | > | Post myPostTwo = postPipe.read("2"); >>>>>>>>>> | > | myPostTwo.getComments(); >>>>>>>>>> | > | ======= >>>>>>>>>> | > >>>>>>>>>> | > It can be done with that yes. My concern was more when we >>>>>>>>>> had a Pipe of >>>>>>>>>> | > type <Post> and a readForResource(String property) method. >>>>>>>>>> | >>>>>>>>>> | >>>>>>>>>> | Ok - one more question >>>>>>>>>> | >>>>>>>>>> | >>>>>>>>>> | So... when doing: myPipe.read(1); does that "only" issue a GET >>>>>>>>>> against the ' >>>>>>>>>> | http://some.server.com/posts/1 ' resource? >>>>>>>>>> | >>>>>>>>>> | A second get, for the comments collection is than issued when >>>>>>>>>> calling >>>>>>>>>> | myPostOne.getComments();? >>>>>>>>>> | (GET against ' http://some.server.com/posts/1/comments' )? >>>>>>>>>> | >>>>>>>>>> | >>>>>>>>>> | >>>>>>>>>> | >>>>>>>>>> | > The type information of the property isn't available unless >>>>>>>>>> we can infer >>>>>>>>>> | > it from the Post object. >>>>>>>>>> | > >>>>>>>>>> | >>>>>>>>>> | >>>>>>>>>> | >>>>>>>>>> | >>>>>>>>>> | >>>>>>>>>> | > >>>>>>>>>> | > >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | Greetings, >>>>>>>>>> | > | Matthias >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | On Fri, Apr 5, 2013 at 2:37 PM, Matthias Wessendorf < >>>>>>>>>> matzew(a)apache.org > >>>>>>>>>> | > | wrote: >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | Thought a bit more about it and chatted with friends, >>>>>>>>>> | > | >>>>>>>>>> | > | the issue with the sub pipes is: it adds state and is >>>>>>>>>> perhaps an API >>>>>>>>>> | > | construct that is a bit hard to understand (see all the >>>>>>>>>> discussions here) >>>>>>>>>> | > | >>>>>>>>>> | > | Not sure - but currently we can access "kid resources", >>>>>>>>>> with our API - >>>>>>>>>> | > right >>>>>>>>>> | > | ? >>>>>>>>>> | > | >>>>>>>>>> | > | https://gist.github.com/matzew/6ab432e437b9a017a21d >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | Perhaps it's better to just keep it that way? This has the >>>>>>>>>> benefit of >>>>>>>>>> | > using >>>>>>>>>> | > | an established and know API, the different pipes are >>>>>>>>>> accessible via the >>>>>>>>>> | > | pipeline object; >>>>>>>>>> | > | >>>>>>>>>> | > | And the code is not too much code; it's simply an explicit >>>>>>>>>> pipe ... >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | On Fri, Apr 5, 2013 at 10:56 AM, Matthias Wessendorf < >>>>>>>>>> matzew(a)apache.org >>>>>>>>>> | > | > >>>>>>>>>> | > | wrote: >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | On Fri, Apr 5, 2013 at 10:52 AM, Sebastien Blanc < >>>>>>>>>> scm.blanc(a)gmail.com > >>>>>>>>>> | > | wrote: >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | On Fri, Apr 5, 2013 at 10:36 AM, Matthias Wessendorf < >>>>>>>>>> matzew(a)apache.org >>>>>>>>>> | > | > >>>>>>>>>> | > | wrote: >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | On Fri, Apr 5, 2013 at 10:14 AM, Christos Vasilakis < >>>>>>>>>> cvasilak(a)gmail.com >>>>>>>>>> | > | > >>>>>>>>>> | > | wrote: >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | Hi >>>>>>>>>> | > | >>>>>>>>>> | > | some comments >>>>>>>>>> | > | >>>>>>>>>> | > | I believe the method can't be used since you don't know >>>>>>>>>> the team for the >>>>>>>>>> | > | players so you can't retrieve the pipe directly..right? >>>>>>>>>> | > | >>>>>>>>>> | > | Isn't that really up to the impl of the rest service? >>>>>>>>>> | > | They could return a list of teamsHePlayed for; >>>>>>>>>> | > | >>>>>>>>>> | > | So, let's not tie this API to a specific, not existing >>>>>>>>>> RESTful service; >>>>>>>>>> | > | >>>>>>>>>> | > | +1, we don't need to care about that, we must just focus >>>>>>>>>> on how we can >>>>>>>>>> | > | declare and call nested pipes. >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | yep >>>>>>>>>> | > | >>>>>>>>>> | > | I guess this is perhaps the closest we can come to : >>>>>>>>>> | > | >>>>>>>>>> | > | id<AGPipe> allOwnersInNewYorkPipe = [leaguesPipe subPipe:@ >>>>>>>>>> "owners" >>>>>>>>>> | > | for:@"newyork"]; >>>>>>>>>> | > | >>>>>>>>>> | > | and than.... on the 'leaguesPipe' you can access its kids >>>>>>>>>> with something >>>>>>>>>> | > like >>>>>>>>>> | > | : >>>>>>>>>> | > | >>>>>>>>>> | > | NSArray* kids = [leaguesPipe subPipes]; >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | However, that adds some state to a specific pipe object >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | -M >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | getPlayers ( Callback < List < Player >> callback ) { >>>>>>>>>> | > | pipe . get ( "player" ). read ( callback ); >>>>>>>>>> | > | } >>>>>>>>>> | > | >>>>>>>>>> | > | Further my questions is, how is a third (or arbitrary) >>>>>>>>>> nested resources >>>>>>>>>> | > are >>>>>>>>>> | > | supported? I mean for a url schema like this >>>>>>>>>> | > | >>>>>>>>>> | > | soccer.org/leagues/ {id}/teams/{id}/players/{id} >>>>>>>>>> | > | >>>>>>>>>> | > | first we access the leagues: >>>>>>>>>> | > | --- >>>>>>>>>> | > | getLeagues(Callback<List<Leagues>> callback) { >>>>>>>>>> | > | pipe.get("leagues").read(callback); >>>>>>>>>> | > | } >>>>>>>>>> | > | --- >>>>>>>>>> | > | then the teams for this league: >>>>>>>>>> | > | --- >>>>>>>>>> | > | getTeamsOnLeaque(Leaque league, Callback<List<Team>> >>>>>>>>>> callback) { >>>>>>>>>> | > | pipe.junction("league","team").read(leaque, callback); >>>>>>>>>> | > | } >>>>>>>>>> | > | --- >>>>>>>>>> | > | ..and then we access the "Players" for a "Team": >>>>>>>>>> | > | --- >>>>>>>>>> | > | getPlayersOnTeam(Team team, Callback<List<Player>> >>>>>>>>>> callback) { >>>>>>>>>> | > | pipe.junction("team","player").read(team, callback); >>>>>>>>>> | > | } >>>>>>>>>> | > | --- >>>>>>>>>> | > | But where is the "League" information to fill the >>>>>>>>>> "/leagues/{id}..." >>>>>>>>>> | > path? >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | I'd assume the information is 'inherited' out of a given >>>>>>>>>> pipe, when >>>>>>>>>> | > doing the >>>>>>>>>> | > | 'join' >>>>>>>>>> | > | >>>>>>>>>> | > | e.g. like >>>>>>>>>> | > | myTeamsForLeaguePipe = leaguePipe.junction("team"); >>>>>>>>>> | > | >>>>>>>>>> | > | not sure... >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | Unless you mean something like: >>>>>>>>>> | > | --- >>>>>>>>>> | > | getPlayersOnTeam(Leaque league, Team team, >>>>>>>>>> Callback<List<Player>> >>>>>>>>>> | > callback) { >>>>>>>>>> | > | pipe.junction("league", "team","player").read(league, >>>>>>>>>> team, callback); >>>>>>>>>> | > | } >>>>>>>>>> | > | >>>>>>>>>> | > | I am not sure if that is really easy to understand/use >>>>>>>>>> | > | >>>>>>>>>> | > | Yes and the term "junction" is a bit confusing as it don't >>>>>>>>>> express >>>>>>>>>> | > explicitly >>>>>>>>>> | > | a parent/child relation. >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | --- >>>>>>>>>> | > | >>>>>>>>>> | > | probably I am missing sth.. >>>>>>>>>> | > | >>>>>>>>>> | > | Thanks, >>>>>>>>>> | > | Christos >>>>>>>>>> | > | >>>>>>>>>> | > | On Apr 4, 2013, at 5:52 PM, Summers Pittman < >>>>>>>>>> supittma(a)redhat.com > >>>>>>>>>> | > wrote: >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | What if we create a new metaphor, a Junction. >>>>>>>>>> | > | >>>>>>>>>> | > | https://gist.github.com/secondsun/dcf5682b6ff17c729d9a >>>>>>>>>> | > | >>>>>>>>>> | > | It joins two pipes together and can be used over and over >>>>>>>>>> again with >>>>>>>>>> | > | different data? >>>>>>>>>> | > | It isn't a Pipe though, but perhaps that could be changed >>>>>>>>>> to look more >>>>>>>>>> | > like >>>>>>>>>> | > | Christos's previous example. >>>>>>>>>> | > | >>>>>>>>>> | > | At the very least I like the words "junction" or "join" >>>>>>>>>> more than "of" >>>>>>>>>> | > | >>>>>>>>>> | > | ----- Original Message ----- >>>>>>>>>> | > | | From: "Christos Vasilakis" < cvasilak(a)gmail.com > >>>>>>>>>> | > | | To: "AeroGear Developer Mailing List" < >>>>>>>>>> aerogear-dev(a)lists.jboss.org > >>>>>>>>>> | > | | Sent: Wednesday, April 3, 2013 3:03:02 AM >>>>>>>>>> | > | | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support >>>>>>>>>> for nested >>>>>>>>>> | > | | endpoints >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | On Apr 2, 2013, at 4:03 PM, Matthias Wessendorf < >>>>>>>>>> matzew(a)apache.org > >>>>>>>>>> | > | | wrote: >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | Two thoughts.... >>>>>>>>>> | > | | >>>>>>>>>> | > | | 1) the 'original' leaguesPipe has no clue about the >>>>>>>>>> subpipes, right ? >>>>>>>>>> | > | | 2) should a pipe offer a 'getter' for all it's sub pipes >>>>>>>>>> ? >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | Just a thought is instead of using Pipe, to continue >>>>>>>>>> using Pipeline >>>>>>>>>> | > adding >>>>>>>>>> | > | | an >>>>>>>>>> | > | | extra parameter " of" for specifying the parent : E.g.: >>>>>>>>>> | > | | >>>>>>>>>> | > | | ….. >>>>>>>>>> | > | | id<AGPipe> leaguesPipe = [pipeline pipe@"leagues"]; >>>>>>>>>> | > | | >>>>>>>>>> | > | | id<AGPipe> allTeamsInSeattlePipe = [pipeline subPipe@"teams" >>>>>>>>>> of >>>>>>>>>> | > | | :leaguesPipe >>>>>>>>>> | > | | for:@"seattle"] >>>>>>>>>> | > | | >>>>>>>>>> | > | | id<AGPipe> allPlayersInTrebuchetPipe = [pipeline >>>>>>>>>> subPipe:@"players" >>>>>>>>>> | > of: >>>>>>>>>> | > | | allTeamsInSeattlePipe for:@"trebuchet"]; >>>>>>>>>> | > | | ….. >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | Wdyt? >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | -M >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | Thanks, >>>>>>>>>> | > | | Christos >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | soccer.org/leagues/seattle/teams/trebuchet/players/foo- > >>>>>>>>>> | > | | [[pipeline pipe:@"players" pathParams:@[@"seattle", >>>>>>>>>> @"trebuchet"]] >>>>>>>>>> | > read >>>>>>>>>> | > | | :@"foo"] .. >>>>>>>>>> | > | | ----- >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | Wdyt? >>>>>>>>>> | > | | >>>>>>>>>> | > | | Thanks >>>>>>>>>> | > | | Christos >>>>>>>>>> | > | | >>>>>>>>>> | > | | On Mar 18, 2013, at 1:12 PM, Sebastien Blanc < >>>>>>>>>> scm.blanc(a)gmail.com > >>>>>>>>>> | > wrote: >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | Well, that would not be possible, for that you will have >>>>>>>>>> to create a >>>>>>>>>> | > | | "child" >>>>>>>>>> | > | | pipe. But I agree, that is maybe no optimal ... >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | On Fri, Mar 15, 2013 at 6:44 PM, Summers Pittman < >>>>>>>>>> supittma(a)redhat.com >>>>>>>>>> | > | | > >>>>>>>>>> | > | | wrote: >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | On 03/15/2013 01:34 PM, Sebastien Blanc wrote: >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | I like the idea but I will more see that has a >>>>>>>>>> method/function for the >>>>>>>>>> | > | | pipelineManager (and will be easier to implement in JS, >>>>>>>>>> I think) : >>>>>>>>>> | > | | >>>>>>>>>> | > | | var myParentPipe = >>>>>>>>>> | > Aerogear.Pipeline({name:"parentPipe"}).pipes.parentPipe >>>>>>>>>> | > | | >>>>>>>>>> | > | | var myChildPipe = >>>>>>>>>> Aerogear.Pipeline.fromParent(myParentPipe, {options} >>>>>>>>>> | > ) >>>>>>>>>> | > | | What would it look like to get a child record from a >>>>>>>>>> parent? >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | On Fri, Mar 15, 2013 at 5:37 PM, Douglas Campos < >>>>>>>>>> qmx(a)qmx.me > wrote: >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | What about this? >>>>>>>>>> | > | | >>>>>>>>>> | > | | Pipeline<Post> postPipeline = … >>>>>>>>>> | > | | Post post = // get from the pipeline >>>>>>>>>> | > | | Pipeline<Comment> >>>>>>>>>> | > | | >>>>>>>>>> postPipeline.childPipelineForOrOtherWeirdName(Comment.class, post) >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | On 15/03/2013, at 12:26, Summers Pittman < >>>>>>>>>> supittma(a)redhat.com > >>>>>>>>>> | > wrote: >>>>>>>>>> | > | | >>>>>>>>>> | > | | > On 03/14/2013 04:48 AM, Matthias Wessendorf wrote: >>>>>>>>>> | > | | >> >>>>>>>>>> | > | | >> >>>>>>>>>> | > | | >> On Thu, Mar 14, 2013 at 9:32 AM, Sebastien Blanc < >>>>>>>>>> | > scm.blanc(a)gmail.com > >>>>>>>>>> | > | | >> wrote: >>>>>>>>>> | > | | >> Hi, >>>>>>>>>> | > | | >> While I was playing with scaffolding and tried to >>>>>>>>>> build a simple >>>>>>>>>> | > Blog >>>>>>>>>> | > | | >> Application with Aerogear I faced the current >>>>>>>>>> situation : >>>>>>>>>> | > | | >> I have a Post object which contains many Comment >>>>>>>>>> objects. Now I >>>>>>>>>> | > want to >>>>>>>>>> | > | | >> call my Post pipe to retrieve the related comments, I >>>>>>>>>> have >>>>>>>>>> | > currently 2 >>>>>>>>>> | > | | >> options : >>>>>>>>>> | > | | >> >>>>>>>>>> | > | | >> /posts/1 -> assuming comments will be implicitly >>>>>>>>>> retrieved (eager >>>>>>>>>> | > | | >> loading) >>>>>>>>>> | > | | >> /comments/?postid=1 >>>>>>>>>> | > | | >> >>>>>>>>>> | > | | >> But regarding our model the correct form should be : >>>>>>>>>> | > | | >> >>>>>>>>>> | > | | >> /posts/1/comments >>>>>>>>>> | > | | >> >>>>>>>>>> | > | | >> >>>>>>>>>> | > | | >> +1 >>>>>>>>>> | > | | >> that is the ideal way to model URIs for "nested" >>>>>>>>>> resources. >>>>>>>>>> | > | | >> >>>>>>>>>> | > | | >> See [1], extracted from [2] >>>>>>>>>> | > | | >> >>>>>>>>>> | > | | >> >>>>>>>>>> | > | | >> >>>>>>>>>> | > | | >> But, AFAIK, with the current API, it is not possible >>>>>>>>>> to define this >>>>>>>>>> | > last >>>>>>>>>> | > | | >> pattern (at least for JS and iOs, confirmed by >>>>>>>>>> Matzew). When doing a >>>>>>>>>> | > | | >> read >>>>>>>>>> | > | | >> we can pass an id option but as mentioned in the doc, >>>>>>>>>> this id will >>>>>>>>>> | > | | >> always >>>>>>>>>> | > | | >> be append to the endpoint. >>>>>>>>>> | > | | >> >>>>>>>>>> | > | | >> >>>>>>>>>> | > | | >> Well, it is possible - but in a very (IMO) ugly way: >>>>>>>>>> | > | | >> >>>>>>>>>> | > | | >> https://gist.github.com/matzew/6ab432e437b9a017a21d >>>>>>>>>> | > | | >> >>>>>>>>>> | > | | >> >>>>>>>>>> | > | | >> >>>>>>>>>> | > | | >> >>>>>>>>>> | > | | >> IMO, we should be able to support this pattern but >>>>>>>>>> for now I'm not >>>>>>>>>> | > | | >> really >>>>>>>>>> | > | | >> sure how to specify this in our API, so if you have >>>>>>>>>> any ideas >>>>>>>>>> | > feedback >>>>>>>>>> | > | | >> this thread has been made for you ! >>>>>>>>>> | > | | >> >>>>>>>>>> | > | | >> >>>>>>>>>> | > | | >> >>>>>>>>>> | > | | >> Suggestion: Enhance the read function - example: >>>>>>>>>> | > | | >> >>>>>>>>>> | > | | >> https://gist.github.com/matzew/04f069dfbed2cc77a8b4 >>>>>>>>>> | > | | > I'm thinking of the inverse myself. Add a "ParentPath" >>>>>>>>>> property >>>>>>>>>> | > which can >>>>>>>>>> | > | | > be used to extract information from parent objects. >>>>>>>>>> | > | | > >>>>>>>>>> | > | | > https://gist.github.com/secondsun/17ce96082eda37dbd10e >>>>>>>>>> | > | | > >>>>>>>>>> | > | | >> >>>>>>>>>> | > | | >> >>>>>>>>>> | > | | >> -Matthias >>>>>>>>>> | > | | >> >>>>>>>>>> | > | | >> >>>>>>>>>> | > | | >> [1] >>>>>>>>>> | > | | >> >>>>>>>>>> | > >>>>>>>>>> http://www.infoq.com/resource/articles/rest-introduction/en/resources/fig... >>>>>>>>>> | > | | >> [2] http://www.infoq.com/articles/rest-introduction >>>>>>>>>> | > | | >> >>>>>>>>>> | > | | >> >>>>>>>>>> | > | | >> >>>>>>>>>> | > | | >> >>>>>>>>>> | > | | >> Seb >>>>>>>>>> | > | | >> >>>>>>>>>> | > | | >> >>>>>>>>>> | > | | >> _______________________________________________ >>>>>>>>>> | > | | >> aerogear-dev mailing list >>>>>>>>>> | > | | >> aerogear-dev(a)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 >>>>>>>>>> | > | | >> >>>>>>>>>> | > | | >> _______________________________________________ >>>>>>>>>> | > | | >> aerogear-dev mailing list >>>>>>>>>> | > | | >> >>>>>>>>>> | > | | >> aerogear-dev(a)lists.jboss.org >>>>>>>>>> | > | | >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>> | > | | > >>>>>>>>>> | > | | > _______________________________________________ >>>>>>>>>> | > | | > aerogear-dev mailing list >>>>>>>>>> | > | | > aerogear-dev(a)lists.jboss.org >>>>>>>>>> | > | | > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>> | > | | >>>>>>>>>> | > | | -- qmx >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | _______________________________________________ >>>>>>>>>> | > | | aerogear-dev mailing list >>>>>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | _______________________________________________ >>>>>>>>>> | > | | aerogear-dev mailing list aerogear-dev(a)lists.jboss.org >>>>>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | _______________________________________________ >>>>>>>>>> | > | | aerogear-dev mailing list >>>>>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>> | > | | >>>>>>>>>> | > | | _______________________________________________ >>>>>>>>>> | > | | aerogear-dev mailing list >>>>>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | _______________________________________________ >>>>>>>>>> | > | | aerogear-dev mailing list >>>>>>>>>> | > | | aerogear-dev(a)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 >>>>>>>>>> | > | | _______________________________________________ >>>>>>>>>> | > | | aerogear-dev mailing list >>>>>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | _______________________________________________ >>>>>>>>>> | > | | aerogear-dev mailing list >>>>>>>>>> | > | | aerogear-dev(a)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 >>>>>>>>>> | > | | _______________________________________________ >>>>>>>>>> | > | | aerogear-dev mailing list >>>>>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>> | > | | >>>>>>>>>> | > | | >>>>>>>>>> | > | | _______________________________________________ >>>>>>>>>> | > | | aerogear-dev mailing list >>>>>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>> | > | >>>>>>>>>> | > | _______________________________________________ >>>>>>>>>> | > | aerogear-dev mailing list >>>>>>>>>> | > | aerogear-dev(a)lists.jboss.org >>>>>>>>>> | > | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | _______________________________________________ >>>>>>>>>> | > | aerogear-dev mailing list >>>>>>>>>> | > | aerogear-dev(a)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 >>>>>>>>>> | > | >>>>>>>>>> | > | _______________________________________________ >>>>>>>>>> | > | aerogear-dev mailing list >>>>>>>>>> | > | aerogear-dev(a)lists.jboss.org >>>>>>>>>> | > | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | _______________________________________________ >>>>>>>>>> | > | aerogear-dev mailing list >>>>>>>>>> | > | aerogear-dev(a)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 >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | -- >>>>>>>>>> | > | Matthias Wessendorf >>>>>>>>>> | > | >>>>>>>>>> | > | blog: http://matthiaswessendorf.wordpress.com/ >>>>>>>>>> | > | sessions: http://www.slideshare.net/mwessendorf >>>>>>>>>> | > | twitter: http://twitter.com/mwessendorf >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | >>>>>>>>>> | > | -- >>>>>>>>>> | > | Matthias Wessendorf >>>>>>>>>> | > | >>>>>>>>>> | > | blog: http://matthiaswessendorf.wordpress.com/ >>>>>>>>>> | > | sessions: http://www.slideshare.net/mwessendorf >>>>>>>>>> | > | twitter: http://twitter.com/mwessendorf >>>>>>>>>> | > | >>>>>>>>>> | > | _______________________________________________ >>>>>>>>>> | > | aerogear-dev mailing list >>>>>>>>>> | > | aerogear-dev(a)lists.jboss.org >>>>>>>>>> | > | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>> | > >>>>>>>>>> | > _______________________________________________ >>>>>>>>>> | > aerogear-dev mailing list >>>>>>>>>> | > aerogear-dev(a)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 >>>>>>>>>> | >>>>>>>>>> | _______________________________________________ >>>>>>>>>> | aerogear-dev mailing list >>>>>>>>>> | aerogear-dev(a)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 >>>>>>>>>> | >>>>>>>>>> | _______________________________________________ >>>>>>>>>> | aerogear-dev mailing list >>>>>>>>>> | aerogear-dev(a)lists.jboss.org >>>>>>>>>> | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> aerogear-dev mailing list >>>>>>>>>> aerogear-dev(a)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 >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> aerogear-dev mailing list >>>>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing list >>>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing listaerogear-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing list >>>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Totally agree :) but if you want to do what you suggest without using nested resources ( just delete(5) ) you must create a complete Pipe just for "/post/2/comments" which is also not acceptable, we need to find aother of doing it. On Tue, Apr 30, 2013 at 9:56 AM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: > > > > On Tue, Apr 30, 2013 at 9:53 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt;wrote: > >> Yes , i.e a common use case, we want to delete comment with id 5 from >> blog post with id 2 : >> >> DELETE /post/2/comment/5 >> >> With the nested endpoints has we have defined it will be something like >> : >> >> pipe.remove( 2 , >> { >> resourcePath:"comment/5" >> } >> ); >> >> Which is indeed not crystal clear. But in the same time we really need >> to provide a solution. >> We could maybe introduce a "resourcePathId" ? >> >> pipe.remove( 2 , >> { >> resourcePath: "comment", >> resourcePathId: 5 >> } >> ); >> >> But that would only make sense for a "one level" nested resource ... >> > > > For me, that all reads "delete 2" :) > > Not sure, but currently, that is more obvious (e.g. when you have a pipe > against "/post/2/comments", you just say delete(5);) > > > -Matthias > > > >> >> >> >> On Tue, Apr 30, 2013 at 9:43 AM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: >> >>> >>> >>> >>> On Tue, Apr 23, 2013 at 2:38 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >>> >>>> This is the same issue I pointed out this morning on Sebi's >>>> implementation. I need to think more about a solution. >>>> >>> >>> >>> I agree that the 'save' and the 'remove' are a bit weird (hard to >>> understand). >>> >>> -Matthias >>> >>> >>> >>>> >>>> On Apr 23, 2013, at 7:33 AM, Christos Vasilakis <cvasilak(a)gmail.com&gt; >>>> wrote: >>>> >>>> Hi, >>>> >>>> as I implement the iOS support for nested paths, and in particular >>>> 'save' and 'remove' a situation arises. >>>> >>>> Consider the 'save' operation for a new team in the following path >>>> (a pipe has been instantiated that points to 'leagues') : >>>> >>>> soccer.org/leagues/foo/teams >>>> >>>> To save a new team, the user must: >>>> >>>> [leaguesPipe save:teamObject resourcePath:"/foo/teams"] >>>> >>>> Notice that now, we NEED to pass the id of the league in the >>>> resourcePath for this to work("foo"). >>>> >>>> To update an existing team, the user must: >>>> >>>> [leaguesPipe save:teamObject resourcePath:"/foo/teams"] >>>> >>>> Again the id of the leagues needs to be passed on the resourcePath >>>> >>>> NOTE: For the update to work, teamObject is implied to have the >>>> config.id set (here we assume that the teamObject has similar >>>> config_id name with league for this to work ??) >>>> >>>> Similar for remove: >>>> >>>> [leaguesPipe remove:teamObject resourcePath:"/foo/teams"] >>>> >>>> So, for cases of 'save' and 'remove', the resourcePath endpoint with >>>> the Pipe id SET must come first, and then we append the object's endpoint. >>>> >>>> Thoughts? >>>> >>>> Thanks >>>> Christos >>>> >>>> On Apr 18, 2013, at 6:39 PM, Daniel Bevenius < >>>> daniel.bevenius(a)gmail.com&gt; wrote: >>>> >>>> Yeah, I'm all for 'resourcePath' now that I'm not as confused anymore >>>> :) >>>> >>>> >>>> On 18 April 2013 17:37, Christos Vasilakis <cvasilak(a)gmail.com&gt; wrote: >>>> >>>>> I think If no alternative comes along, let's stick to 'resourcePath' >>>>> for now.. >>>>> >>>>> >>>>> On Apr 18, 2013, at 6:23 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; >>>>> wrote: >>>>> >>>>> So we all agreed on "resourcePath" ? >>>>> >>>>> >>>>> >>>>> On Thu, Apr 18, 2013 at 4:54 PM, Christos Vasilakis < >>>>> cvasilak(a)gmail.com&gt; wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> have created the epic to track this, feel free to edit >>>>>> >>>>>> https://issues.jboss.org/browse/AEROGEAR-1123 >>>>>> >>>>>> - >>>>>> Christos >>>>>> >>>>>> On Apr 16, 2013, at 4:23 PM, Daniel Bevenius < >>>>>> daniel.bevenius(a)gmail.com&gt; wrote: >>>>>> >>>>>> doh! Sorry. I was just looking at the first examples in the gist and >>>>>> did not realize these could have multiple segments. >>>>>> >>>>>> >>>>>> On 16 April 2013 15:18, Kris Borchers <kris(a)redhat.com&gt; wrote: >>>>>> >>>>>>> Hmm, I like the idea of looking to standards but if I'm reading it >>>>>>> right, segment there means just a portion of the URI between slashes, not >>>>>>> multiple slash-separated segments. >>>>>>> >>>>>>> On Apr 16, 2013, at 8:14 AM, Daniel Bevenius < >>>>>>> daniel.bevenius(a)gmail.com&gt; wrote: >>>>>>> >>>>>>> I agree, when I read resourcePath I read that as a path to >>>>>>> resource. How about pathSegment or segment as used by >>>>>>> http://tools.ietf.org/html/rfc3986#section-3.3 ? >>>>>>> >>>>>>> >>>>>>> On 16 April 2013 15:12, Kris Borchers <kris(a)redhat.com&gt; wrote: >>>>>>> >>>>>>>> My only issue with resourcePath is that it doesn't imply that the >>>>>>>> path is relative to the current pipe. I mean, it should be implied since >>>>>>>> you're already working with a pipe and we can be explicit about that in >>>>>>>> documentation but I still wish it was somehow in the name. I think that was >>>>>>>> the goal of using "nested" in the name but I already expressed my issue >>>>>>>> with that. Any other thoughts would be appreciated but I could be happy >>>>>>>> with resourcePath. >>>>>>>> >>>>>>>> On Apr 16, 2013, at 7:55 AM, Lucas Holmquist <lholmqui(a)redhat.com&gt; >>>>>>>> wrote: >>>>>>>> >>>>>>>> +1 to resourcePath . it beats my thought of >>>>>>>> "superawesomenestedresourcethingy" >>>>>>>> On Apr 16, 2013, at 8:39 AM, Christos Vasilakis < >>>>>>>> cvasilak(a)gmail.com&gt; wrote: >>>>>>>> >>>>>>>> +1 >>>>>>>> >>>>>>>> I think it describes the feature better. >>>>>>>> >>>>>>>> >>>>>>>> On Apr 16, 2013, at 3:09 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; >>>>>>>> wrote: >>>>>>>> >>>>>>>> +1 on the "resourcePath", you nailed it ! >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Apr 16, 2013 at 2:03 PM, Kris Borchers <kris(a)redhat.com&gt;wrote: >>>>>>>> >>>>>>>>> Hmmm, "nestedResource" isn't terrible but not crazy about >>>>>>>>> "nested" since they're not necessarily nested but just related. Hmmmmm. >>>>>>>>> >>>>>>>>> It's not that I hate resource, I think it kind of makes sense if >>>>>>>>> you know what we're talking about. How about something like "resourcePath" >>>>>>>>> to be a little more explicit in what it is? Still not crazy about that but >>>>>>>>> feel like it's better/closer to something that describes what it is. >>>>>>>>> >>>>>>>>> On Apr 16, 2013, at 6:44 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Well, there seems to be an agreement on option #1 , except for >>>>>>>>> the name "resource" , so let's find a name that we all agree on and so we >>>>>>>>> can going further with this feature. >>>>>>>>> My propositions: "nestedResource" , "fragment", "nestedURI" ... >>>>>>>>> But I'm not really fan of all of my propositions ... >>>>>>>>> Seb >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Apr 11, 2013 at 4:07 PM, Summers Pittman < >>>>>>>>> supittma(a)redhat.com&gt; wrote: >>>>>>>>> >>>>>>>>>> With #1 is `resource` a URI? If so, will developers have to >>>>>>>>>> build the URI by hand? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 04/10/2013 10:48 AM, Christos Vasilakis wrote: >>>>>>>>>> >>>>>>>>>> Hi >>>>>>>>>> >>>>>>>>>> I've prepared a document[1] that collectively describes the >>>>>>>>>> different approaches discussed in this thread for supporting the nested >>>>>>>>>> resources. It is split in two sections, ones that don't require >>>>>>>>>> modification to the existing API and ones that do >>>>>>>>>> >>>>>>>>>> Please have a look and let me know if I miss sth or interpret >>>>>>>>>> one approach wrong. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Christos >>>>>>>>>> >>>>>>>>>> [1] https://gist.github.com/cvasilak/4a5f51b8d1ad9cc7f21b >>>>>>>>>> >>>>>>>>>> On Apr 9, 2013, at 10:19 AM, Sebastien Blanc < >>>>>>>>>> scm.blanc(a)gmail.com&gt; wrote: >>>>>>>>>> >>>>>>>>>> Hey, >>>>>>>>>> Like paging, could we start 2 gists : one with a side to side >>>>>>>>>> techno samples and another one with high level Specs ? I start a bit to get >>>>>>>>>> lost in this thread :) >>>>>>>>>> Just one remark when reading the last messages, one "must have" >>>>>>>>>> is to be able to retrieve all the comments for a post without EVER >>>>>>>>>> retrieving the post record, so >>>>>>>>>> /posts/1/comments will retrieve all the comments for post 1 but >>>>>>>>>> will actually never call posts/1 : in this covered in your last examples ? >>>>>>>>>> (spec could be : "by-pass parent GET resource" >>>>>>>>>> Seb >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Apr 9, 2013 at 9:03 AM, Matthias Wessendorf < >>>>>>>>>> matzew(a)apache.org&gt; wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Mon, Apr 8, 2013 at 7:57 PM, Summers Pittman < >>>>>>>>>>> supittma(a)redhat.com&gt; wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>> | From: "Matthias Wessendorf" <matzew(a)apache.org&gt; >>>>>>>>>>>> | To: "AeroGear Developer Mailing List" < >>>>>>>>>>>> aerogear-dev(a)lists.jboss.org&gt; >>>>>>>>>>>> | Sent: Monday, April 8, 2013 1:22:19 PM >>>>>>>>>>>> | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for >>>>>>>>>>>> nested endpoints >>>>>>>>>>>> | >>>>>>>>>>>> | OK, with the following server API: >>>>>>>>>>>> | >>>>>>>>>>>> | http://some.server.com/posts/1 >>>>>>>>>>>> | http://some.server.com/posts/1/comments >>>>>>>>>>>> | (and NO 'comments' collection on the ' >>>>>>>>>>>> http://some.server.com/posts/1 ' >>>>>>>>>>>> | response) >>>>>>>>>>>> | >>>>>>>>>>>> | Does this (today) 'myPipe.read(1)' already read the specific >>>>>>>>>>>> comments ( >>>>>>>>>>>> | http://some.server.com/posts/1/comments ) ?? >>>>>>>>>>>> | >>>>>>>>>>>> | ======= JAVA API ======= >>>>>>>>>>>> | Class Post: >>>>>>>>>>>> | - string: id; >>>>>>>>>>>> | - string: title; >>>>>>>>>>>> | - string: postContent; >>>>>>>>>>>> | - List<Comment> comments; >>>>>>>>>>>> | Class Comment: >>>>>>>>>>>> | - string username; >>>>>>>>>>>> | - string comment; >>>>>>>>>>>> | >>>>>>>>>>>> | Or would the IMPL expect an 'embedded' _comments_ collection >>>>>>>>>>>> on the response >>>>>>>>>>>> | of "GET http://some.server.com/posts/1 " ? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> It will not read /posts/1/comments if the Pipe's endpoint is >>>>>>>>>>>> /posts. If you have a comments collection on the post but no comments data >>>>>>>>>>>> in the response then the value for getComments will just be null. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Ok - so this needs to be tweaked in Java too, since it's very >>>>>>>>>>> common to model the REST endpoints like above; >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> | >>>>>>>>>>>> | >>>>>>>>>>>> | >>>>>>>>>>>> | On Mon, Apr 8, 2013 at 7:05 PM, Summers Pittman < >>>>>>>>>>>> supittma(a)redhat.com > >>>>>>>>>>>> | wrote: >>>>>>>>>>>> | >>>>>>>>>>>> | >>>>>>>>>>>> | No. The get of pipe 1 would have to include the comments for >>>>>>>>>>>> get comments to >>>>>>>>>>>> | work >>>>>>>>>>>> | >>>>>>>>>>>> | Sent from my Android phone using TouchDown ( >>>>>>>>>>>> www.nitrodesk.com ) >>>>>>>>>>>> | >>>>>>>>>>>> | >>>>>>>>>>>> | -----Original Message----- >>>>>>>>>>>> | From: Matthias Wessendorf [ matzew(a)apache.org ] >>>>>>>>>>>> | Received: Monday, 08 Apr 2013, 12:04PM >>>>>>>>>>>> | To: AeroGear Developer Mailing List [ >>>>>>>>>>>> aerogear-dev(a)lists.jboss.org ] >>>>>>>>>>>> | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for >>>>>>>>>>>> nested endpoints >>>>>>>>>>>> | >>>>>>>>>>>> | >>>>>>>>>>>> | On Mon, Apr 8, 2013 at 5:57 PM, Summers Pittman < >>>>>>>>>>>> supittma(a)redhat.com > >>>>>>>>>>>> | wrote: >>>>>>>>>>>> | >>>>>>>>>>>> | > >>>>>>>>>>>> | > >>>>>>>>>>>> | > ----- Original Message ----- >>>>>>>>>>>> | > | From: "Matthias Wessendorf" < matzew(a)apache.org > >>>>>>>>>>>> | > | To: "AeroGear Developer Mailing List" < >>>>>>>>>>>> aerogear-dev(a)lists.jboss.org > >>>>>>>>>>>> | > | Sent: Monday, April 8, 2013 10:28:46 AM >>>>>>>>>>>> | > | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support >>>>>>>>>>>> for nested >>>>>>>>>>>> | > endpoints >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | or, like before said - reading "lists" (e.g. all the >>>>>>>>>>>> comments for >>>>>>>>>>>> | > specific >>>>>>>>>>>> | > | blog post): >>>>>>>>>>>> | > | https://gist.github.com/matzew/04f069dfbed2cc77a8b4 >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | For Java.... I guess...... resolving this URL: >>>>>>>>>>>> | > | http://some.server.com/posts/1/comments >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | could be done with this - right ? >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | ======= >>>>>>>>>>>> | > | Class Post: >>>>>>>>>>>> | > | - string: title; >>>>>>>>>>>> | > | - string: postContent; >>>>>>>>>>>> | > | - List<Comment> comments; >>>>>>>>>>>> | > | Class Comment: >>>>>>>>>>>> | > | - string username; >>>>>>>>>>>> | > | - string comment; >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | // get all the comments for 1: >>>>>>>>>>>> | > | Post myPostOne = postPipe.read("1"); >>>>>>>>>>>> | > | myPostOne.getComments(); >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | // get all the comments for 2: >>>>>>>>>>>> | > | Post myPostTwo = postPipe.read("2"); >>>>>>>>>>>> | > | myPostTwo.getComments(); >>>>>>>>>>>> | > | ======= >>>>>>>>>>>> | > >>>>>>>>>>>> | > It can be done with that yes. My concern was more when we >>>>>>>>>>>> had a Pipe of >>>>>>>>>>>> | > type <Post> and a readForResource(String property) method. >>>>>>>>>>>> | >>>>>>>>>>>> | >>>>>>>>>>>> | Ok - one more question >>>>>>>>>>>> | >>>>>>>>>>>> | >>>>>>>>>>>> | So... when doing: myPipe.read(1); does that "only" issue a >>>>>>>>>>>> GET against the ' >>>>>>>>>>>> | http://some.server.com/posts/1 ' resource? >>>>>>>>>>>> | >>>>>>>>>>>> | A second get, for the comments collection is than issued >>>>>>>>>>>> when calling >>>>>>>>>>>> | myPostOne.getComments();? >>>>>>>>>>>> | (GET against ' http://some.server.com/posts/1/comments' )? >>>>>>>>>>>> | >>>>>>>>>>>> | >>>>>>>>>>>> | >>>>>>>>>>>> | >>>>>>>>>>>> | > The type information of the property isn't available >>>>>>>>>>>> unless we can infer >>>>>>>>>>>> | > it from the Post object. >>>>>>>>>>>> | > >>>>>>>>>>>> | >>>>>>>>>>>> | >>>>>>>>>>>> | >>>>>>>>>>>> | >>>>>>>>>>>> | >>>>>>>>>>>> | > >>>>>>>>>>>> | > >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | Greetings, >>>>>>>>>>>> | > | Matthias >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | On Fri, Apr 5, 2013 at 2:37 PM, Matthias Wessendorf < >>>>>>>>>>>> matzew(a)apache.org > >>>>>>>>>>>> | > | wrote: >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | Thought a bit more about it and chatted with friends, >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | the issue with the sub pipes is: it adds state and is >>>>>>>>>>>> perhaps an API >>>>>>>>>>>> | > | construct that is a bit hard to understand (see all the >>>>>>>>>>>> discussions here) >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | Not sure - but currently we can access "kid resources", >>>>>>>>>>>> with our API - >>>>>>>>>>>> | > right >>>>>>>>>>>> | > | ? >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | https://gist.github.com/matzew/6ab432e437b9a017a21d >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | Perhaps it's better to just keep it that way? This has >>>>>>>>>>>> the benefit of >>>>>>>>>>>> | > using >>>>>>>>>>>> | > | an established and know API, the different pipes are >>>>>>>>>>>> accessible via the >>>>>>>>>>>> | > | pipeline object; >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | And the code is not too much code; it's simply an >>>>>>>>>>>> explicit pipe ... >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | On Fri, Apr 5, 2013 at 10:56 AM, Matthias Wessendorf < >>>>>>>>>>>> matzew(a)apache.org >>>>>>>>>>>> | > | > >>>>>>>>>>>> | > | wrote: >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | On Fri, Apr 5, 2013 at 10:52 AM, Sebastien Blanc < >>>>>>>>>>>> scm.blanc(a)gmail.com > >>>>>>>>>>>> | > | wrote: >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | On Fri, Apr 5, 2013 at 10:36 AM, Matthias Wessendorf < >>>>>>>>>>>> matzew(a)apache.org >>>>>>>>>>>> | > | > >>>>>>>>>>>> | > | wrote: >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | On Fri, Apr 5, 2013 at 10:14 AM, Christos Vasilakis < >>>>>>>>>>>> cvasilak(a)gmail.com >>>>>>>>>>>> | > | > >>>>>>>>>>>> | > | wrote: >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | Hi >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | some comments >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | I believe the method can't be used since you don't know >>>>>>>>>>>> the team for the >>>>>>>>>>>> | > | players so you can't retrieve the pipe directly..right? >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | Isn't that really up to the impl of the rest service? >>>>>>>>>>>> | > | They could return a list of teamsHePlayed for; >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | So, let's not tie this API to a specific, not existing >>>>>>>>>>>> RESTful service; >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | +1, we don't need to care about that, we must just focus >>>>>>>>>>>> on how we can >>>>>>>>>>>> | > | declare and call nested pipes. >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | yep >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | I guess this is perhaps the closest we can come to : >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | id<AGPipe> allOwnersInNewYorkPipe = [leaguesPipe >>>>>>>>>>>> subPipe:@"owners" >>>>>>>>>>>> | > | for:@"newyork"]; >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | and than.... on the 'leaguesPipe' you can access its >>>>>>>>>>>> kids with something >>>>>>>>>>>> | > like >>>>>>>>>>>> | > | : >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | NSArray* kids = [leaguesPipe subPipes]; >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | However, that adds some state to a specific pipe object >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | -M >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | getPlayers ( Callback < List < Player >> callback ) { >>>>>>>>>>>> | > | pipe . get ( "player" ). read ( callback ); >>>>>>>>>>>> | > | } >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | Further my questions is, how is a third (or arbitrary) >>>>>>>>>>>> nested resources >>>>>>>>>>>> | > are >>>>>>>>>>>> | > | supported? I mean for a url schema like this >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | soccer.org/leagues/ {id}/teams/{id}/players/{id} >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | first we access the leagues: >>>>>>>>>>>> | > | --- >>>>>>>>>>>> | > | getLeagues(Callback<List<Leagues>> callback) { >>>>>>>>>>>> | > | pipe.get("leagues").read(callback); >>>>>>>>>>>> | > | } >>>>>>>>>>>> | > | --- >>>>>>>>>>>> | > | then the teams for this league: >>>>>>>>>>>> | > | --- >>>>>>>>>>>> | > | getTeamsOnLeaque(Leaque league, Callback<List<Team>> >>>>>>>>>>>> callback) { >>>>>>>>>>>> | > | pipe.junction("league","team").read(leaque, callback); >>>>>>>>>>>> | > | } >>>>>>>>>>>> | > | --- >>>>>>>>>>>> | > | ..and then we access the "Players" for a "Team": >>>>>>>>>>>> | > | --- >>>>>>>>>>>> | > | getPlayersOnTeam(Team team, Callback<List<Player>> >>>>>>>>>>>> callback) { >>>>>>>>>>>> | > | pipe.junction("team","player").read(team, callback); >>>>>>>>>>>> | > | } >>>>>>>>>>>> | > | --- >>>>>>>>>>>> | > | But where is the "League" information to fill the >>>>>>>>>>>> "/leagues/{id}..." >>>>>>>>>>>> | > path? >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | I'd assume the information is 'inherited' out of a given >>>>>>>>>>>> pipe, when >>>>>>>>>>>> | > doing the >>>>>>>>>>>> | > | 'join' >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | e.g. like >>>>>>>>>>>> | > | myTeamsForLeaguePipe = leaguePipe.junction("team"); >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | not sure... >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | Unless you mean something like: >>>>>>>>>>>> | > | --- >>>>>>>>>>>> | > | getPlayersOnTeam(Leaque league, Team team, >>>>>>>>>>>> Callback<List<Player>> >>>>>>>>>>>> | > callback) { >>>>>>>>>>>> | > | pipe.junction("league", "team","player").read(league, >>>>>>>>>>>> team, callback); >>>>>>>>>>>> | > | } >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | I am not sure if that is really easy to understand/use >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | Yes and the term "junction" is a bit confusing as it >>>>>>>>>>>> don't express >>>>>>>>>>>> | > explicitly >>>>>>>>>>>> | > | a parent/child relation. >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | --- >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | probably I am missing sth.. >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | Thanks, >>>>>>>>>>>> | > | Christos >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | On Apr 4, 2013, at 5:52 PM, Summers Pittman < >>>>>>>>>>>> supittma(a)redhat.com > >>>>>>>>>>>> | > wrote: >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | What if we create a new metaphor, a Junction. >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | https://gist.github.com/secondsun/dcf5682b6ff17c729d9a >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | It joins two pipes together and can be used over and >>>>>>>>>>>> over again with >>>>>>>>>>>> | > | different data? >>>>>>>>>>>> | > | It isn't a Pipe though, but perhaps that could be >>>>>>>>>>>> changed to look more >>>>>>>>>>>> | > like >>>>>>>>>>>> | > | Christos's previous example. >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | At the very least I like the words "junction" or "join" >>>>>>>>>>>> more than "of" >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | ----- Original Message ----- >>>>>>>>>>>> | > | | From: "Christos Vasilakis" < cvasilak(a)gmail.com > >>>>>>>>>>>> | > | | To: "AeroGear Developer Mailing List" < >>>>>>>>>>>> aerogear-dev(a)lists.jboss.org > >>>>>>>>>>>> | > | | Sent: Wednesday, April 3, 2013 3:03:02 AM >>>>>>>>>>>> | > | | Subject: Re: [aerogear-dev] [Aerogear Pipeline] >>>>>>>>>>>> Support for nested >>>>>>>>>>>> | > | | endpoints >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | On Apr 2, 2013, at 4:03 PM, Matthias Wessendorf < >>>>>>>>>>>> matzew(a)apache.org > >>>>>>>>>>>> | > | | wrote: >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | Two thoughts.... >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | 1) the 'original' leaguesPipe has no clue about the >>>>>>>>>>>> subpipes, right ? >>>>>>>>>>>> | > | | 2) should a pipe offer a 'getter' for all it's sub >>>>>>>>>>>> pipes ? >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | Just a thought is instead of using Pipe, to continue >>>>>>>>>>>> using Pipeline >>>>>>>>>>>> | > adding >>>>>>>>>>>> | > | | an >>>>>>>>>>>> | > | | extra parameter " of" for specifying the parent : E.g.: >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | ….. >>>>>>>>>>>> | > | | id<AGPipe> leaguesPipe = [pipeline pipe@"leagues"]; >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | id<AGPipe> allTeamsInSeattlePipe = [pipeline subPipe@"teams" >>>>>>>>>>>> of >>>>>>>>>>>> | > | | :leaguesPipe >>>>>>>>>>>> | > | | for:@"seattle"] >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | id<AGPipe> allPlayersInTrebuchetPipe = [pipeline >>>>>>>>>>>> subPipe:@"players" >>>>>>>>>>>> | > of: >>>>>>>>>>>> | > | | allTeamsInSeattlePipe for:@"trebuchet"]; >>>>>>>>>>>> | > | | ….. >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | Wdyt? >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | -M >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | Thanks, >>>>>>>>>>>> | > | | Christos >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | soccer.org/leagues/seattle/teams/trebuchet/players/foo- > >>>>>>>>>>>> | > | | [[pipeline pipe:@"players" pathParams:@[@"seattle", >>>>>>>>>>>> @"trebuchet"]] >>>>>>>>>>>> | > read >>>>>>>>>>>> | > | | :@"foo"] .. >>>>>>>>>>>> | > | | ----- >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | Wdyt? >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | Thanks >>>>>>>>>>>> | > | | Christos >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | On Mar 18, 2013, at 1:12 PM, Sebastien Blanc < >>>>>>>>>>>> scm.blanc(a)gmail.com > >>>>>>>>>>>> | > wrote: >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | Well, that would not be possible, for that you will >>>>>>>>>>>> have to create a >>>>>>>>>>>> | > | | "child" >>>>>>>>>>>> | > | | pipe. But I agree, that is maybe no optimal ... >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | On Fri, Mar 15, 2013 at 6:44 PM, Summers Pittman < >>>>>>>>>>>> supittma(a)redhat.com >>>>>>>>>>>> | > | | > >>>>>>>>>>>> | > | | wrote: >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | On 03/15/2013 01:34 PM, Sebastien Blanc wrote: >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | I like the idea but I will more see that has a >>>>>>>>>>>> method/function for the >>>>>>>>>>>> | > | | pipelineManager (and will be easier to implement in >>>>>>>>>>>> JS, I think) : >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | var myParentPipe = >>>>>>>>>>>> | > Aerogear.Pipeline({name:"parentPipe"}).pipes.parentPipe >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | var myChildPipe = >>>>>>>>>>>> Aerogear.Pipeline.fromParent(myParentPipe, {options} >>>>>>>>>>>> | > ) >>>>>>>>>>>> | > | | What would it look like to get a child record from a >>>>>>>>>>>> parent? >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | On Fri, Mar 15, 2013 at 5:37 PM, Douglas Campos < >>>>>>>>>>>> qmx(a)qmx.me > wrote: >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | What about this? >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | Pipeline<Post> postPipeline = … >>>>>>>>>>>> | > | | Post post = // get from the pipeline >>>>>>>>>>>> | > | | Pipeline<Comment> >>>>>>>>>>>> | > | | >>>>>>>>>>>> postPipeline.childPipelineForOrOtherWeirdName(Comment.class, post) >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | On 15/03/2013, at 12:26, Summers Pittman < >>>>>>>>>>>> supittma(a)redhat.com > >>>>>>>>>>>> | > wrote: >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | > On 03/14/2013 04:48 AM, Matthias Wessendorf wrote: >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> On Thu, Mar 14, 2013 at 9:32 AM, Sebastien Blanc < >>>>>>>>>>>> | > scm.blanc(a)gmail.com > >>>>>>>>>>>> | > | | >> wrote: >>>>>>>>>>>> | > | | >> Hi, >>>>>>>>>>>> | > | | >> While I was playing with scaffolding and tried to >>>>>>>>>>>> build a simple >>>>>>>>>>>> | > Blog >>>>>>>>>>>> | > | | >> Application with Aerogear I faced the current >>>>>>>>>>>> situation : >>>>>>>>>>>> | > | | >> I have a Post object which contains many Comment >>>>>>>>>>>> objects. Now I >>>>>>>>>>>> | > want to >>>>>>>>>>>> | > | | >> call my Post pipe to retrieve the related comments, >>>>>>>>>>>> I have >>>>>>>>>>>> | > currently 2 >>>>>>>>>>>> | > | | >> options : >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> /posts/1 -> assuming comments will be implicitly >>>>>>>>>>>> retrieved (eager >>>>>>>>>>>> | > | | >> loading) >>>>>>>>>>>> | > | | >> /comments/?postid=1 >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> But regarding our model the correct form should be : >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> /posts/1/comments >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> +1 >>>>>>>>>>>> | > | | >> that is the ideal way to model URIs for "nested" >>>>>>>>>>>> resources. >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> See [1], extracted from [2] >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> But, AFAIK, with the current API, it is not >>>>>>>>>>>> possible to define this >>>>>>>>>>>> | > last >>>>>>>>>>>> | > | | >> pattern (at least for JS and iOs, confirmed by >>>>>>>>>>>> Matzew). When doing a >>>>>>>>>>>> | > | | >> read >>>>>>>>>>>> | > | | >> we can pass an id option but as mentioned in the >>>>>>>>>>>> doc, this id will >>>>>>>>>>>> | > | | >> always >>>>>>>>>>>> | > | | >> be append to the endpoint. >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> Well, it is possible - but in a very (IMO) ugly way: >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> https://gist.github.com/matzew/6ab432e437b9a017a21d >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> IMO, we should be able to support this pattern but >>>>>>>>>>>> for now I'm not >>>>>>>>>>>> | > | | >> really >>>>>>>>>>>> | > | | >> sure how to specify this in our API, so if you have >>>>>>>>>>>> any ideas >>>>>>>>>>>> | > feedback >>>>>>>>>>>> | > | | >> this thread has been made for you ! >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> Suggestion: Enhance the read function - example: >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> https://gist.github.com/matzew/04f069dfbed2cc77a8b4 >>>>>>>>>>>> | > | | > I'm thinking of the inverse myself. Add a >>>>>>>>>>>> "ParentPath" property >>>>>>>>>>>> | > which can >>>>>>>>>>>> | > | | > be used to extract information from parent objects. >>>>>>>>>>>> | > | | > >>>>>>>>>>>> | > | | > >>>>>>>>>>>> https://gist.github.com/secondsun/17ce96082eda37dbd10e >>>>>>>>>>>> | > | | > >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> -Matthias >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> [1] >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > >>>>>>>>>>>> http://www.infoq.com/resource/articles/rest-introduction/en/resources/fig... >>>>>>>>>>>> | > | | >> [2] http://www.infoq.com/articles/rest-introduction >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> Seb >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> _______________________________________________ >>>>>>>>>>>> | > | | >> aerogear-dev mailing list >>>>>>>>>>>> | > | | >> aerogear-dev(a)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 >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> _______________________________________________ >>>>>>>>>>>> | > | | >> aerogear-dev mailing list >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> aerogear-dev(a)lists.jboss.org >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>>> | > | | > >>>>>>>>>>>> | > | | > _______________________________________________ >>>>>>>>>>>> | > | | > aerogear-dev mailing list >>>>>>>>>>>> | > | | > aerogear-dev(a)lists.jboss.org >>>>>>>>>>>> | > | | > >>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | -- qmx >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | _______________________________________________ >>>>>>>>>>>> | > | | aerogear-dev mailing list >>>>>>>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | _______________________________________________ >>>>>>>>>>>> | > | | aerogear-dev mailing list aerogear-dev(a)lists.jboss.org >>>>>>>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | _______________________________________________ >>>>>>>>>>>> | > | | aerogear-dev mailing list >>>>>>>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | _______________________________________________ >>>>>>>>>>>> | > | | aerogear-dev mailing list >>>>>>>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | _______________________________________________ >>>>>>>>>>>> | > | | aerogear-dev mailing list >>>>>>>>>>>> | > | | aerogear-dev(a)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 >>>>>>>>>>>> | > | | _______________________________________________ >>>>>>>>>>>> | > | | aerogear-dev mailing list >>>>>>>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | _______________________________________________ >>>>>>>>>>>> | > | | aerogear-dev mailing list >>>>>>>>>>>> | > | | aerogear-dev(a)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 >>>>>>>>>>>> | > | | _______________________________________________ >>>>>>>>>>>> | > | | aerogear-dev mailing list >>>>>>>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | _______________________________________________ >>>>>>>>>>>> | > | | aerogear-dev mailing list >>>>>>>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>>>>>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | _______________________________________________ >>>>>>>>>>>> | > | aerogear-dev mailing list >>>>>>>>>>>> | > | aerogear-dev(a)lists.jboss.org >>>>>>>>>>>> | > | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | _______________________________________________ >>>>>>>>>>>> | > | aerogear-dev mailing list >>>>>>>>>>>> | > | aerogear-dev(a)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 >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | _______________________________________________ >>>>>>>>>>>> | > | aerogear-dev mailing list >>>>>>>>>>>> | > | aerogear-dev(a)lists.jboss.org >>>>>>>>>>>> | > | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | _______________________________________________ >>>>>>>>>>>> | > | aerogear-dev mailing list >>>>>>>>>>>> | > | aerogear-dev(a)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 >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | -- >>>>>>>>>>>> | > | Matthias Wessendorf >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | blog: http://matthiaswessendorf.wordpress.com/ >>>>>>>>>>>> | > | sessions: http://www.slideshare.net/mwessendorf >>>>>>>>>>>> | > | twitter: http://twitter.com/mwessendorf >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | -- >>>>>>>>>>>> | > | Matthias Wessendorf >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | blog: http://matthiaswessendorf.wordpress.com/ >>>>>>>>>>>> | > | sessions: http://www.slideshare.net/mwessendorf >>>>>>>>>>>> | > | twitter: http://twitter.com/mwessendorf >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | _______________________________________________ >>>>>>>>>>>> | > | aerogear-dev mailing list >>>>>>>>>>>> | > | aerogear-dev(a)lists.jboss.org >>>>>>>>>>>> | > | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>>> | > >>>>>>>>>>>> | > _______________________________________________ >>>>>>>>>>>> | > aerogear-dev mailing list >>>>>>>>>>>> | > aerogear-dev(a)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 >>>>>>>>>>>> | >>>>>>>>>>>> | _______________________________________________ >>>>>>>>>>>> | aerogear-dev mailing list >>>>>>>>>>>> | aerogear-dev(a)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 >>>>>>>>>>>> | >>>>>>>>>>>> | _______________________________________________ >>>>>>>>>>>> | aerogear-dev mailing list >>>>>>>>>>>> | aerogear-dev(a)lists.jboss.org >>>>>>>>>>>> | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> aerogear-dev mailing list >>>>>>>>>>>> aerogear-dev(a)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 >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> aerogear-dev mailing list >>>>>>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> aerogear-dev mailing list >>>>>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> aerogear-dev mailing listaerogear-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> aerogear-dev mailing list >>>>>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> aerogear-dev mailing list >>>>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> aerogear-dev mailing list >>>>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing list >>>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing list >>>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing list >>>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing list >>>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)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 >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

I know I know ! I'm just writing out the stuff with the specs we have today ;) On Tue, Apr 30, 2013 at 10:05 AM, Corinne Krych <corinnekrych(a)gmail.com&gt;wrote: > IMHO, the problem with Seb's syntax > > pipe.remove( 2 , > { > resourcePath: "comment", > resourcePathId: 5 > } > ); > is that you read delete 2 and then the details of the nested structure > you should read delete 5 first and then the details of where to find it. > > --- > Corinne > > > > On 30 April 2013 09:59, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > >> Totally agree :) but if you want to do what you suggest without using >> nested resources ( just delete(5) ) you must create a complete Pipe just >> for "/post/2/comments" which is also not acceptable, we need to find >> aother of doing it. >> >> >> >> On Tue, Apr 30, 2013 at 9:56 AM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: >> >>> >>> >>> >>> On Tue, Apr 30, 2013 at 9:53 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt;wrote: >>> >>>> Yes , i.e a common use case, we want to delete comment with id 5 from >>>> blog post with id 2 : >>>> >>>> DELETE /post/2/comment/5 >>>> >>>> With the nested endpoints has we have defined it will be something >>>> like : >>>> >>>> pipe.remove( 2 , >>>> { >>>> resourcePath:"comment/5" >>>> } >>>> ); >>>> >>>> Which is indeed not crystal clear. But in the same time we really need >>>> to provide a solution. >>>> We could maybe introduce a "resourcePathId" ? >>>> >>>> pipe.remove( 2 , >>>> { >>>> resourcePath: "comment", >>>> resourcePathId: 5 >>>> } >>>> ); >>>> >>>> But that would only make sense for a "one level" nested resource ... >>>> >>> >>> >>> For me, that all reads "delete 2" :) >>> >>> Not sure, but currently, that is more obvious (e.g. when you have a >>> pipe against "/post/2/comments", you just say delete(5);) >>> >>> >>> -Matthias >>> >>> >>> >>>> >>>> >>>> >>>> On Tue, Apr 30, 2013 at 9:43 AM, Matthias Wessendorf < >>>> matzew(a)apache.org&gt; wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Tue, Apr 23, 2013 at 2:38 PM, Kris Borchers <kris(a)redhat.com&gt;wrote: >>>>> >>>>>> This is the same issue I pointed out this morning on Sebi's >>>>>> implementation. I need to think more about a solution. >>>>>> >>>>> >>>>> >>>>> I agree that the 'save' and the 'remove' are a bit weird (hard to >>>>> understand). >>>>> >>>>> -Matthias >>>>> >>>>> >>>>> >>>>>> >>>>>> On Apr 23, 2013, at 7:33 AM, Christos Vasilakis <cvasilak(a)gmail.com&gt; >>>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> as I implement the iOS support for nested paths, and in particular >>>>>> 'save' and 'remove' a situation arises. >>>>>> >>>>>> Consider the 'save' operation for a new team in the following path >>>>>> (a pipe has been instantiated that points to 'leagues') : >>>>>> >>>>>> soccer.org/leagues/foo/teams >>>>>> >>>>>> To save a new team, the user must: >>>>>> >>>>>> [leaguesPipe save:teamObject resourcePath:"/foo/teams"] >>>>>> >>>>>> Notice that now, we NEED to pass the id of the league in the >>>>>> resourcePath for this to work("foo"). >>>>>> >>>>>> To update an existing team, the user must: >>>>>> >>>>>> [leaguesPipe save:teamObject resourcePath:"/foo/teams"] >>>>>> >>>>>> Again the id of the leagues needs to be passed on the resourcePath >>>>>> >>>>>> NOTE: For the update to work, teamObject is implied to have the >>>>>> config.id set (here we assume that the teamObject has similar >>>>>> config_id name with league for this to work ??) >>>>>> >>>>>> Similar for remove: >>>>>> >>>>>> [leaguesPipe remove:teamObject resourcePath:"/foo/teams"] >>>>>> >>>>>> So, for cases of 'save' and 'remove', the resourcePath endpoint with >>>>>> the Pipe id SET must come first, and then we append the object's endpoint. >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> Thanks >>>>>> Christos >>>>>> >>>>>> On Apr 18, 2013, at 6:39 PM, Daniel Bevenius < >>>>>> daniel.bevenius(a)gmail.com&gt; wrote: >>>>>> >>>>>> Yeah, I'm all for 'resourcePath' now that I'm not as confused >>>>>> anymore :) >>>>>> >>>>>> >>>>>> On 18 April 2013 17:37, Christos Vasilakis <cvasilak(a)gmail.com&gt;wrote: >>>>>> >>>>>>> I think If no alternative comes along, let's stick to >>>>>>> 'resourcePath' for now.. >>>>>>> >>>>>>> >>>>>>> On Apr 18, 2013, at 6:23 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; >>>>>>> wrote: >>>>>>> >>>>>>> So we all agreed on "resourcePath" ? >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Apr 18, 2013 at 4:54 PM, Christos Vasilakis < >>>>>>> cvasilak(a)gmail.com&gt; wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> have created the epic to track this, feel free to edit >>>>>>>> >>>>>>>> https://issues.jboss.org/browse/AEROGEAR-1123 >>>>>>>> >>>>>>>> - >>>>>>>> Christos >>>>>>>> >>>>>>>> On Apr 16, 2013, at 4:23 PM, Daniel Bevenius < >>>>>>>> daniel.bevenius(a)gmail.com&gt; wrote: >>>>>>>> >>>>>>>> doh! Sorry. I was just looking at the first examples in the gist >>>>>>>> and did not realize these could have multiple segments. >>>>>>>> >>>>>>>> >>>>>>>> On 16 April 2013 15:18, Kris Borchers <kris(a)redhat.com&gt; wrote: >>>>>>>> >>>>>>>>> Hmm, I like the idea of looking to standards but if I'm reading >>>>>>>>> it right, segment there means just a portion of the URI between slashes, >>>>>>>>> not multiple slash-separated segments. >>>>>>>>> >>>>>>>>> On Apr 16, 2013, at 8:14 AM, Daniel Bevenius < >>>>>>>>> daniel.bevenius(a)gmail.com&gt; wrote: >>>>>>>>> >>>>>>>>> I agree, when I read resourcePath I read that as a path to >>>>>>>>> resource. How about pathSegment or segment as used by >>>>>>>>> http://tools.ietf.org/html/rfc3986#section-3.3 ? >>>>>>>>> >>>>>>>>> >>>>>>>>> On 16 April 2013 15:12, Kris Borchers <kris(a)redhat.com&gt; wrote: >>>>>>>>> >>>>>>>>>> My only issue with resourcePath is that it doesn't imply that >>>>>>>>>> the path is relative to the current pipe. I mean, it should be implied >>>>>>>>>> since you're already working with a pipe and we can be explicit about that >>>>>>>>>> in documentation but I still wish it was somehow in the name. I think that >>>>>>>>>> was the goal of using "nested" in the name but I already expressed my issue >>>>>>>>>> with that. Any other thoughts would be appreciated but I could be happy >>>>>>>>>> with resourcePath. >>>>>>>>>> >>>>>>>>>> On Apr 16, 2013, at 7:55 AM, Lucas Holmquist < >>>>>>>>>> lholmqui(a)redhat.com&gt; wrote: >>>>>>>>>> >>>>>>>>>> +1 to resourcePath . it beats my thought of >>>>>>>>>> "superawesomenestedresourcethingy" >>>>>>>>>> On Apr 16, 2013, at 8:39 AM, Christos Vasilakis < >>>>>>>>>> cvasilak(a)gmail.com&gt; wrote: >>>>>>>>>> >>>>>>>>>> +1 >>>>>>>>>> >>>>>>>>>> I think it describes the feature better. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Apr 16, 2013, at 3:09 PM, Sebastien Blanc < >>>>>>>>>> scm.blanc(a)gmail.com&gt; wrote: >>>>>>>>>> >>>>>>>>>> +1 on the "resourcePath", you nailed it ! >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Apr 16, 2013 at 2:03 PM, Kris Borchers <kris(a)redhat.com&gt;wrote: >>>>>>>>>> >>>>>>>>>>> Hmmm, "nestedResource" isn't terrible but not crazy about >>>>>>>>>>> "nested" since they're not necessarily nested but just related. Hmmmmm. >>>>>>>>>>> >>>>>>>>>>> It's not that I hate resource, I think it kind of makes sense >>>>>>>>>>> if you know what we're talking about. How about something like >>>>>>>>>>> "resourcePath" to be a little more explicit in what it is? Still not crazy >>>>>>>>>>> about that but feel like it's better/closer to something that describes >>>>>>>>>>> what it is. >>>>>>>>>>> >>>>>>>>>>> On Apr 16, 2013, at 6:44 AM, Sebastien Blanc < >>>>>>>>>>> scm.blanc(a)gmail.com&gt; wrote: >>>>>>>>>>> >>>>>>>>>>> Well, there seems to be an agreement on option #1 , except for >>>>>>>>>>> the name "resource" , so let's find a name that we all agree on and so we >>>>>>>>>>> can going further with this feature. >>>>>>>>>>> My propositions: "nestedResource" , "fragment", "nestedURI" >>>>>>>>>>> ... But I'm not really fan of all of my propositions ... >>>>>>>>>>> Seb >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Apr 11, 2013 at 4:07 PM, Summers Pittman < >>>>>>>>>>> supittma(a)redhat.com&gt; wrote: >>>>>>>>>>> >>>>>>>>>>>> With #1 is `resource` a URI? If so, will developers have to >>>>>>>>>>>> build the URI by hand? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 04/10/2013 10:48 AM, Christos Vasilakis wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi >>>>>>>>>>>> >>>>>>>>>>>> I've prepared a document[1] that collectively describes the >>>>>>>>>>>> different approaches discussed in this thread for supporting the nested >>>>>>>>>>>> resources. It is split in two sections, ones that don't require >>>>>>>>>>>> modification to the existing API and ones that do >>>>>>>>>>>> >>>>>>>>>>>> Please have a look and let me know if I miss sth or >>>>>>>>>>>> interpret one approach wrong. >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> Christos >>>>>>>>>>>> >>>>>>>>>>>> [1] https://gist.github.com/cvasilak/4a5f51b8d1ad9cc7f21b >>>>>>>>>>>> >>>>>>>>>>>> On Apr 9, 2013, at 10:19 AM, Sebastien Blanc < >>>>>>>>>>>> scm.blanc(a)gmail.com&gt; wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hey, >>>>>>>>>>>> Like paging, could we start 2 gists : one with a side to side >>>>>>>>>>>> techno samples and another one with high level Specs ? I start a bit to get >>>>>>>>>>>> lost in this thread :) >>>>>>>>>>>> Just one remark when reading the last messages, one "must >>>>>>>>>>>> have" is to be able to retrieve all the comments for a post without EVER >>>>>>>>>>>> retrieving the post record, so >>>>>>>>>>>> /posts/1/comments will retrieve all the comments for post 1 >>>>>>>>>>>> but will actually never call posts/1 : in this covered in your last >>>>>>>>>>>> examples ? (spec could be : "by-pass parent GET resource" >>>>>>>>>>>> Seb >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Apr 9, 2013 at 9:03 AM, Matthias Wessendorf < >>>>>>>>>>>> matzew(a)apache.org&gt; wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Mon, Apr 8, 2013 at 7:57 PM, Summers Pittman < >>>>>>>>>>>>> supittma(a)redhat.com&gt; wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>>>> | From: "Matthias Wessendorf" <matzew(a)apache.org&gt; >>>>>>>>>>>>>> | To: "AeroGear Developer Mailing List" < >>>>>>>>>>>>>> aerogear-dev(a)lists.jboss.org&gt; >>>>>>>>>>>>>> | Sent: Monday, April 8, 2013 1:22:19 PM >>>>>>>>>>>>>> | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support >>>>>>>>>>>>>> for nested endpoints >>>>>>>>>>>>>> | >>>>>>>>>>>>>> | OK, with the following server API: >>>>>>>>>>>>>> | >>>>>>>>>>>>>> | http://some.server.com/posts/1 >>>>>>>>>>>>>> | http://some.server.com/posts/1/comments >>>>>>>>>>>>>> | (and NO 'comments' collection on the ' >>>>>>>>>>>>>> http://some.server.com/posts/1 ' >>>>>>>>>>>>>> | response) >>>>>>>>>>>>>> | >>>>>>>>>>>>>> | Does this (today) 'myPipe.read(1)' already read the >>>>>>>>>>>>>> specific comments ( >>>>>>>>>>>>>> | http://some.server.com/posts/1/comments ) ?? >>>>>>>>>>>>>> | >>>>>>>>>>>>>> | ======= JAVA API ======= >>>>>>>>>>>>>> | Class Post: >>>>>>>>>>>>>> | - string: id; >>>>>>>>>>>>>> | - string: title; >>>>>>>>>>>>>> | - string: postContent; >>>>>>>>>>>>>> | - List<Comment> comments; >>>>>>>>>>>>>> | Class Comment: >>>>>>>>>>>>>> | - string username; >>>>>>>>>>>>>> | - string comment; >>>>>>>>>>>>>> | >>>>>>>>>>>>>> | Or would the IMPL expect an 'embedded' _comments_ >>>>>>>>>>>>>> collection on the response >>>>>>>>>>>>>> | of "GET http://some.server.com/posts/1 " ? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> It will not read /posts/1/comments if the Pipe's endpoint >>>>>>>>>>>>>> is /posts. If you have a comments collection on the post but no comments >>>>>>>>>>>>>> data in the response then the value for getComments will just be null. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Ok - so this needs to be tweaked in Java too, since it's >>>>>>>>>>>>> very common to model the REST endpoints like above; >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> | >>>>>>>>>>>>>> | >>>>>>>>>>>>>> | >>>>>>>>>>>>>> | On Mon, Apr 8, 2013 at 7:05 PM, Summers Pittman < >>>>>>>>>>>>>> supittma(a)redhat.com > >>>>>>>>>>>>>> | wrote: >>>>>>>>>>>>>> | >>>>>>>>>>>>>> | >>>>>>>>>>>>>> | No. The get of pipe 1 would have to include the comments >>>>>>>>>>>>>> for get comments to >>>>>>>>>>>>>> | work >>>>>>>>>>>>>> | >>>>>>>>>>>>>> | Sent from my Android phone using TouchDown ( >>>>>>>>>>>>>> www.nitrodesk.com ) >>>>>>>>>>>>>> | >>>>>>>>>>>>>> | >>>>>>>>>>>>>> | -----Original Message----- >>>>>>>>>>>>>> | From: Matthias Wessendorf [ matzew(a)apache.org ] >>>>>>>>>>>>>> | Received: Monday, 08 Apr 2013, 12:04PM >>>>>>>>>>>>>> | To: AeroGear Developer Mailing List [ >>>>>>>>>>>>>> aerogear-dev(a)lists.jboss.org ] >>>>>>>>>>>>>> | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support >>>>>>>>>>>>>> for nested endpoints >>>>>>>>>>>>>> | >>>>>>>>>>>>>> | >>>>>>>>>>>>>> | On Mon, Apr 8, 2013 at 5:57 PM, Summers Pittman < >>>>>>>>>>>>>> supittma(a)redhat.com > >>>>>>>>>>>>>> | wrote: >>>>>>>>>>>>>> | >>>>>>>>>>>>>> | > >>>>>>>>>>>>>> | > >>>>>>>>>>>>>> | > ----- Original Message ----- >>>>>>>>>>>>>> | > | From: "Matthias Wessendorf" < matzew(a)apache.org > >>>>>>>>>>>>>> | > | To: "AeroGear Developer Mailing List" < >>>>>>>>>>>>>> aerogear-dev(a)lists.jboss.org > >>>>>>>>>>>>>> | > | Sent: Monday, April 8, 2013 10:28:46 AM >>>>>>>>>>>>>> | > | Subject: Re: [aerogear-dev] [Aerogear Pipeline] >>>>>>>>>>>>>> Support for nested >>>>>>>>>>>>>> | > endpoints >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | or, like before said - reading "lists" (e.g. all the >>>>>>>>>>>>>> comments for >>>>>>>>>>>>>> | > specific >>>>>>>>>>>>>> | > | blog post): >>>>>>>>>>>>>> | > | https://gist.github.com/matzew/04f069dfbed2cc77a8b4 >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | For Java.... I guess...... resolving this URL: >>>>>>>>>>>>>> | > | http://some.server.com/posts/1/comments >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | could be done with this - right ? >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | ======= >>>>>>>>>>>>>> | > | Class Post: >>>>>>>>>>>>>> | > | - string: title; >>>>>>>>>>>>>> | > | - string: postContent; >>>>>>>>>>>>>> | > | - List<Comment> comments; >>>>>>>>>>>>>> | > | Class Comment: >>>>>>>>>>>>>> | > | - string username; >>>>>>>>>>>>>> | > | - string comment; >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | // get all the comments for 1: >>>>>>>>>>>>>> | > | Post myPostOne = postPipe.read("1"); >>>>>>>>>>>>>> | > | myPostOne.getComments(); >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | // get all the comments for 2: >>>>>>>>>>>>>> | > | Post myPostTwo = postPipe.read("2"); >>>>>>>>>>>>>> | > | myPostTwo.getComments(); >>>>>>>>>>>>>> | > | ======= >>>>>>>>>>>>>> | > >>>>>>>>>>>>>> | > It can be done with that yes. My concern was more when >>>>>>>>>>>>>> we had a Pipe of >>>>>>>>>>>>>> | > type <Post> and a readForResource(String property) >>>>>>>>>>>>>> method. >>>>>>>>>>>>>> | >>>>>>>>>>>>>> | >>>>>>>>>>>>>> | Ok - one more question >>>>>>>>>>>>>> | >>>>>>>>>>>>>> | >>>>>>>>>>>>>> | So... when doing: myPipe.read(1); does that "only" issue a >>>>>>>>>>>>>> GET against the ' >>>>>>>>>>>>>> | http://some.server.com/posts/1 ' resource? >>>>>>>>>>>>>> | >>>>>>>>>>>>>> | A second get, for the comments collection is than issued >>>>>>>>>>>>>> when calling >>>>>>>>>>>>>> | myPostOne.getComments();? >>>>>>>>>>>>>> | (GET against ' http://some.server.com/posts/1/comments' )? >>>>>>>>>>>>>> | >>>>>>>>>>>>>> | >>>>>>>>>>>>>> | >>>>>>>>>>>>>> | >>>>>>>>>>>>>> | > The type information of the property isn't available >>>>>>>>>>>>>> unless we can infer >>>>>>>>>>>>>> | > it from the Post object. >>>>>>>>>>>>>> | > >>>>>>>>>>>>>> | >>>>>>>>>>>>>> | >>>>>>>>>>>>>> | >>>>>>>>>>>>>> | >>>>>>>>>>>>>> | >>>>>>>>>>>>>> | > >>>>>>>>>>>>>> | > >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | Greetings, >>>>>>>>>>>>>> | > | Matthias >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | On Fri, Apr 5, 2013 at 2:37 PM, Matthias Wessendorf < >>>>>>>>>>>>>> matzew(a)apache.org > >>>>>>>>>>>>>> | > | wrote: >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | Thought a bit more about it and chatted with friends, >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | the issue with the sub pipes is: it adds state and is >>>>>>>>>>>>>> perhaps an API >>>>>>>>>>>>>> | > | construct that is a bit hard to understand (see all >>>>>>>>>>>>>> the discussions here) >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | Not sure - but currently we can access "kid >>>>>>>>>>>>>> resources", with our API - >>>>>>>>>>>>>> | > right >>>>>>>>>>>>>> | > | ? >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | https://gist.github.com/matzew/6ab432e437b9a017a21d >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | Perhaps it's better to just keep it that way? This has >>>>>>>>>>>>>> the benefit of >>>>>>>>>>>>>> | > using >>>>>>>>>>>>>> | > | an established and know API, the different pipes are >>>>>>>>>>>>>> accessible via the >>>>>>>>>>>>>> | > | pipeline object; >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | And the code is not too much code; it's simply an >>>>>>>>>>>>>> explicit pipe ... >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | On Fri, Apr 5, 2013 at 10:56 AM, Matthias Wessendorf < >>>>>>>>>>>>>> matzew(a)apache.org >>>>>>>>>>>>>> | > | > >>>>>>>>>>>>>> | > | wrote: >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | On Fri, Apr 5, 2013 at 10:52 AM, Sebastien Blanc < >>>>>>>>>>>>>> scm.blanc(a)gmail.com > >>>>>>>>>>>>>> | > | wrote: >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | On Fri, Apr 5, 2013 at 10:36 AM, Matthias Wessendorf < >>>>>>>>>>>>>> matzew(a)apache.org >>>>>>>>>>>>>> | > | > >>>>>>>>>>>>>> | > | wrote: >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | On Fri, Apr 5, 2013 at 10:14 AM, Christos Vasilakis < >>>>>>>>>>>>>> cvasilak(a)gmail.com >>>>>>>>>>>>>> | > | > >>>>>>>>>>>>>> | > | wrote: >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | Hi >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | some comments >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | I believe the method can't be used since you don't >>>>>>>>>>>>>> know the team for the >>>>>>>>>>>>>> | > | players so you can't retrieve the pipe directly..right? >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | Isn't that really up to the impl of the rest service? >>>>>>>>>>>>>> | > | They could return a list of teamsHePlayed for; >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | So, let's not tie this API to a specific, not existing >>>>>>>>>>>>>> RESTful service; >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | +1, we don't need to care about that, we must just >>>>>>>>>>>>>> focus on how we can >>>>>>>>>>>>>> | > | declare and call nested pipes. >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | yep >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | I guess this is perhaps the closest we can come to : >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | id<AGPipe> allOwnersInNewYorkPipe = [leaguesPipe >>>>>>>>>>>>>> subPipe:@"owners" >>>>>>>>>>>>>> | > | for:@"newyork"]; >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | and than.... on the 'leaguesPipe' you can access its >>>>>>>>>>>>>> kids with something >>>>>>>>>>>>>> | > like >>>>>>>>>>>>>> | > | : >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | NSArray* kids = [leaguesPipe subPipes]; >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | However, that adds some state to a specific pipe object >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | -M >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | getPlayers ( Callback < List < Player >> callback ) { >>>>>>>>>>>>>> | > | pipe . get ( "player" ). read ( callback ); >>>>>>>>>>>>>> | > | } >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | Further my questions is, how is a third (or arbitrary) >>>>>>>>>>>>>> nested resources >>>>>>>>>>>>>> | > are >>>>>>>>>>>>>> | > | supported? I mean for a url schema like this >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | soccer.org/leagues/ {id}/teams/{id}/players/{id} >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | first we access the leagues: >>>>>>>>>>>>>> | > | --- >>>>>>>>>>>>>> | > | getLeagues(Callback<List<Leagues>> callback) { >>>>>>>>>>>>>> | > | pipe.get("leagues").read(callback); >>>>>>>>>>>>>> | > | } >>>>>>>>>>>>>> | > | --- >>>>>>>>>>>>>> | > | then the teams for this league: >>>>>>>>>>>>>> | > | --- >>>>>>>>>>>>>> | > | getTeamsOnLeaque(Leaque league, Callback<List<Team>> >>>>>>>>>>>>>> callback) { >>>>>>>>>>>>>> | > | pipe.junction("league","team").read(leaque, callback); >>>>>>>>>>>>>> | > | } >>>>>>>>>>>>>> | > | --- >>>>>>>>>>>>>> | > | ..and then we access the "Players" for a "Team": >>>>>>>>>>>>>> | > | --- >>>>>>>>>>>>>> | > | getPlayersOnTeam(Team team, Callback<List<Player>> >>>>>>>>>>>>>> callback) { >>>>>>>>>>>>>> | > | pipe.junction("team","player").read(team, callback); >>>>>>>>>>>>>> | > | } >>>>>>>>>>>>>> | > | --- >>>>>>>>>>>>>> | > | But where is the "League" information to fill the >>>>>>>>>>>>>> "/leagues/{id}..." >>>>>>>>>>>>>> | > path? >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | I'd assume the information is 'inherited' out of a >>>>>>>>>>>>>> given pipe, when >>>>>>>>>>>>>> | > doing the >>>>>>>>>>>>>> | > | 'join' >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | e.g. like >>>>>>>>>>>>>> | > | myTeamsForLeaguePipe = leaguePipe.junction("team"); >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | not sure... >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | Unless you mean something like: >>>>>>>>>>>>>> | > | --- >>>>>>>>>>>>>> | > | getPlayersOnTeam(Leaque league, Team team, >>>>>>>>>>>>>> Callback<List<Player>> >>>>>>>>>>>>>> | > callback) { >>>>>>>>>>>>>> | > | pipe.junction("league", "team","player").read(league, >>>>>>>>>>>>>> team, callback); >>>>>>>>>>>>>> | > | } >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | I am not sure if that is really easy to understand/use >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | Yes and the term "junction" is a bit confusing as it >>>>>>>>>>>>>> don't express >>>>>>>>>>>>>> | > explicitly >>>>>>>>>>>>>> | > | a parent/child relation. >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | --- >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | probably I am missing sth.. >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | Thanks, >>>>>>>>>>>>>> | > | Christos >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | On Apr 4, 2013, at 5:52 PM, Summers Pittman < >>>>>>>>>>>>>> supittma(a)redhat.com > >>>>>>>>>>>>>> | > wrote: >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | What if we create a new metaphor, a Junction. >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | https://gist.github.com/secondsun/dcf5682b6ff17c729d9a >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | It joins two pipes together and can be used over and >>>>>>>>>>>>>> over again with >>>>>>>>>>>>>> | > | different data? >>>>>>>>>>>>>> | > | It isn't a Pipe though, but perhaps that could be >>>>>>>>>>>>>> changed to look more >>>>>>>>>>>>>> | > like >>>>>>>>>>>>>> | > | Christos's previous example. >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | At the very least I like the words "junction" or >>>>>>>>>>>>>> "join" more than "of" >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | ----- Original Message ----- >>>>>>>>>>>>>> | > | | From: "Christos Vasilakis" < cvasilak(a)gmail.com > >>>>>>>>>>>>>> | > | | To: "AeroGear Developer Mailing List" < >>>>>>>>>>>>>> aerogear-dev(a)lists.jboss.org > >>>>>>>>>>>>>> | > | | Sent: Wednesday, April 3, 2013 3:03:02 AM >>>>>>>>>>>>>> | > | | Subject: Re: [aerogear-dev] [Aerogear Pipeline] >>>>>>>>>>>>>> Support for nested >>>>>>>>>>>>>> | > | | endpoints >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | On Apr 2, 2013, at 4:03 PM, Matthias Wessendorf < >>>>>>>>>>>>>> matzew(a)apache.org > >>>>>>>>>>>>>> | > | | wrote: >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | Two thoughts.... >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | 1) the 'original' leaguesPipe has no clue about the >>>>>>>>>>>>>> subpipes, right ? >>>>>>>>>>>>>> | > | | 2) should a pipe offer a 'getter' for all it's sub >>>>>>>>>>>>>> pipes ? >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | Just a thought is instead of using Pipe, to continue >>>>>>>>>>>>>> using Pipeline >>>>>>>>>>>>>> | > adding >>>>>>>>>>>>>> | > | | an >>>>>>>>>>>>>> | > | | extra parameter " of" for specifying the parent : >>>>>>>>>>>>>> E.g.: >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | ….. >>>>>>>>>>>>>> | > | | id<AGPipe> leaguesPipe = [pipeline pipe@"leagues"]; >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | id<AGPipe> allTeamsInSeattlePipe = [pipeline subPipe@"teams" >>>>>>>>>>>>>> of >>>>>>>>>>>>>> | > | | :leaguesPipe >>>>>>>>>>>>>> | > | | for:@"seattle"] >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | id<AGPipe> allPlayersInTrebuchetPipe = [pipeline >>>>>>>>>>>>>> subPipe:@"players" >>>>>>>>>>>>>> | > of: >>>>>>>>>>>>>> | > | | allTeamsInSeattlePipe for:@"trebuchet"]; >>>>>>>>>>>>>> | > | | ….. >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | Wdyt? >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | -M >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | Thanks, >>>>>>>>>>>>>> | > | | Christos >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> soccer.org/leagues/seattle/teams/trebuchet/players/foo - > >>>>>>>>>>>>>> | > | | [[pipeline pipe:@"players" pathParams:@[@"seattle", >>>>>>>>>>>>>> @"trebuchet"]] >>>>>>>>>>>>>> | > read >>>>>>>>>>>>>> | > | | :@"foo"] .. >>>>>>>>>>>>>> | > | | ----- >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | Wdyt? >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | Thanks >>>>>>>>>>>>>> | > | | Christos >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | On Mar 18, 2013, at 1:12 PM, Sebastien Blanc < >>>>>>>>>>>>>> scm.blanc(a)gmail.com > >>>>>>>>>>>>>> | > wrote: >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | Well, that would not be possible, for that you will >>>>>>>>>>>>>> have to create a >>>>>>>>>>>>>> | > | | "child" >>>>>>>>>>>>>> | > | | pipe. But I agree, that is maybe no optimal ... >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | On Fri, Mar 15, 2013 at 6:44 PM, Summers Pittman < >>>>>>>>>>>>>> supittma(a)redhat.com >>>>>>>>>>>>>> | > | | > >>>>>>>>>>>>>> | > | | wrote: >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | On 03/15/2013 01:34 PM, Sebastien Blanc wrote: >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | I like the idea but I will more see that has a >>>>>>>>>>>>>> method/function for the >>>>>>>>>>>>>> | > | | pipelineManager (and will be easier to implement in >>>>>>>>>>>>>> JS, I think) : >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | var myParentPipe = >>>>>>>>>>>>>> | > Aerogear.Pipeline({name:"parentPipe"}).pipes.parentPipe >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | var myChildPipe = >>>>>>>>>>>>>> Aerogear.Pipeline.fromParent(myParentPipe, {options} >>>>>>>>>>>>>> | > ) >>>>>>>>>>>>>> | > | | What would it look like to get a child record from a >>>>>>>>>>>>>> parent? >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | On Fri, Mar 15, 2013 at 5:37 PM, Douglas Campos < >>>>>>>>>>>>>> qmx(a)qmx.me > wrote: >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | What about this? >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | Pipeline<Post> postPipeline = … >>>>>>>>>>>>>> | > | | Post post = // get from the pipeline >>>>>>>>>>>>>> | > | | Pipeline<Comment> >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> postPipeline.childPipelineForOrOtherWeirdName(Comment.class, post) >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | On 15/03/2013, at 12:26, Summers Pittman < >>>>>>>>>>>>>> supittma(a)redhat.com > >>>>>>>>>>>>>> | > wrote: >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | > On 03/14/2013 04:48 AM, Matthias Wessendorf wrote: >>>>>>>>>>>>>> | > | | >> >>>>>>>>>>>>>> | > | | >> >>>>>>>>>>>>>> | > | | >> On Thu, Mar 14, 2013 at 9:32 AM, Sebastien Blanc < >>>>>>>>>>>>>> | > scm.blanc(a)gmail.com > >>>>>>>>>>>>>> | > | | >> wrote: >>>>>>>>>>>>>> | > | | >> Hi, >>>>>>>>>>>>>> | > | | >> While I was playing with scaffolding and tried to >>>>>>>>>>>>>> build a simple >>>>>>>>>>>>>> | > Blog >>>>>>>>>>>>>> | > | | >> Application with Aerogear I faced the current >>>>>>>>>>>>>> situation : >>>>>>>>>>>>>> | > | | >> I have a Post object which contains many Comment >>>>>>>>>>>>>> objects. Now I >>>>>>>>>>>>>> | > want to >>>>>>>>>>>>>> | > | | >> call my Post pipe to retrieve the related >>>>>>>>>>>>>> comments, I have >>>>>>>>>>>>>> | > currently 2 >>>>>>>>>>>>>> | > | | >> options : >>>>>>>>>>>>>> | > | | >> >>>>>>>>>>>>>> | > | | >> /posts/1 -> assuming comments will be implicitly >>>>>>>>>>>>>> retrieved (eager >>>>>>>>>>>>>> | > | | >> loading) >>>>>>>>>>>>>> | > | | >> /comments/?postid=1 >>>>>>>>>>>>>> | > | | >> >>>>>>>>>>>>>> | > | | >> But regarding our model the correct form should >>>>>>>>>>>>>> be : >>>>>>>>>>>>>> | > | | >> >>>>>>>>>>>>>> | > | | >> /posts/1/comments >>>>>>>>>>>>>> | > | | >> >>>>>>>>>>>>>> | > | | >> >>>>>>>>>>>>>> | > | | >> +1 >>>>>>>>>>>>>> | > | | >> that is the ideal way to model URIs for "nested" >>>>>>>>>>>>>> resources. >>>>>>>>>>>>>> | > | | >> >>>>>>>>>>>>>> | > | | >> See [1], extracted from [2] >>>>>>>>>>>>>> | > | | >> >>>>>>>>>>>>>> | > | | >> >>>>>>>>>>>>>> | > | | >> >>>>>>>>>>>>>> | > | | >> But, AFAIK, with the current API, it is not >>>>>>>>>>>>>> possible to define this >>>>>>>>>>>>>> | > last >>>>>>>>>>>>>> | > | | >> pattern (at least for JS and iOs, confirmed by >>>>>>>>>>>>>> Matzew). When doing a >>>>>>>>>>>>>> | > | | >> read >>>>>>>>>>>>>> | > | | >> we can pass an id option but as mentioned in the >>>>>>>>>>>>>> doc, this id will >>>>>>>>>>>>>> | > | | >> always >>>>>>>>>>>>>> | > | | >> be append to the endpoint. >>>>>>>>>>>>>> | > | | >> >>>>>>>>>>>>>> | > | | >> >>>>>>>>>>>>>> | > | | >> Well, it is possible - but in a very (IMO) ugly >>>>>>>>>>>>>> way: >>>>>>>>>>>>>> | > | | >> >>>>>>>>>>>>>> | > | | >> >>>>>>>>>>>>>> https://gist.github.com/matzew/6ab432e437b9a017a21d >>>>>>>>>>>>>> | > | | >> >>>>>>>>>>>>>> | > | | >> >>>>>>>>>>>>>> | > | | >> >>>>>>>>>>>>>> | > | | >> >>>>>>>>>>>>>> | > | | >> IMO, we should be able to support this pattern >>>>>>>>>>>>>> but for now I'm not >>>>>>>>>>>>>> | > | | >> really >>>>>>>>>>>>>> | > | | >> sure how to specify this in our API, so if you >>>>>>>>>>>>>> have any ideas >>>>>>>>>>>>>> | > feedback >>>>>>>>>>>>>> | > | | >> this thread has been made for you ! >>>>>>>>>>>>>> | > | | >> >>>>>>>>>>>>>> | > | | >> >>>>>>>>>>>>>> | > | | >> >>>>>>>>>>>>>> | > | | >> Suggestion: Enhance the read function - example: >>>>>>>>>>>>>> | > | | >> >>>>>>>>>>>>>> | > | | >> >>>>>>>>>>>>>> https://gist.github.com/matzew/04f069dfbed2cc77a8b4 >>>>>>>>>>>>>> | > | | > I'm thinking of the inverse myself. Add a >>>>>>>>>>>>>> "ParentPath" property >>>>>>>>>>>>>> | > which can >>>>>>>>>>>>>> | > | | > be used to extract information from parent objects. >>>>>>>>>>>>>> | > | | > >>>>>>>>>>>>>> | > | | > >>>>>>>>>>>>>> https://gist.github.com/secondsun/17ce96082eda37dbd10e >>>>>>>>>>>>>> | > | | > >>>>>>>>>>>>>> | > | | >> >>>>>>>>>>>>>> | > | | >> >>>>>>>>>>>>>> | > | | >> -Matthias >>>>>>>>>>>>>> | > | | >> >>>>>>>>>>>>>> | > | | >> >>>>>>>>>>>>>> | > | | >> [1] >>>>>>>>>>>>>> | > | | >> >>>>>>>>>>>>>> | > >>>>>>>>>>>>>> http://www.infoq.com/resource/articles/rest-introduction/en/resources/fig... >>>>>>>>>>>>>> | > | | >> [2] >>>>>>>>>>>>>> http://www.infoq.com/articles/rest-introduction >>>>>>>>>>>>>> | > | | >> >>>>>>>>>>>>>> | > | | >> >>>>>>>>>>>>>> | > | | >> >>>>>>>>>>>>>> | > | | >> >>>>>>>>>>>>>> | > | | >> Seb >>>>>>>>>>>>>> | > | | >> >>>>>>>>>>>>>> | > | | >> >>>>>>>>>>>>>> | > | | >> _______________________________________________ >>>>>>>>>>>>>> | > | | >> aerogear-dev mailing list >>>>>>>>>>>>>> | > | | >> aerogear-dev(a)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 >>>>>>>>>>>>>> | > | | >> >>>>>>>>>>>>>> | > | | >> _______________________________________________ >>>>>>>>>>>>>> | > | | >> aerogear-dev mailing list >>>>>>>>>>>>>> | > | | >> >>>>>>>>>>>>>> | > | | >> aerogear-dev(a)lists.jboss.org >>>>>>>>>>>>>> | > | | >> >>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>>>>> | > | | > >>>>>>>>>>>>>> | > | | > _______________________________________________ >>>>>>>>>>>>>> | > | | > aerogear-dev mailing list >>>>>>>>>>>>>> | > | | > aerogear-dev(a)lists.jboss.org >>>>>>>>>>>>>> | > | | > >>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | -- qmx >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | _______________________________________________ >>>>>>>>>>>>>> | > | | aerogear-dev mailing list >>>>>>>>>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | _______________________________________________ >>>>>>>>>>>>>> | > | | aerogear-dev mailing list >>>>>>>>>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | _______________________________________________ >>>>>>>>>>>>>> | > | | aerogear-dev mailing list >>>>>>>>>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | _______________________________________________ >>>>>>>>>>>>>> | > | | aerogear-dev mailing list >>>>>>>>>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | _______________________________________________ >>>>>>>>>>>>>> | > | | aerogear-dev mailing list >>>>>>>>>>>>>> | > | | aerogear-dev(a)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 >>>>>>>>>>>>>> | > | | _______________________________________________ >>>>>>>>>>>>>> | > | | aerogear-dev mailing list >>>>>>>>>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | _______________________________________________ >>>>>>>>>>>>>> | > | | aerogear-dev mailing list >>>>>>>>>>>>>> | > | | aerogear-dev(a)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 >>>>>>>>>>>>>> | > | | _______________________________________________ >>>>>>>>>>>>>> | > | | aerogear-dev mailing list >>>>>>>>>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> | > | | _______________________________________________ >>>>>>>>>>>>>> | > | | aerogear-dev mailing list >>>>>>>>>>>>>> | > | | aerogear-dev(a)lists.jboss.org >>>>>>>>>>>>>> | > | | >>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | _______________________________________________ >>>>>>>>>>>>>> | > | aerogear-dev mailing list >>>>>>>>>>>>>> | > | aerogear-dev(a)lists.jboss.org >>>>>>>>>>>>>> | > | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | _______________________________________________ >>>>>>>>>>>>>> | > | aerogear-dev mailing list >>>>>>>>>>>>>> | > | aerogear-dev(a)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 >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | _______________________________________________ >>>>>>>>>>>>>> | > | aerogear-dev mailing list >>>>>>>>>>>>>> | > | aerogear-dev(a)lists.jboss.org >>>>>>>>>>>>>> | > | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | _______________________________________________ >>>>>>>>>>>>>> | > | aerogear-dev mailing list >>>>>>>>>>>>>> | > | aerogear-dev(a)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 >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | -- >>>>>>>>>>>>>> | > | Matthias Wessendorf >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | blog: http://matthiaswessendorf.wordpress.com/ >>>>>>>>>>>>>> | > | sessions: http://www.slideshare.net/mwessendorf >>>>>>>>>>>>>> | > | twitter: http://twitter.com/mwessendorf >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | -- >>>>>>>>>>>>>> | > | Matthias Wessendorf >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | blog: http://matthiaswessendorf.wordpress.com/ >>>>>>>>>>>>>> | > | sessions: http://www.slideshare.net/mwessendorf >>>>>>>>>>>>>> | > | twitter: http://twitter.com/mwessendorf >>>>>>>>>>>>>> | > | >>>>>>>>>>>>>> | > | _______________________________________________ >>>>>>>>>>>>>> | > | aerogear-dev mailing list >>>>>>>>>>>>>> | > | aerogear-dev(a)lists.jboss.org >>>>>>>>>>>>>> | > | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>>>>> | > >>>>>>>>>>>>>> | > _______________________________________________ >>>>>>>>>>>>>> | > aerogear-dev mailing list >>>>>>>>>>>>>> | > aerogear-dev(a)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 >>>>>>>>>>>>>> | >>>>>>>>>>>>>> | _______________________________________________ >>>>>>>>>>>>>> | aerogear-dev mailing list >>>>>>>>>>>>>> | aerogear-dev(a)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 >>>>>>>>>>>>>> | >>>>>>>>>>>>>> | _______________________________________________ >>>>>>>>>>>>>> | aerogear-dev mailing list >>>>>>>>>>>>>> | aerogear-dev(a)lists.jboss.org >>>>>>>>>>>>>> | https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> aerogear-dev mailing list >>>>>>>>>>>>>> aerogear-dev(a)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 >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> aerogear-dev mailing list >>>>>>>>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> aerogear-dev mailing list >>>>>>>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> aerogear-dev mailing listaerogear-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> aerogear-dev mailing list >>>>>>>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> aerogear-dev mailing list >>>>>>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> aerogear-dev mailing list >>>>>>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> aerogear-dev mailing list >>>>>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> aerogear-dev mailing list >>>>>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> aerogear-dev mailing list >>>>>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> aerogear-dev mailing list >>>>>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> aerogear-dev mailing list >>>>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> aerogear-dev mailing list >>>>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing list >>>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing list >>>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev(a)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 >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)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 >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev >

What if we create a new metaphor, a Junction. https://gist.github.com/secondsun/dcf5682b6ff17c729d9a

It joins two pipes together and can be used over and over again with different data? It isn't a Pipe though, but perhaps that could be changed to look more like Christos's previous example. At the very least I like the words "junction" or "join" more than "of" ----- Original Message ----- | From: "Christos Vasilakis" <cvasilak(a)gmail.com&gt; | To: "AeroGear Developer Mailing List" <aerogear-dev(a)lists.jboss.org&gt; | Sent: Wednesday, April 3, 2013 3:03:02 AM | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for nested endpoints | | | On Apr 2, 2013, at 4:03 PM, Matthias Wessendorf < matzew(a)apache.org > wrote: | | | | | Two thoughts.... | | 1) the 'original' leaguesPipe has no clue about the subpipes, right ? | 2) should a pipe offer a 'getter' for all it's sub pipes ? | | | Just a thought is instead of using Pipe, to continue using Pipeline adding an | extra parameter " of" for specifying the parent : E.g.: | | ….. | id<AGPipe> leaguesPipe = [pipeline pipe@"leagues"]; | | id<AGPipe> allTeamsInSeattlePipe = [pipeline subPipe@"teams" of :leaguesPipe | for:@"seattle"] | | id<AGPipe> allPlayersInTrebuchetPipe = [pipeline subPipe:@"players" of: | allTeamsInSeattlePipe for:@"trebuchet"]; | ….. | | | Wdyt? | | | | | | | | -M | | | | | | Thanks, | Christos | | | | | | | | | | | | | | | soccer.org/leagues/seattle/teams/trebuchet/players/foo - > | [[pipeline pipe:@"players" pathParams:@[@"seattle", @"trebuchet"]] read | :@"foo"] .. | ----- | | | Wdyt? | | Thanks | Christos | | On Mar 18, 2013, at 1:12 PM, Sebastien Blanc < scm.blanc(a)gmail.com > wrote: | | | | Well, that would not be possible, for that you will have to create a "child" | pipe. But I agree, that is maybe no optimal ... | | | On Fri, Mar 15, 2013 at 6:44 PM, Summers Pittman < supittma(a)redhat.com > | wrote: | | | | On 03/15/2013 01:34 PM, Sebastien Blanc wrote: | | | I like the idea but I will more see that has a method/function for the | pipelineManager (and will be easier to implement in JS, I think) : | | var myParentPipe = Aerogear.Pipeline({name:"parentPipe"}).pipes.parentPipe | | var myChildPipe = Aerogear.Pipeline.fromParent(myParentPipe, {options} ) | What would it look like to get a child record from a parent? | | | | | | | On Fri, Mar 15, 2013 at 5:37 PM, Douglas Campos < qmx(a)qmx.me > wrote: | | | What about this? | | Pipeline<Post> postPipeline = … | Post post = // get from the pipeline | Pipeline<Comment> | postPipeline.childPipelineForOrOtherWeirdName(Comment.class, post) | | | On 15/03/2013, at 12:26, Summers Pittman < supittma(a)redhat.com > wrote: | | > On 03/14/2013 04:48 AM, Matthias Wessendorf wrote: | >> | >> | >> On Thu, Mar 14, 2013 at 9:32 AM, Sebastien Blanc < scm.blanc(a)gmail.com > | >> wrote: | >> Hi, | >> While I was playing with scaffolding and tried to build a simple Blog | >> Application with Aerogear I faced the current situation : | >> I have a Post object which contains many Comment objects. Now I want to | >> call my Post pipe to retrieve the related comments, I have currently 2 | >> options : | >> | >> /posts/1 -> assuming comments will be implicitly retrieved (eager loading) | >> /comments/?postid=1 | >> | >> But regarding our model the correct form should be : | >> | >> /posts/1/comments | >> | >> | >> +1 | >> that is the ideal way to model URIs for "nested" resources. | >> | >> See [1], extracted from [2] | >> | >> | >> | >> But, AFAIK, with the current API, it is not possible to define this last | >> pattern (at least for JS and iOs, confirmed by Matzew). When doing a read | >> we can pass an id option but as mentioned in the doc, this id will always | >> be append to the endpoint. | >> | >> | >> Well, it is possible - but in a very (IMO) ugly way: | >> | >> https://gist.github.com/matzew/6ab432e437b9a017a21d | >> | >> | >> | >> | >> IMO, we should be able to support this pattern but for now I'm not really | >> sure how to specify this in our API, so if you have any ideas feedback | >> this thread has been made for you ! | >> | >> | >> | >> Suggestion: Enhance the read function - example: | >> | >> https://gist.github.com/matzew/04f069dfbed2cc77a8b4 | > I'm thinking of the inverse myself. Add a "ParentPath" property which can | > be used to extract information from parent objects. | > | > https://gist.github.com/secondsun/17ce96082eda37dbd10e | > | >> | >> | >> -Matthias | >> | >> | >> [1] | >> http://www.infoq.com/resource/articles/rest-introduction/en/resources/fig... | >> [2] http://www.infoq.com/articles/rest-introduction | >> | >> | >> | >> | >> Seb | >> | >> | >> _______________________________________________ | >> aerogear-dev mailing list | >> aerogear-dev(a)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 | >> | >> _______________________________________________ | >> aerogear-dev mailing list | >> | >> aerogear-dev(a)lists.jboss.org | >> https://lists.jboss.org/mailman/listinfo/aerogear-dev | > | > _______________________________________________ | > aerogear-dev mailing list | > aerogear-dev(a)lists.jboss.org | > https://lists.jboss.org/mailman/listinfo/aerogear-dev | | -- qmx | | | _______________________________________________ | aerogear-dev mailing list | aerogear-dev(a)lists.jboss.org | https://lists.jboss.org/mailman/listinfo/aerogear-dev | | | | _______________________________________________ | aerogear-dev mailing list aerogear-dev(a)lists.jboss.org | https://lists.jboss.org/mailman/listinfo/aerogear-dev | | | _______________________________________________ | aerogear-dev mailing list | aerogear-dev(a)lists.jboss.org | https://lists.jboss.org/mailman/listinfo/aerogear-dev | | _______________________________________________ | aerogear-dev mailing list | aerogear-dev(a)lists.jboss.org | https://lists.jboss.org/mailman/listinfo/aerogear-dev | | | _______________________________________________ | aerogear-dev mailing list | aerogear-dev(a)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 | _______________________________________________ | aerogear-dev mailing list | aerogear-dev(a)lists.jboss.org | https://lists.jboss.org/mailman/listinfo/aerogear-dev | | | _______________________________________________ | aerogear-dev mailing list | aerogear-dev(a)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 | _______________________________________________ | aerogear-dev mailing list | aerogear-dev(a)lists.jboss.org | https://lists.jboss.org/mailman/listinfo/aerogear-dev | | | _______________________________________________ | aerogear-dev mailing list | aerogear-dev(a)lists.jboss.org | https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev