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

Thought a bit more about it and chatted with friends, the issue with the sub pipes is: it adds state and is perhaps an API construct that is a bit hard to understand (see all the discussions here) Not sure - but currently we can access "kid resources", with our API - right ? https://gist.github.com/matzew/6ab432e437b9a017a21d Perhaps it's better to just keep it that way? This has the benefit of using an established and know API, the different pipes are accessible via the pipeline object; And the code is not too much code; it's simply an explicit pipe ... On Fri, Apr 5, 2013 at 10:56 AM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: > > > > 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 >>> > 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&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 > >>>> | 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 > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf