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

Mon Apr 8 13:05:43 EDT 2013

No. The get of pipe 1 would have to include the comments for get comments to work

Sent from my Android phone using TouchDown (www.nitrodesk.com)

-----Original Message-----
From: Matthias Wessendorf [matzew at apache.org]
Received: Monday, 08 Apr 2013, 12:04PM
To: AeroGear Developer Mailing List [aerogear-dev at lists.jboss.org]
Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for nested endpoints

On Mon, Apr 8, 2013 at 5:57 PM, Summers Pittman <supittma at redhat.com> wrote:

>
>
> ----- Original Message -----
> | From: "Matthias Wessendorf" <matzew at apache.org>
> | To: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>
> | Sent: Monday, April 8, 2013 10:28:46 AM
> | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for nested
> endpoints
> |
> | 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();
> | =======
>
> It can be done with that yes.  My concern was more when we had a Pipe of
> type <Post> and a readForResource(String property)  method.

Ok - one more question

So... when doing: myPipe.read(1); does that "only" issue a GET against the '
 http://some.server.com/posts/1' resource?

A second get, for the comments collection is than issued when calling
myPostOne.getComments();?
(GET against ' http://some.server.com/posts/1/comments')?

>  The type information of the property isn't available unless we can infer
> it from the Post object.
>

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