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

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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev