Re: [aerogear-dev] [Aerogear Pipeline] Support for nested endpoints

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