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

----- Original Message ----- | From: "Matthias Wessendorf" <matzew(a)apache.org&gt; | To: "AeroGear Developer Mailing List" <aerogear-dev(a)lists.jboss.org&gt; | Sent: Monday, April 8, 2013 10:28:46 AM | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for nested endpoints | | or, like before said - reading "lists" (e.g. all the comments for specific | blog post): | https://gist.github.com/matzew/04f069dfbed2cc77a8b4 | | | For Java.... I guess...... resolving this URL: | http://some.server.com/posts/1/comments | | could be done with this - right ? | | ======= | Class Post: | - string: title; | - string: postContent; | - List<Comment> comments; | Class Comment: | - string username; | - string comment; | | | // get all the comments for 1: | Post myPostOne = postPipe.read("1"); | myPostOne.getComments(); | | // get all the comments for 2: | Post myPostTwo = postPipe.read("2"); | myPostTwo.getComments(); | ======= It can be done with that yes. My concern was more when we had a Pipe of type <Post> and a readForResource(String property) method.

The type information of the property isn't available unless we can infer it from the Post object.

| | | Greetings, | Matthias | | | | | | | | On Fri, Apr 5, 2013 at 2:37 PM, Matthias Wessendorf < matzew(a)apache.org&gt; | wrote: | | | | 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 > | 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 > 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 > | | To: "AeroGear Developer Mailing List" < aerogear-dev(a)lists.jboss.org > | | 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 | | | | -- | 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 | | | | -- | 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