So we all agreed on "resourcePath" ?
On Thu, Apr 18, 2013 at 4:54 PM, Christos Vasilakis <cvasilak(a)gmail.com>wrote:
Hi,
have created the epic to track this, feel free to edit
https://issues.jboss.org/browse/AEROGEAR-1123
-
Christos
On Apr 16, 2013, at 4:23 PM, Daniel Bevenius <daniel.bevenius(a)gmail.com>
wrote:
doh! Sorry. I was just looking at the first examples in the gist and did
not realize these could have multiple segments.
On 16 April 2013 15:18, Kris Borchers <kris(a)redhat.com> wrote:
> Hmm, I like the idea of looking to standards but if I'm reading it right,
> segment there means just a portion of the URI between slashes, not multiple
> slash-separated segments.
>
> On Apr 16, 2013, at 8:14 AM, Daniel Bevenius <daniel.bevenius(a)gmail.com>
> wrote:
>
> I agree, when I read resourcePath I read that as a path to resource. How
> about pathSegment or segment as used by
>
http://tools.ietf.org/html/rfc3986#section-3.3 ?
>
>
> On 16 April 2013 15:12, Kris Borchers <kris(a)redhat.com> wrote:
>
>> My only issue with resourcePath is that it doesn't imply that the path
>> is relative to the current pipe. I mean, it should be implied since you're
>> already working with a pipe and we can be explicit about that in
>> documentation but I still wish it was somehow in the name. I think that was
>> the goal of using "nested" in the name but I already expressed my
issue
>> with that. Any other thoughts would be appreciated but I could be happy
>> with resourcePath.
>>
>> On Apr 16, 2013, at 7:55 AM, Lucas Holmquist <lholmqui(a)redhat.com>
>> wrote:
>>
>> +1 to resourcePath . it beats my thought of
>> "superawesomenestedresourcethingy"
>> On Apr 16, 2013, at 8:39 AM, Christos Vasilakis <cvasilak(a)gmail.com>
>> wrote:
>>
>> +1
>>
>> I think it describes the feature better.
>>
>>
>> On Apr 16, 2013, at 3:09 PM, Sebastien Blanc <scm.blanc(a)gmail.com>
>> wrote:
>>
>> +1 on the "resourcePath", you nailed it !
>>
>>
>>
>> On Tue, Apr 16, 2013 at 2:03 PM, Kris Borchers <kris(a)redhat.com> wrote:
>>
>>> Hmmm, "nestedResource" isn't terrible but not crazy about
"nested"
>>> since they're not necessarily nested but just related. Hmmmmm.
>>>
>>> It's not that I hate resource, I think it kind of makes sense if you
>>> know what we're talking about. How about something like
"resourcePath" to
>>> be a little more explicit in what it is? Still not crazy about that but
>>> feel like it's better/closer to something that describes what it is.
>>>
>>> On Apr 16, 2013, at 6:44 AM, Sebastien Blanc <scm.blanc(a)gmail.com>
>>> wrote:
>>>
>>> Well, there seems to be an agreement on option #1 , except for the name
>>> "resource" , so let's find a name that we all agree on and so
we can going
>>> further with this feature.
>>> My propositions: "nestedResource" , "fragment",
"nestedURI" ... But
>>> I'm not really fan of all of my propositions ...
>>> Seb
>>>
>>>
>>>
>>> On Thu, Apr 11, 2013 at 4:07 PM, Summers Pittman
<supittma(a)redhat.com>wrote:
>>>
>>>> With #1 is `resource` a URI? If so, will developers have to build
>>>> the URI by hand?
>>>>
>>>>
>>>> On 04/10/2013 10:48 AM, Christos Vasilakis wrote:
>>>>
>>>> Hi
>>>>
>>>> I've prepared a document[1] that collectively describes the
>>>> different approaches discussed in this thread for supporting the nested
>>>> resources. It is split in two sections, ones that don't require
>>>> modification to the existing API and ones that do
>>>>
>>>> Please have a look and let me know if I miss sth or interpret one
>>>> approach wrong.
>>>>
>>>> Thanks
>>>> Christos
>>>>
>>>> [1]
https://gist.github.com/cvasilak/4a5f51b8d1ad9cc7f21b
>>>>
>>>> On Apr 9, 2013, at 10:19 AM, Sebastien Blanc
<scm.blanc(a)gmail.com>
>>>> wrote:
>>>>
>>>> Hey,
>>>> Like paging, could we start 2 gists : one with a side to side techno
>>>> samples and another one with high level Specs ? I start a bit to get
lost
>>>> in this thread :)
>>>> Just one remark when reading the last messages, one "must have"
is to
>>>> be able to retrieve all the comments for a post without EVER retrieving
the
>>>> post record, so
>>>> /posts/1/comments will retrieve all the comments for post 1 but
>>>> will actually never call posts/1 : in this covered in your last examples
?
>>>> (spec could be : "by-pass parent GET resource"
>>>> Seb
>>>>
>>>>
>>>>
>>>> On Tue, Apr 9, 2013 at 9:03 AM, Matthias Wessendorf
<matzew(a)apache.org
>>>> > wrote:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Apr 8, 2013 at 7:57 PM, Summers Pittman
<supittma(a)redhat.com
>>>>> > wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>> | From: "Matthias Wessendorf"
<matzew(a)apache.org>
>>>>>> | To: "AeroGear Developer Mailing List" <
>>>>>> aerogear-dev(a)lists.jboss.org>
>>>>>> | Sent: Monday, April 8, 2013 1:22:19 PM
>>>>>> | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for
nested
>>>>>> endpoints
>>>>>> |
>>>>>> | OK, with the following server API:
>>>>>> |
>>>>>> |
http://some.server.com/posts/1
>>>>>> |
http://some.server.com/posts/1/comments
>>>>>> | (and NO 'comments' collection on the '
>>>>>>
http://some.server.com/posts/1 '
>>>>>> | response)
>>>>>> |
>>>>>> | Does this (today) 'myPipe.read(1)' already read the
specific
>>>>>> comments (
>>>>>> |
http://some.server.com/posts/1/comments ) ??
>>>>>> |
>>>>>> | ======= JAVA API =======
>>>>>> | Class Post:
>>>>>> | - string: id;
>>>>>> | - string: title;
>>>>>> | - string: postContent;
>>>>>> | - List<Comment> comments;
>>>>>> | Class Comment:
>>>>>> | - string username;
>>>>>> | - string comment;
>>>>>> |
>>>>>> | Or would the IMPL expect an 'embedded' _comments_
collection on
>>>>>> the response
>>>>>> | of "GET
http://some.server.com/posts/1 " ?
>>>>>>
>>>>>>
>>>>> It will not read /posts/1/comments if the Pipe's endpoint is
>>>>>> /posts. If you have a comments collection on the post but no
comments data
>>>>>> in the response then the value for getComments will just be
null.
>>>>>>
>>>>>
>>>>> Ok - so this needs to be tweaked in Java too, since it's very
>>>>> common to model the REST endpoints like above;
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> |
>>>>>> |
>>>>>> |
>>>>>> | On Mon, Apr 8, 2013 at 7:05 PM, Summers Pittman <
>>>>>> supittma(a)redhat.com >
>>>>>> | wrote:
>>>>>> |
>>>>>> |
>>>>>> | 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(a)apache.org ]
>>>>>> | Received: Monday, 08 Apr 2013, 12:04PM
>>>>>> | To: AeroGear Developer Mailing List [
aerogear-dev(a)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(a)redhat.com >
>>>>>> | wrote:
>>>>>> |
>>>>>> | >
>>>>>> | >
>>>>>> | > ----- Original Message -----
>>>>>> | > | From: "Matthias Wessendorf" <
matzew(a)apache.org >
>>>>>> | > | To: "AeroGear Developer Mailing List" <
>>>>>> aerogear-dev(a)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(a)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(a)apache.org
>>>>>> | > | >
>>>>>> | > | wrote:
>>>>>> | > |
>>>>>> | > |
>>>>>> | > |
>>>>>> | > |
>>>>>> | > |
>>>>>> | > |
>>>>>> | > | On Fri, Apr 5, 2013 at 10:52 AM, Sebastien Blanc <
>>>>>> scm.blanc(a)gmail.com >
>>>>>> | > | wrote:
>>>>>> | > |
>>>>>> | > |
>>>>>> | > |
>>>>>> | > |
>>>>>> | > |
>>>>>> | > |
>>>>>> | > | On Fri, Apr 5, 2013 at 10:36 AM, Matthias Wessendorf
<
>>>>>> matzew(a)apache.org
>>>>>> | > | >
>>>>>> | > | wrote:
>>>>>> | > |
>>>>>> | > |
>>>>>> | > |
>>>>>> | > |
>>>>>> | > |
>>>>>> | > |
>>>>>> | > | 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;
>>>>>> | > |
>>>>>> | > | +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(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
>>>>>> | > |
>>>>>> | > |
>>>>>> | > |
>>>>>> | > | --
>>>>>> | > | 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
>>>>>> | > |
>>>>>> | > |
>>>>>> | > |
>>>>>> | > | --
>>>>>> | > | 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(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
>>>>>> |
>>>>>> |
>>>>>> |
>>>>>> | --
>>>>>> | 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
listaerogear-dev@lists.jboss.orghttps://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
>>
>>
>> _______________________________________________
>> 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
>
_______________________________________________
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