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

Thu Apr 4 02:58:31 EDT 2013

Interesting thoughts - but I am not sure if I like the "of" - feels a bit
procedural :)

Would be interested in other opinions on this

-Matthias

On Wed, Apr 3, 2013 at 9:03 AM, Christos Vasilakis <cvasilak at gmail.com>wrote:

>
> 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 listaerogear-dev at lists.jboss.orghttps://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
>

-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130404/b6d19224/attachment-0001.html 