----- Original Message -----
| From: "Matthias Wessendorf" <matzew@apache.org>
| To: "AeroGear Developer Mailing List" <aerogear-dev@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 specificIt can be done with that yes. My concern was more when we had a Pipe of type <Post> and a readForResource(String property) method.
| 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();
| =======
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@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@apache.org >
| wrote:
|
|
|
|
|
|
| On Fri, Apr 5, 2013 at 10:52 AM, Sebastien Blanc < scm.blanc@gmail.com >
| wrote:
|
|
|
|
|
|
| On Fri, Apr 5, 2013 at 10:36 AM, Matthias Wessendorf < matzew@apache.org >
| wrote:
|
|
|
|
|
|
| On Fri, Apr 5, 2013 at 10:14 AM, Christos Vasilakis < cvasilak@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@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@gmail.com >
| | To: "AeroGear Developer Mailing List" < aerogear-dev@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@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@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@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@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@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@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@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@lists.jboss.org
| | >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
| | >
| | > _______________________________________________
| | > aerogear-dev mailing list
| | > aerogear-dev@lists.jboss.org
| | > https://lists.jboss.org/mailman/listinfo/aerogear-dev
| |
| | -- qmx
| |
| |
| | _______________________________________________
| | aerogear-dev mailing list
| | aerogear-dev@lists.jboss.org
| | https://lists.jboss.org/mailman/listinfo/aerogear-dev
| |
| |
| |
| | _______________________________________________
| | aerogear-dev mailing list aerogear-dev@lists.jboss.org
| | https://lists.jboss.org/mailman/listinfo/aerogear-dev
| |
| |
| | _______________________________________________
| | aerogear-dev mailing list
| | aerogear-dev@lists.jboss.org
| | https://lists.jboss.org/mailman/listinfo/aerogear-dev
| |
| | _______________________________________________
| | aerogear-dev mailing list
| | aerogear-dev@lists.jboss.org
| | https://lists.jboss.org/mailman/listinfo/aerogear-dev
| |
| |
| | _______________________________________________
| | aerogear-dev mailing list
| | aerogear-dev@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@lists.jboss.org
| | https://lists.jboss.org/mailman/listinfo/aerogear-dev
| |
| |
| | _______________________________________________
| | aerogear-dev mailing list
| | aerogear-dev@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@lists.jboss.org
| | https://lists.jboss.org/mailman/listinfo/aerogear-dev
| |
| |
| | _______________________________________________
| | aerogear-dev mailing list
| | aerogear-dev@lists.jboss.org
| | https://lists.jboss.org/mailman/listinfo/aerogear-dev
|
| _______________________________________________
| aerogear-dev mailing list
| aerogear-dev@lists.jboss.org
| https://lists.jboss.org/mailman/listinfo/aerogear-dev
|
|
| _______________________________________________
| aerogear-dev mailing list
| aerogear-dev@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@lists.jboss.org
| https://lists.jboss.org/mailman/listinfo/aerogear-dev
|
|
| _______________________________________________
| aerogear-dev mailing list
| aerogear-dev@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@lists.jboss.org
| https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev