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

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