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&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 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 >> > > > > -- > 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