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

I think If no alternative comes along, let's stick to 'resourcePath' for now.. On Apr 18, 2013, at 6:23 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: So we all agreed on "resourcePath" ? On Thu, Apr 18, 2013 at 4:54 PM, Christos Vasilakis <cvasilak(a)gmail.com&gt;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&gt; > 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&gt; 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&gt; >> 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&gt; 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&gt; >>> wrote: >>> >>> +1 to resourcePath . it beats my thought of >>> "superawesomenestedresourcethingy" >>> On Apr 16, 2013, at 8:39 AM, Christos Vasilakis <cvasilak(a)gmail.com&gt; >>> wrote: >>> >>> +1 >>> >>> I think it describes the feature better. >>> >>> >>> On Apr 16, 2013, at 3:09 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; >>> wrote: >>> >>> +1 on the "resourcePath", you nailed it ! >>> >>> >>> >>> On Tue, Apr 16, 2013 at 2:03 PM, Kris Borchers <kris(a)redhat.com&gt; 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&gt; >>>> 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&gt;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&gt; >>>>> 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&gt; wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Apr 8, 2013 at 7:57 PM, Summers Pittman < >>>>>> supittma(a)redhat.com&gt; wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>> | From: "Matthias Wessendorf" <matzew(a)apache.org&gt; >>>>>>> | To: "AeroGear Developer Mailing List" < >>>>>>> aerogear-dev(a)lists.jboss.org&gt; >>>>>>> | 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 > _______________________________________________ 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