<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">+1 to resourcePath . it beats my thought of "superawesomenestedresourcethingy"<br><div><div>On Apr 16, 2013, at 8:39 AM, Christos Vasilakis <<a href="mailto:cvasilak@gmail.com">cvasilak@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">+1 <div><br></div><div>I think it describes the feature better.<div><br><div><br><div><div><div>On Apr 16, 2013, at 3:09 PM, Sebastien Blanc <<a href="mailto:scm.blanc@gmail.com">scm.blanc@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">+1 on the "resourcePath", you nailed it ! <div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 16, 2013 at 2:03 PM, Kris Borchers <span dir="ltr"><<a href="mailto:kris@redhat.com" target="_blank">kris@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hmmm, "nestedResource" isn't terrible but not crazy about "nested" since they're not necessarily nested but just related. Hmmmmm.<div>
<br></div><div>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.</div>
<div><div class="h5"><br><div><div>On Apr 16, 2013, at 6:44 AM, Sebastien Blanc <<a href="mailto:scm.blanc@gmail.com" target="_blank">scm.blanc@gmail.com</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr">
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. <div>My propositions: "nestedResource" , "fragment", "nestedURI" ... But I'm not really fan of all of my propositions ...</div>
<div>Seb</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 11, 2013 at 4:07 PM, Summers Pittman <span dir="ltr"><<a href="mailto:supittma@redhat.com" target="_blank">supittma@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>With #1 is `resource` a URI? If so,
will developers have to build the URI by hand?<div><br>
<br>
On 04/10/2013 10:48 AM, Christos Vasilakis wrote:<br>
</div></div><div>
<blockquote type="cite">
Hi
<div><br>
</div>
<div>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</div>
<div><br>
</div>
<div>Please have a look and let me know if I miss sth or interpret
one approach wrong.</div>
<div><br>
</div>
<div>Thanks</div>
<div>Christos</div>
<div><br>
</div>
<div>[1] <a href="https://gist.github.com/cvasilak/4a5f51b8d1ad9cc7f21b" target="_blank">https://gist.github.com/cvasilak/4a5f51b8d1ad9cc7f21b</a></div>
<div><br>
<div>
<div>On Apr 9, 2013, at 10:19 AM, Sebastien Blanc <<a href="mailto:scm.blanc@gmail.com" target="_blank">scm.blanc@gmail.com</a>>
wrote:</div>
<br>
<blockquote type="cite">
<div dir="ltr">Hey,
<div>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 :)</div>
<div>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 </div>
<div>/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"</div>
<div>
Seb</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Tue, Apr 9, 2013 at 9:03 AM,
Matthias Wessendorf <span dir="ltr"><<a href="mailto:matzew@apache.org" target="_blank">matzew@apache.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">
<div>On Mon, Apr 8, 2013 at 7:57 PM,
Summers Pittman <span dir="ltr"><<a href="mailto:supittma@redhat.com" target="_blank">supittma@redhat.com</a>></span>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
<br>
----- Original Message -----<br>
| From: "Matthias Wessendorf" <<a href="mailto:matzew@apache.org" target="_blank">matzew@apache.org</a>><br>
| To: "AeroGear Developer Mailing List" <<a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a>><br>
</div>
<div>
<div>| Sent: Monday, April 8, 2013 1:22:19
PM<br>
| Subject: Re: [aerogear-dev] [Aerogear
Pipeline] Support for nested endpoints<br>
|<br>
</div>
<div>| OK, with the following server API:<br>
|<br>
| <a href="http://some.server.com/posts/1" target="_blank">http://some.server.com/posts/1</a><br>
| <a href="http://some.server.com/posts/1/comments" target="_blank">http://some.server.com/posts/1/comments</a><br>
| (and NO 'comments' collection on the ' <a href="http://some.server.com/posts/1" target="_blank">http://some.server.com/posts/1</a>
'<br>
| response)<br>
|<br>
| Does this (today) 'myPipe.read(1)'
already read the specific comments (<br>
</div>
| <a href="http://some.server.com/posts/1/comments" target="_blank">http://some.server.com/posts/1/comments</a>
) ??<br>
<div>|<br>
| ======= JAVA API =======<br>
| Class Post:<br>
| - string: id;<br>
| - string: title;<br>
| - string: postContent;<br>
| - List<Comment> comments;<br>
| Class Comment:<br>
| - string username;<br>
| - string comment;<br>
|<br>
| Or would the IMPL expect an 'embedded'
_comments_ collection on the response<br>
| of "GET <a href="http://some.server.com/posts/1" target="_blank">http://some.server.com/posts/1</a>
" ?<br>
<span style="color:rgb(34,34,34)"> </span><br>
</div>
</div>
</blockquote>
<div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
</div>
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.<br>
</blockquote>
<div><br>
</div>
</div>
<div>Ok - so this needs to be tweaked in Java
too, since it's very common to model the REST
endpoints like above;</div>
<div>
<div>
<div><br>
</div>
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>|<br>
|<br>
|<br>
| On Mon, Apr 8, 2013 at 7:05 PM,
Summers Pittman < <a href="mailto:supittma@redhat.com" target="_blank">supittma@redhat.com</a>
><br>
| wrote:<br>
|<br>
|<br>
| No. The get of pipe 1 would have to
include the comments for get comments to<br>
| work<br>
|<br>
| Sent from my Android phone using
TouchDown ( <a href="http://www.nitrodesk.com/" target="_blank">www.nitrodesk.com</a>
)<br>
|<br>
|<br>
| -----Original Message-----<br>
| From: Matthias Wessendorf [ <a href="mailto:matzew@apache.org" target="_blank">matzew@apache.org</a>
]<br>
| Received: Monday, 08 Apr 2013, 12:04PM<br>
| To: AeroGear Developer Mailing List [
<a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a>
]<br>
| Subject: Re: [aerogear-dev] [Aerogear
Pipeline] Support for nested endpoints<br>
|<br>
|<br>
| On Mon, Apr 8, 2013 at 5:57 PM,
Summers Pittman < <a href="mailto:supittma@redhat.com" target="_blank">supittma@redhat.com</a>
><br>
| wrote:<br>
|<br>
| ><br>
| ><br>
| > ----- Original Message -----<br>
| > | From: "Matthias Wessendorf"
< <a href="mailto:matzew@apache.org" target="_blank">matzew@apache.org</a>
><br>
| > | To: "AeroGear Developer Mailing
List" < <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a>
><br>
| > | Sent: Monday, April 8, 2013
10:28:46 AM<br>
| > | Subject: Re: [aerogear-dev]
[Aerogear Pipeline] Support for nested<br>
| > endpoints<br>
| > |<br>
| > | or, like before said - reading
"lists" (e.g. all the comments for<br>
| > specific<br>
| > | blog post):<br>
| > | <a href="https://gist.github.com/matzew/04f069dfbed2cc77a8b4" target="_blank">https://gist.github.com/matzew/04f069dfbed2cc77a8b4</a><br>
| > |<br>
| > |<br>
| > | For Java.... I guess......
resolving this URL:<br>
| > | <a href="http://some.server.com/posts/1/comments" target="_blank">http://some.server.com/posts/1/comments</a><br>
| > |<br>
| > | could be done with this - right
?<br>
| > |<br>
| > | =======<br>
| > | Class Post:<br>
| > | - string: title;<br>
| > | - string: postContent;<br>
| > | - List<Comment> comments;<br>
| > | Class Comment:<br>
| > | - string username;<br>
| > | - string comment;<br>
| > |<br>
| > |<br>
| > | // get all the comments for 1:<br>
| > | Post myPostOne =
postPipe.read("1");<br>
| > | myPostOne.getComments();<br>
| > |<br>
| > | // get all the comments for 2:<br>
| > | Post myPostTwo =
postPipe.read("2");<br>
| > | myPostTwo.getComments();<br>
| > | =======<br>
| ><br>
| > It can be done with that yes. My
concern was more when we had a Pipe of<br>
| > type <Post> and a
readForResource(String property) method.<br>
|<br>
|<br>
| Ok - one more question<br>
|<br>
|<br>
| So... when doing: myPipe.read(1); does
that "only" issue a GET against the '<br>
| <a href="http://some.server.com/posts/1" target="_blank">http://some.server.com/posts/1</a>
' resource?<br>
|<br>
| A second get, for the comments
collection is than issued when calling<br>
| myPostOne.getComments();?<br>
| (GET against ' <a href="http://some.server.com/posts/1/comments" target="_blank">http://some.server.com/posts/1/comments</a>'
)?<br>
|<br>
|<br>
|<br>
|<br>
| > The type information of the
property isn't available unless we can
infer<br>
| > it from the Post object.<br>
| ><br>
|<br>
|<br>
|<br>
|<br>
|<br>
| ><br>
| ><br>
| > |<br>
| > |<br>
| > | Greetings,<br>
| > | Matthias<br>
| > |<br>
| > |<br>
| > |<br>
| > |<br>
| > |<br>
| > |<br>
| > |<br>
| > | On Fri, Apr 5, 2013 at 2:37 PM,
Matthias Wessendorf < <a href="mailto:matzew@apache.org" target="_blank">matzew@apache.org</a>
><br>
| > | wrote:<br>
| > |<br>
| > |<br>
| > |<br>
| > | Thought a bit more about it and
chatted with friends,<br>
| > |<br>
| > | the issue with the sub pipes
is: it adds state and is perhaps an API<br>
| > | construct that is a bit hard to
understand (see all the discussions
here)<br>
| > |<br>
| > | Not sure - but currently we can
access "kid resources", with our API -<br>
| > right<br>
| > | ?<br>
| > |<br>
| > | <a href="https://gist.github.com/matzew/6ab432e437b9a017a21d" target="_blank">https://gist.github.com/matzew/6ab432e437b9a017a21d</a><br>
| > |<br>
| > |<br>
| > | Perhaps it's better to just
keep it that way? This has the benefit
of<br>
| > using<br>
| > | an established and know API,
the different pipes are accessible via
the<br>
| > | pipeline object;<br>
| > |<br>
| > | And the code is not too much
code; it's simply an explicit pipe ...<br>
| > |<br>
| > |<br>
| > |<br>
| > |<br>
| > |<br>
| > |<br>
| > | On Fri, Apr 5, 2013 at 10:56
AM, Matthias Wessendorf < <a href="mailto:matzew@apache.org" target="_blank">matzew@apache.org</a><br>
| > | ><br>
| > | wrote:<br>
| > |<br>
| > |<br>
| > |<br>
| > |<br>
| > |<br>
| > |<br>
| > | On Fri, Apr 5, 2013 at 10:52
AM, Sebastien Blanc < <a href="mailto:scm.blanc@gmail.com" target="_blank">scm.blanc@gmail.com</a>
><br>
| > | wrote:<br>
| > |<br>
| > |<br>
| > |<br>
| > |<br>
| > |<br>
| > |<br>
| > | On Fri, Apr 5, 2013 at 10:36
AM, Matthias Wessendorf < <a href="mailto:matzew@apache.org" target="_blank">matzew@apache.org</a><br>
| > | ><br>
| > | wrote:<br>
| > |<br>
| > |<br>
| > |<br>
| > |<br>
| > |<br>
| > |<br>
| > | On Fri, Apr 5, 2013 at 10:14
AM, Christos Vasilakis < <a href="mailto:cvasilak@gmail.com" target="_blank">cvasilak@gmail.com</a><br>
| > | ><br>
| > | wrote:<br>
| > |<br>
| > |<br>
| > |<br>
| > | Hi<br>
| > |<br>
| > | some comments<br>
| > |<br>
| > | I believe the method can't be
used since you don't know the team for
the<br>
| > | players so you can't retrieve
the pipe directly..right?<br>
| > |<br>
| > | Isn't that really up to the
impl of the rest service?<br>
| > | They could return a list of
teamsHePlayed for;<br>
| > |<br>
| > | So, let's not tie this API to a
specific, not existing RESTful service;<br>
| > |<br>
| > | +1, we don't need to care about
that, we must just focus on how we can<br>
| > | declare and call nested pipes.<br>
| > |<br>
| > |<br>
| > |<br>
| > |<br>
| > | yep<br>
| > |<br>
| > | I guess this is perhaps the
closest we can come to :<br>
| > |<br>
| > | id<AGPipe>
allOwnersInNewYorkPipe = [leaguesPipe
subPipe:@"owners"<br>
| > | for:@"newyork"];<br>
| > |<br>
| > | and than.... on the
'leaguesPipe' you can access its kids
with something<br>
| > like<br>
| > | :<br>
| > |<br>
| > | NSArray* kids = [leaguesPipe
subPipes];<br>
| > |<br>
| > |<br>
| > | However, that adds some state
to a specific pipe object<br>
| > |<br>
| > |<br>
| > | -M<br>
| > |<br>
| > |<br>
| > |<br>
| > |<br>
| > |<br>
| > |<br>
| > |<br>
| > |<br>
| > |<br>
| > |<br>
| > |<br>
| > |<br>
| > |<br>
| > |<br>
| > |<br>
| > | getPlayers ( Callback < List
< Player >> callback ) {<br>
| > | pipe . get ( "player" ). read (
callback );<br>
| > | }<br>
| > |<br>
| > | Further my questions is, how is
a third (or arbitrary) nested resources<br>
| > are<br>
| > | supported? I mean for a url
schema like this<br>
| > |<br>
| > | <a href="http://soccer.org/leagues/" target="_blank">soccer.org/leagues/</a>
{id}/teams/{id}/players/{id}<br>
| > |<br>
| > | first we access the leagues:<br>
| > | ---<br>
| > |
getLeagues(Callback<List<Leagues>>
callback) {<br>
| > |
pipe.get("leagues").read(callback);<br>
| > | }<br>
| > | ---<br>
| > | then the teams for this league:<br>
| > | ---<br>
| > | getTeamsOnLeaque(Leaque league,
Callback<List<Team>>
callback) {<br>
| > |
pipe.junction("league","team").read(leaque,
callback);<br>
| > | }<br>
| > | ---<br>
| > | ..and then we access the
"Players" for a "Team":<br>
| > | ---<br>
| > | getPlayersOnTeam(Team team,
Callback<List<Player>>
callback) {<br>
| > |
pipe.junction("team","player").read(team,
callback);<br>
| > | }<br>
| > | ---<br>
| > | But where is the "League"
information to fill the
"/leagues/{id}..."<br>
| > path?<br>
| > |<br>
| > |<br>
| > | I'd assume the information is
'inherited' out of a given pipe, when<br>
| > doing the<br>
| > | 'join'<br>
| > |<br>
| > | e.g. like<br>
| > | myTeamsForLeaguePipe =
leaguePipe.junction("team");<br>
| > |<br>
| > | not sure...<br>
| > |<br>
| > |<br>
| > |<br>
| > |<br>
| > | Unless you mean something like:<br>
| > | ---<br>
| > | getPlayersOnTeam(Leaque league,
Team team,
Callback<List<Player>><br>
| > callback) {<br>
| > | pipe.junction("league",
"team","player").read(league, team,
callback);<br>
| > | }<br>
| > |<br>
| > | I am not sure if that is really
easy to understand/use<br>
| > |<br>
| > | Yes and the term "junction" is
a bit confusing as it don't express<br>
| > explicitly<br>
| > | a parent/child relation.<br>
| > |<br>
| > |<br>
| > |<br>
| > |<br>
| > |<br>
| > |<br>
| > |<br>
| > | ---<br>
| > |<br>
| > | probably I am missing sth..<br>
| > |<br>
| > | Thanks,<br>
| > | Christos<br>
| > |<br>
| > | On Apr 4, 2013, at 5:52 PM,
Summers Pittman < <a href="mailto:supittma@redhat.com" target="_blank">supittma@redhat.com</a>
><br>
| > wrote:<br>
| > |<br>
| > |<br>
| > |<br>
| > | What if we create a new
metaphor, a Junction.<br>
| > |<br>
| > | <a href="https://gist.github.com/secondsun/dcf5682b6ff17c729d9a" target="_blank">https://gist.github.com/secondsun/dcf5682b6ff17c729d9a</a><br>
| > |<br>
| > | It joins two pipes together and
can be used over and over again with<br>
| > | different data?<br>
| > | It isn't a Pipe though, but
perhaps that could be changed to look
more<br>
| > like<br>
| > | Christos's previous example.<br>
| > |<br>
| > | At the very least I like the
words "junction" or "join" more than
"of"<br>
| > |<br>
| > | ----- Original Message -----<br>
| > | | From: "Christos Vasilakis"
< <a href="mailto:cvasilak@gmail.com" target="_blank">cvasilak@gmail.com</a>
><br>
| > | | To: "AeroGear Developer
Mailing List" < <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a>
><br>
| > | | Sent: Wednesday, April 3,
2013 3:03:02 AM<br>
| > | | Subject: Re: [aerogear-dev]
[Aerogear Pipeline] Support for nested<br>
| > | | endpoints<br>
| > | |<br>
| > | |<br>
| > | | On Apr 2, 2013, at 4:03 PM,
Matthias Wessendorf < <a href="mailto:matzew@apache.org" target="_blank">matzew@apache.org</a>
><br>
| > | | wrote:<br>
| > | |<br>
| > | |<br>
| > | |<br>
| > | |<br>
| > | | Two thoughts....<br>
| > | |<br>
| > | | 1) the 'original' leaguesPipe
has no clue about the subpipes, right ?<br>
| > | | 2) should a pipe offer a
'getter' for all it's sub pipes ?<br>
| > | |<br>
| > | |<br>
| > | | Just a thought is instead of
using Pipe, to continue using Pipeline<br>
| > adding<br>
| > | | an<br>
| > | | extra parameter " of" for
specifying the parent : E.g.:<br>
| > | |<br>
| > | | …..<br>
| > | | id<AGPipe> leaguesPipe
= [pipeline pipe@"leagues"];<br>
| > | |<br>
| > | | id<AGPipe>
allTeamsInSeattlePipe = [pipeline
subPipe@"teams" of<br>
| > | | :leaguesPipe<br>
| > | | for:@"seattle"]<br>
| > | |<br>
| > | | id<AGPipe>
allPlayersInTrebuchetPipe = [pipeline
subPipe:@"players"<br>
| > of:<br>
| > | | allTeamsInSeattlePipe
for:@"trebuchet"];<br>
| > | | …..<br>
| > | |<br>
| > | |<br>
| > | | Wdyt?<br>
| > | |<br>
| > | |<br>
| > | |<br>
| > | |<br>
| > | |<br>
| > | |<br>
| > | |<br>
| > | | -M<br>
| > | |<br>
| > | |<br>
| > | |<br>
| > | |<br>
| > | |<br>
| > | | Thanks,<br>
| > | | Christos<br>
| > | |<br>
| > | |<br>
| > | |<br>
| > | |<br>
| > | |<br>
| > | |<br>
| > | |<br>
| > | |<br>
| > | |<br>
| > | |<br>
| > | |<br>
| > | |<br>
| > | |<br>
| > | |<br>
| > | | <a href="http://soccer.org/leagues/seattle/teams/trebuchet/players/foo" target="_blank">soccer.org/leagues/seattle/teams/trebuchet/players/foo</a>
- ><br>
| > | | [[pipeline pipe:@"players"
pathParams:@[@"seattle", @"trebuchet"]]<br>
| > read<br>
| > | | :@"foo"] ..<br>
| > | | -----<br>
| > | |<br>
| > | |<br>
| > | | Wdyt?<br>
| > | |<br>
| > | | Thanks<br>
| > | | Christos<br>
| > | |<br>
| > | | On Mar 18, 2013, at 1:12 PM,
Sebastien Blanc < <a href="mailto:scm.blanc@gmail.com" target="_blank">scm.blanc@gmail.com</a>
><br>
| > wrote:<br>
| > | |<br>
| > | |<br>
| > | |<br>
| > | | Well, that would not be
possible, for that you will have to
create a<br>
| > | | "child"<br>
| > | | pipe. But I agree, that is
maybe no optimal ...<br>
| > | |<br>
| > | |<br>
| > | | On Fri, Mar 15, 2013 at 6:44
PM, Summers Pittman < <a href="mailto:supittma@redhat.com" target="_blank">supittma@redhat.com</a><br>
| > | | ><br>
| > | | wrote:<br>
| > | |<br>
| > | |<br>
| > | |<br>
| > | | On 03/15/2013 01:34 PM,
Sebastien Blanc wrote:<br>
| > | |<br>
| > | |<br>
| > | | I like the idea but I will
more see that has a method/function for
the<br>
| > | | pipelineManager (and will be
easier to implement in JS, I think) :<br>
| > | |<br>
| > | | var myParentPipe =<br>
| >
Aerogear.Pipeline({name:"parentPipe"}).pipes.parentPipe<br>
| > | |<br>
| > | | var myChildPipe =
Aerogear.Pipeline.fromParent(myParentPipe,
{options}<br>
| > )<br>
| > | | What would it look like to
get a child record from a parent?<br>
| > | |<br>
| > | |<br>
| > | |<br>
| > | |<br>
| > | |<br>
| > | |<br>
| > | | On Fri, Mar 15, 2013 at 5:37
PM, Douglas Campos < <a href="mailto:qmx@qmx.me" target="_blank">qmx@qmx.me</a> >
wrote:<br>
| > | |<br>
| > | |<br>
| > | | What about this?<br>
| > | |<br>
| > | | Pipeline<Post>
postPipeline = …<br>
| > | | Post post = // get from the
pipeline<br>
| > | | Pipeline<Comment><br>
| > | |
postPipeline.childPipelineForOrOtherWeirdName(Comment.class,
post)<br>
| > | |<br>
| > | |<br>
| > | | On 15/03/2013, at 12:26,
Summers Pittman < <a href="mailto:supittma@redhat.com" target="_blank">supittma@redhat.com</a>
><br>
| > wrote:<br>
| > | |<br>
| > | | > On 03/14/2013 04:48 AM,
Matthias Wessendorf wrote:<br>
| > | | >><br>
| > | | >><br>
| > | | >> On Thu, Mar 14, 2013
at 9:32 AM, Sebastien Blanc <<br>
| > <a href="mailto:scm.blanc@gmail.com" target="_blank">scm.blanc@gmail.com</a>
><br>
| > | | >> wrote:<br>
| > | | >> Hi,<br>
| > | | >> While I was playing
with scaffolding and tried to build a
simple<br>
| > Blog<br>
| > | | >> Application with
Aerogear I faced the current situation :<br>
| > | | >> I have a Post object
which contains many Comment objects. Now
I<br>
| > want to<br>
| > | | >> call my Post pipe to
retrieve the related comments, I have<br>
| > currently 2<br>
| > | | >> options :<br>
| > | | >><br>
| > | | >> /posts/1 ->
assuming comments will be implicitly
retrieved (eager<br>
| > | | >> loading)<br>
| > | | >> /comments/?postid=1<br>
| > | | >><br>
| > | | >> But regarding our
model the correct form should be :<br>
| > | | >><br>
| > | | >> /posts/1/comments<br>
| > | | >><br>
| > | | >><br>
| > | | >> +1<br>
| > | | >> that is the ideal
way to model URIs for "nested"
resources.<br>
| > | | >><br>
| > | | >> See [1], extracted
from [2]<br>
| > | | >><br>
| > | | >><br>
| > | | >><br>
| > | | >> But, AFAIK, with the
current API, it is not possible to
define this<br>
| > last<br>
| > | | >> pattern (at least
for JS and iOs, confirmed by Matzew).
When doing a<br>
| > | | >> read<br>
| > | | >> we can pass an id
option but as mentioned in the doc, this
id will<br>
| > | | >> always<br>
| > | | >> be append to the
endpoint.<br>
| > | | >><br>
| > | | >><br>
| > | | >> Well, it is possible
- but in a very (IMO) ugly way:<br>
| > | | >><br>
| > | | >> <a href="https://gist.github.com/matzew/6ab432e437b9a017a21d" target="_blank">https://gist.github.com/matzew/6ab432e437b9a017a21d</a><br>
| > | | >><br>
| > | | >><br>
| > | | >><br>
| > | | >><br>
| > | | >> IMO, we should be
able to support this pattern but for now
I'm not<br>
| > | | >> really<br>
| > | | >> sure how to specify
this in our API, so if you have any
ideas<br>
| > feedback<br>
| > | | >> this thread has been
made for you !<br>
| > | | >><br>
| > | | >><br>
| > | | >><br>
| > | | >> Suggestion: Enhance
the read function - example:<br>
| > | | >><br>
| > | | >> <a href="https://gist.github.com/matzew/04f069dfbed2cc77a8b4" target="_blank">https://gist.github.com/matzew/04f069dfbed2cc77a8b4</a><br>
| > | | > I'm thinking of the
inverse myself. Add a "ParentPath"
property<br>
| > which can<br>
| > | | > be used to extract
information from parent objects.<br>
| > | | ><br>
| > | | > <a href="https://gist.github.com/secondsun/17ce96082eda37dbd10e" target="_blank">https://gist.github.com/secondsun/17ce96082eda37dbd10e</a><br>
| > | | ><br>
| > | | >><br>
| > | | >><br>
| > | | >> -Matthias<br>
| > | | >><br>
| > | | >><br>
| > | | >> [1]<br>
| > | | >><br>
| > <a href="http://www.infoq.com/resource/articles/rest-introduction/en/resources/figure2.jpg" target="_blank">http://www.infoq.com/resource/articles/rest-introduction/en/resources/figure2.jpg</a><br>
| > | | >> [2] <a href="http://www.infoq.com/articles/rest-introduction" target="_blank">http://www.infoq.com/articles/rest-introduction</a><br>
| > | | >><br>
| > | | >><br>
| > | | >><br>
| > | | >><br>
| > | | >> Seb<br>
| > | | >><br>
| > | | >><br>
| > | | >>
_______________________________________________<br>
| > | | >> aerogear-dev mailing
list<br>
| > | | >> <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
| > | | >> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
| > | | >><br>
| > | | >><br>
| > | | >><br>
| > | | >> --<br>
| > | | >> Matthias Wessendorf<br>
| > | | >><br>
| > | | >> blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
| > | | >> sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
| > | | >> twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
| > | | >><br>
| > | | >>
_______________________________________________<br>
| > | | >> aerogear-dev mailing
list<br>
| > | | >><br>
| > | | >> <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
| > | | >> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
| > | | ><br>
| > | | >
_______________________________________________<br>
| > | | > aerogear-dev mailing
list<br>
| > | | > <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
| > | | > <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
| > | |<br>
| > | | -- qmx<br>
| > | |<br>
| > | |<br>
| > | |
_______________________________________________<br>
| > | | aerogear-dev mailing list<br>
| > | | <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
| > | | <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
| > | |<br>
| > | |<br>
| > | |<br>
| > | |
_______________________________________________<br>
| > | | aerogear-dev mailing list <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
| > | | <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
| > | |<br>
| > | |<br>
| > | |
_______________________________________________<br>
| > | | aerogear-dev mailing list<br>
| > | | <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
| > | | <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
| > | |<br>
| > | |
_______________________________________________<br>
| > | | aerogear-dev mailing list<br>
| > | | <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
| > | | <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
| > | |<br>
| > | |<br>
| > | |
_______________________________________________<br>
| > | | aerogear-dev mailing list<br>
| > | | <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
| > | | <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
| > | |<br>
| > | |<br>
| > | |<br>
| > | | --<br>
| > | | Matthias Wessendorf<br>
| > | |<br>
| > | | blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
| > | | sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
| > | | twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
| > | |
_______________________________________________<br>
| > | | aerogear-dev mailing list<br>
| > | | <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
| > | | <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
| > | |<br>
| > | |<br>
| > | |
_______________________________________________<br>
| > | | aerogear-dev mailing list<br>
| > | | <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
| > | | <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
| > | |<br>
| > | |<br>
| > | |<br>
| > | | --<br>
| > | | Matthias Wessendorf<br>
| > | |<br>
| > | | blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
| > | | sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
| > | | twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
| > | |
_______________________________________________<br>
| > | | aerogear-dev mailing list<br>
| > | | <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
| > | | <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
| > | |<br>
| > | |<br>
| > | |
_______________________________________________<br>
| > | | aerogear-dev mailing list<br>
| > | | <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
| > | | <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
| > |<br>
| > |
_______________________________________________<br>
| > | aerogear-dev mailing list<br>
| > | <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
| > | <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
| > |<br>
| > |<br>
| > |
_______________________________________________<br>
| > | aerogear-dev mailing list<br>
| > | <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
| > | <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
| > |<br>
| > |<br>
| > |<br>
| > | --<br>
| > | Matthias Wessendorf<br>
| > |<br>
| > | blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
| > | sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
| > | twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
| > |<br>
| > |
_______________________________________________<br>
| > | aerogear-dev mailing list<br>
| > | <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
| > | <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
| > |<br>
| > |<br>
| > |
_______________________________________________<br>
| > | aerogear-dev mailing list<br>
| > | <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
| > | <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
| > |<br>
| > |<br>
| > |<br>
| > | --<br>
| > | Matthias Wessendorf<br>
| > |<br>
| > | blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
| > | sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
| > | twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
| > |<br>
| > |<br>
| > |<br>
| > | --<br>
| > | Matthias Wessendorf<br>
| > |<br>
| > | blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
| > | sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
| > | twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
| > |<br>
| > |<br>
| > |<br>
| > | --<br>
| > | Matthias Wessendorf<br>
| > |<br>
| > | blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
| > | sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
| > | twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
| > |<br>
| > |
_______________________________________________<br>
| > | aerogear-dev mailing list<br>
| > | <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
| > | <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
| ><br>
| >
_______________________________________________<br>
| > aerogear-dev mailing list<br>
| > <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
| > <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
| ><br>
|<br>
|<br>
|<br>
| --<br>
| Matthias Wessendorf<br>
|<br>
| blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
| sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
| twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
|<br>
|
_______________________________________________<br>
| aerogear-dev mailing list<br>
| <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
| <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
|<br>
|<br>
|<br>
| --<br>
| Matthias Wessendorf<br>
|<br>
| blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
| sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
| twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
|<br>
|
_______________________________________________<br>
| aerogear-dev mailing list<br>
| <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
| <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
<br>
_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a></div>
</blockquote>
</div>
</div>
</div>
<div>
<div><br>
<br clear="all">
<div><br>
</div>
-- <br>
Matthias Wessendorf <br>
<br>
blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a>
</div>
</div>
</div>
</div>
<br>
_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
</blockquote>
</div>
<br>
</div>
_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a></blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
aerogear-dev mailing list
<a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a></pre>
</blockquote>
<br>
</div></div>
<br>_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br></blockquote></div><br></div>
_______________________________________________<br>aerogear-dev mailing list<br><a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br><a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a></blockquote>
</div><br></div></div></div><br>_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br></blockquote></div><br></div>
_______________________________________________<br>aerogear-dev mailing list<br><a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br><a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a></blockquote></div><br></div></div></div></div></div>_______________________________________________<br>aerogear-dev mailing list<br><a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/aerogear-dev</blockquote></div><br></body></html>