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

Summers Pittman supittma at redhat.com
Mon Apr 8 11:48:46 EDT 2013



----- Original Message -----
| From: "Christos Vasilakis" <cvasilak at gmail.com>
| To: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>
| Sent: Friday, April 5, 2013 4:14:32 AM
| Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for nested endpoints
| 
| 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?
| 
| getPlayers ( Callback < List < Player >> callback ) {
| pipe . get ( "player" ). read ( callback );
| }

This method would retrieve all Players, not players on a team.

| 
| 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?
| Unless you mean something like:
| ---
| getPlayersOnTeam(Leaque league, Team team, Callback<List<Player>> callback) {
| pipe.junction("league", "team","player").read(league, team, callback);
| }
| ---
This is what you would do if your path was League -> Team -> Players.  In my example ${id} would be fetched from the field with the @RecordId annotation and the name field of each junctioned pipe would be appended to the path.  So in this case /league/${id}/team/${id}/player

The idea is that we pull information from the Pipes which have been junctioned and apply the RESTful pattern.  This doesn't help if there isn't a good pattern of course.

| 
| probably I am missing sth..
Seems like you are on mostly the right idea with what I meant.
| 
| Thanks,
| Christos
| 
| On Apr 4, 2013, at 5:52 PM, Summers Pittman < supittma at 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 at gmail.com>
| | To: "AeroGear Developer Mailing List" <aerogear-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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/figure2.jpg
| | >> [2] http://www.infoq.com/articles/rest-introduction
| | >> 
| | >> 
| | >> 
| | >> 
| | >> Seb
| | >> 
| | >> 
| | >> _______________________________________________
| | >> aerogear-dev mailing list
| | >> aerogear-dev at 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 at lists.jboss.org
| | >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
| | > 
| | > _______________________________________________
| | > aerogear-dev mailing list
| | > aerogear-dev at lists.jboss.org
| | > https://lists.jboss.org/mailman/listinfo/aerogear-dev
| | 
| | -- qmx
| | 
| | 
| | _______________________________________________
| | aerogear-dev mailing list
| | aerogear-dev at lists.jboss.org
| | https://lists.jboss.org/mailman/listinfo/aerogear-dev
| | 
| | 
| | 
| | _______________________________________________
| | aerogear-dev mailing list aerogear-dev at lists.jboss.org
| | https://lists.jboss.org/mailman/listinfo/aerogear-dev
| | 
| | 
| | _______________________________________________
| | aerogear-dev mailing list
| | aerogear-dev at lists.jboss.org
| | https://lists.jboss.org/mailman/listinfo/aerogear-dev
| | 
| | _______________________________________________
| | aerogear-dev mailing list
| | aerogear-dev at lists.jboss.org
| | https://lists.jboss.org/mailman/listinfo/aerogear-dev
| | 
| | 
| | _______________________________________________
| | aerogear-dev mailing list
| | aerogear-dev at 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 at lists.jboss.org
| | https://lists.jboss.org/mailman/listinfo/aerogear-dev
| | 
| | 
| | _______________________________________________
| | aerogear-dev mailing list
| | aerogear-dev at 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 at lists.jboss.org
| | https://lists.jboss.org/mailman/listinfo/aerogear-dev
| | 
| | 
| | _______________________________________________
| | aerogear-dev mailing list
| | aerogear-dev at lists.jboss.org
| | https://lists.jboss.org/mailman/listinfo/aerogear-dev
| 
| _______________________________________________
| aerogear-dev mailing list
| aerogear-dev at lists.jboss.org
| https://lists.jboss.org/mailman/listinfo/aerogear-dev
| 
| 
| _______________________________________________
| aerogear-dev mailing list
| aerogear-dev at lists.jboss.org
| https://lists.jboss.org/mailman/listinfo/aerogear-dev



More information about the aerogear-dev mailing list