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

Sebastien Blanc scm.blanc at gmail.com
Fri Apr 5 04:52:02 EDT 2013


On Fri, Apr 5, 2013 at 10:36 AM, Matthias Wessendorf <matzew at apache.org>wrote:

>
>
>
> On Fri, Apr 5, 2013 at 10:14 AM, Christos Vasilakis <cvasilak at 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.

>
>
>
>>
>>  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 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
>>
>
>
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130405/05cbec9c/attachment-0001.html 


More information about the aerogear-dev mailing list