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

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