[aerogear-dev] [Aerogear Pipeline] Support for nested endpoints
Sebastien Blanc
scm.blanc at gmail.com
Fri Mar 15 13:34:14 EDT 2013
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} )
On Fri, Mar 15, 2013 at 5:37 PM, Douglas Campos <qmx at 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 at 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 at 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 at 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 at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> -- qmx
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130315/bb8e1b7e/attachment.html
More information about the aerogear-dev
mailing list