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

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&gt; 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&gt; 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&gt; > 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 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