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

Hi answers inline On Apr 2, 2013, at 2:22 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: On Thu, Mar 28, 2013 at 1:03 PM, Christos Vasilakis <cvasilak(a)gmail.com&gt;wrote: > Hi team, > > on the last couple of days I have been playing with the idea on how to > support nested path in resources (a.k.a subresources). I am more keen in > the idea to treat the nested resources as full-time citizens. That is, > treat the nested resource as a Pipe. > I agree w/ Luke - interesting proposal > > I came up with the following proposal (showing here in iOS) > > For demonstration I use an imaginative Soccer API > > e.g. > soccer.org/leagues/{id}/teams/{id}/players > > when expanded with sample {ids}: > soccer.org/leagues/seattle/teams/trebuchet/players > > During registration of the "parent pipe" (leagues) we specify the nested > resources for this Pipe using the "setNestedPipes" config option. > Internally the Pipeline during the setup of this pipe creates the > corresponding nested pipes, initialising their URL accordingly. > > e.g. > ----- > AGPipeline* pipeline = [AGPipeline > pipelineWithBaseURL:BASE_SOCCER_APP_URL]; > > id<AGPipe> leagues = [pipeline pipe:^(id<AGPipeConfig> config) { > [config setName:@"leagues"]; > > [config setNestedPipes:[@"teams", @"players"]; // an array of nested > resources for this pipe > I would read the nested pipes here as: * soccer.org/leagues/{id}/teams * soccer.org/leagues/{id}/players which does not match the above URL samples, you gave; Internally, using the order of the nested resource names in the array, I built two pipes in that order, that is soccer.org/leagues/{id}/teams/ (1) soccer.org/leagues/{id}/teams/{id}/players (2) but as you said, it can be easily confused.. > }]; > ----- > > A new "pipe" method is added in the pipeline with params the Parent ID's > of this nested resource. Once returned you have a fill Pipe to invoke > operations on. > > ----- > soccer.org/leagues/seattle/teams/trebuchet - > > [[pipeline pipe:@"teams" pathParams:@[@"seattle"]] *read:@*"trebuchet"] > ... > Hrm..... I am confused... What is the name of the first argument? Also the path params, not sure about them… agree. Basically you access the pipe "teams" filling the parent {id}'s with the values. I think this proposal differs from how we currently read a specific entry: (soccer.org/leagues/seattle) [leaguesPipe read:@"seattle" success:callback failure:othercallback]; So i guess ... the above would return details about the "Seattle League", right? correct, no change to how the leaguesPipe works. Now... I think... If I wanted a "sub"/"nested" pipe, from that leagues pipe (e.g. to work with teams in the "Seattle Leaguue" ... I think there are two ways... a) use the Pipeline as it's factory (I guess that's what you proposed) b) use the actual pipe to create a nested pipe, by leveraging the available information Here is, I think, how the b) could look for this URL: id<AGPipe> allTeamsInSeattlePipe = [leaguesPipe subPipe:@"teams" for:@"seattle"]; Now we have a subPipe that has this (inherited) URL: -> soccer.org/leagues/seattle/teams And, if I want to issue a a read against " soccer.org/leagues/seattle/teams/trebuchet" would look like: [allTeamsInSeattlePipe read:@"trebuchet" success:callback failure:othercallback]; Now, imagine the API could also return the owners of a certain lagues - the "sub pipe creation" could be done like: Here is, I think, how the b) could look for this URL: id<AGPipe> allOwnersInNewYorkPipe = [leaguesPipe subPipe:@"owners" for:@"newyork"]; Reading details about Mr. Brown (some owner in the list, that has the ID 19) would be like: [allOwnersInNewYorkPipe read:@"19" success:callback failure:othercallback]; So... this would match a read to: "soccer.org/leagues/newyork/owners/19" Does that make sense ? Any thoughts ? I really *LIKE* the idea! +1000 It's verbose enough and it's easy to set up the nested pipes. two comments: a) For accessing a sub-nested pipe of a nested one I assume there will be something like the following e.g: soccer.org/leagues/seatle/teams/ -> id<AGPipe> *allTeamsInSeattlePipe* = [leaguesPipe subPipe:@"teams" for:@ "seattle"]; soccer.org/leagues/seatle/teams/trebuchet/players -> id<AGPipe> allPlayersInTrebuchetPipe = [*allTeamsInSeattlePipe* subPipe:@"players" for:@"trebuchet"]; right?

b) I assume for passing the configuration for this pipe there can be another method [optional] passing the PipeConfig if the user wants to override any setting for this particular pipe e.g: id<AGPipe> allTeamsInSeattlePipe = [leaguesPipe subPipe:@"teams" for:@"seattle" config:^(id<AGPipeConfig> config) { setRecordId:.. setTimeout.. ... }];

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