On Fri, Apr 5, 2013 at 10:14 AM, Christos Vasilakis <cvasilak(a)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;
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);
}
---
probably I am missing sth..
Thanks,
Christos
On Apr 4, 2013, at 5:52 PM, Summers Pittman <supittma(a)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(a)gmail.com>
| To: "AeroGear Developer Mailing List" <aerogear-dev(a)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(a)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(a)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(a)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(a)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(a)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(a)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/fig...
| >> [2]
http://www.infoq.com/articles/rest-introduction
| >>
| >>
| >>
| >>
| >> Seb
| >>
| >>
| >> _______________________________________________
| >> aerogear-dev mailing list
| >> aerogear-dev(a)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(a)lists.jboss.org
| >>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
| >
| > _______________________________________________
| > aerogear-dev mailing list
| > aerogear-dev(a)lists.jboss.org
| >
https://lists.jboss.org/mailman/listinfo/aerogear-dev
|
| -- qmx
|
|
| _______________________________________________
| aerogear-dev mailing list
| aerogear-dev(a)lists.jboss.org
|
https://lists.jboss.org/mailman/listinfo/aerogear-dev
|
|
|
| _______________________________________________
| aerogear-dev mailing list aerogear-dev(a)lists.jboss.org
|
https://lists.jboss.org/mailman/listinfo/aerogear-dev
|
|
| _______________________________________________
| aerogear-dev mailing list
| aerogear-dev(a)lists.jboss.org
|
https://lists.jboss.org/mailman/listinfo/aerogear-dev
|
| _______________________________________________
| aerogear-dev mailing list
| aerogear-dev(a)lists.jboss.org
|
https://lists.jboss.org/mailman/listinfo/aerogear-dev
|
|
| _______________________________________________
| aerogear-dev mailing list
| aerogear-dev(a)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(a)lists.jboss.org
|
https://lists.jboss.org/mailman/listinfo/aerogear-dev
|
|
| _______________________________________________
| aerogear-dev mailing list
| aerogear-dev(a)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(a)lists.jboss.org
|
https://lists.jboss.org/mailman/listinfo/aerogear-dev
|
|
| _______________________________________________
| aerogear-dev mailing list
| aerogear-dev(a)lists.jboss.org
|
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev