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

Summers Pittman supittma at redhat.com
Thu Apr 4 10:52:09 EDT 2013 

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 at gmail.com>
| To: "AeroGear Developer Mailing List" <aerogear-dev at 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 at 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 at 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 at 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 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
| 
| 
| 
| _______________________________________________
| 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
| 
| _______________________________________________
| 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
| 
| 
| 
| --
| 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
| 
| 
| 
| --
| 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

More information about the aerogear-dev mailing list