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

Fri Apr 5 08:37:26 EDT 2013

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 at apache.org>wrote:

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

-- 
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/6029851b/attachment-0001.html 