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

Matthias Wessendorf matzew at apache.org
Mon Apr 8 10:28:46 EDT 2013 

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();
=======


Greetings,
Matthias







On Fri, Apr 5, 2013 at 2:37 PM, Matthias Wessendorf <matzew at apache.org>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 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
>



-- 
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/20130408/e0f5adcf/attachment-0001.html

More information about the aerogear-dev mailing list