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

Matthias Wessendorf matzew at apache.org
Fri Apr 5 04:56:23 EDT 2013 

On Fri, Apr 5, 2013 at 10:52 AM, Sebastien Blanc <scm.blanc at gmail.com>wrote:

>
>
>
> 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.
>




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

More information about the aerogear-dev mailing list