You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@abdera.apache.org by Dan Diephouse <da...@mulesource.com> on 2008/01/29 03:12:32 UTC
TargetBuilder/TargetResolver questions
I'm trying to migrate my app to the new codebase but am having problems
in the area of URI resolution still. I have a few questions...
1. Looking at CustomProvider, it seems the TargetBuilder completely
specifies the URI space. We should be able to deduce all of the stuff
the RegexTargetResolver does in that case from the TargetBuilder. So it
seems to be that at the very least TemplateTargetBuilder should
implement Resolver<Target>.
2. Is a TargetBuilder always going to be required now (for the
RequestContext.urlFor methods)?
3. Given this expression:
setTemplate(TargetType.TYPE_COLLECTION,
"{target_base}/{collection}{-opt|?|q,c,s,p,l,i,o}{-join|&|q,c,s,p,l,i,o}");
And a "target_base" of "/api", I get out URIs like: "%2Fapi/registry".
I'm simply using this method in SimpleAdapter inside
AbstactCollectionAdaptor:
public String getHref(RequestContext request) {
Map<String,Object> params = new HashMap<String,Object>();
params.put("collection", href);
return request.urlFor(TargetType.TYPE_COLLECTION, params);
}
This behavior doesn't seem right to me. Any ideas on the escaping?
4. In SimpleAdapter - getHref and getFeedBaseUri should return the same
thing right? They're just two different ways of doing so?
Thanks,
- Dan
--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog
Re: TargetBuilder/TargetResolver questions
Posted by James M Snell <ja...@gmail.com>.
URI Template variables cannot span multiple path segments. To do what
you want, you need to use "{-opt|/|collection}{-listjoin|/|collection}"
in the template and specify the param value as params.put("collection",
new String[] {"foo","acme","customers"});
- James
Dan Diephouse wrote:
> OK follow up question. I got my app mostly working, but I broke the
> CustomerAdapter test case. If you look at it I made the URI structure
> like this:
>
> / - the services document
> /foo/acme/customers - the collection.
>
> Given this initialization:
>
> CustomerAdapter ca = new CustomerAdapter();
> ca.setHref("foo/acme/customers");
>
> And this getHref(..) method:
>
> public String getHref(RequestContext request) {
> Map<String,Object> params = new HashMap<String,Object>();
> params.put("collection", href);
> return request.urlFor(TargetType.TYPE_COLLECTION, params);
> }
>
> I get back out URIs of the sort - "/foo%2Facme%2Fcustomers".
>
> Do I just need to accept this as a limitation of the target builder
> code? Or can URI templates actually include other path segments?
>
> Thanks
> - Dan
>
> Dan Diephouse wrote:
>> Thanks for the quick fix!
>> - Dan
>>
>> James M Snell wrote:
>>>
>>>
>>> Dan Diephouse wrote:
>>>> I'm trying to migrate my app to the new codebase but am having
>>>> problems in the area of URI resolution still. I have a few questions...
>>>>
>>>> 1. Looking at CustomProvider, it seems the TargetBuilder completely
>>>> specifies the URI space. We should be able to deduce all of the
>>>> stuff the RegexTargetResolver does in that case from the
>>>> TargetBuilder. So it seems to be that at the very least
>>>> TemplateTargetBuilder should implement Resolver<Target>.
>>>>
>>>
>>> The problem with that is that URI Templates are not always
>>> reversable. For instance, if I have a template like "/{a}{b}{c}/", i
>>> have no way of reliably parsing for a, b or c without having an
>>> associated regex for each.
>>>
>>> StructuredTargetResolver and RouteManager, on the other hand, each
>>> implement Resolver<Target> and TargetBuilder, demonstrating that it
>>> is definitely possible for one object to implement both.
>>>
>>>> 2. Is a TargetBuilder always going to be required now (for the
>>>> RequestContext.urlFor methods)?
>>>>
>>>
>>> Yes.
>>>
>>>> 3. Given this expression:
>>>>
>>>> setTemplate(TargetType.TYPE_COLLECTION,
>>>> "{target_base}/{collection}{-opt|?|q,c,s,p,l,i,o}{-join|&|q,c,s,p,l,i,o}");
>>>>
>>>>
>>>> And a "target_base" of "/api", I get out URIs like:
>>>> "%2Fapi/registry". I'm simply using this method in SimpleAdapter
>>>> inside AbstactCollectionAdaptor:
>>>>
>>>> public String getHref(RequestContext request) {
>>>> Map<String,Object> params = new HashMap<String,Object>();
>>>> params.put("collection", href);
>>>> return request.urlFor(TargetType.TYPE_COLLECTION, params);
>>>> }
>>>>
>>>> This behavior doesn't seem right to me. Any ideas on the escaping?
>>>>
>>>
>>> Damn. Sorry. That's my fault. I completely zoned out on the fact
>>> that a URI template variable cannot span multiple segments. I'll get
>>> that fixed this evening.
>>>
>>>
>>>> 4. In SimpleAdapter - getHref and getFeedBaseUri should return the
>>>> same thing right? They're just two different ways of doing so?
>>>>
>>>
>>> Ummm.. yes. I believe so.
>>>
>>> - James
>>>
>>>> Thanks,
>>>> - Dan
>>>>
>>
>>
>
>
Re: TargetBuilder/TargetResolver questions
Posted by James M Snell <ja...@gmail.com>.
Oh, and btw, the URI Template specification is still being developed, if
you have any feedback on the syntax, please send comments to the W3C URI
Mailing List (http://lists.w3.org/Archives/Public/uri/).
Current draft is here:
http://bitworking.org/projects/URI-Templates/draft-gregorio-uritemplate-02.html
See also:
http://www.ibm.com/developerworks/web/library/wa-uri/
- James
Dan Diephouse wrote:
> OK follow up question. I got my app mostly working, but I broke the
> CustomerAdapter test case. If you look at it I made the URI structure
> like this:
>
> / - the services document
> /foo/acme/customers - the collection.
>
> Given this initialization:
>
> CustomerAdapter ca = new CustomerAdapter();
> ca.setHref("foo/acme/customers");
>
> And this getHref(..) method:
>
> public String getHref(RequestContext request) {
> Map<String,Object> params = new HashMap<String,Object>();
> params.put("collection", href);
> return request.urlFor(TargetType.TYPE_COLLECTION, params);
> }
>
> I get back out URIs of the sort - "/foo%2Facme%2Fcustomers".
>
> Do I just need to accept this as a limitation of the target builder
> code? Or can URI templates actually include other path segments?
>
> Thanks
> - Dan
>
> Dan Diephouse wrote:
>> Thanks for the quick fix!
>> - Dan
>>
>> James M Snell wrote:
>>>
>>>
>>> Dan Diephouse wrote:
>>>> I'm trying to migrate my app to the new codebase but am having
>>>> problems in the area of URI resolution still. I have a few questions...
>>>>
>>>> 1. Looking at CustomProvider, it seems the TargetBuilder completely
>>>> specifies the URI space. We should be able to deduce all of the
>>>> stuff the RegexTargetResolver does in that case from the
>>>> TargetBuilder. So it seems to be that at the very least
>>>> TemplateTargetBuilder should implement Resolver<Target>.
>>>>
>>>
>>> The problem with that is that URI Templates are not always
>>> reversable. For instance, if I have a template like "/{a}{b}{c}/", i
>>> have no way of reliably parsing for a, b or c without having an
>>> associated regex for each.
>>>
>>> StructuredTargetResolver and RouteManager, on the other hand, each
>>> implement Resolver<Target> and TargetBuilder, demonstrating that it
>>> is definitely possible for one object to implement both.
>>>
>>>> 2. Is a TargetBuilder always going to be required now (for the
>>>> RequestContext.urlFor methods)?
>>>>
>>>
>>> Yes.
>>>
>>>> 3. Given this expression:
>>>>
>>>> setTemplate(TargetType.TYPE_COLLECTION,
>>>> "{target_base}/{collection}{-opt|?|q,c,s,p,l,i,o}{-join|&|q,c,s,p,l,i,o}");
>>>>
>>>>
>>>> And a "target_base" of "/api", I get out URIs like:
>>>> "%2Fapi/registry". I'm simply using this method in SimpleAdapter
>>>> inside AbstactCollectionAdaptor:
>>>>
>>>> public String getHref(RequestContext request) {
>>>> Map<String,Object> params = new HashMap<String,Object>();
>>>> params.put("collection", href);
>>>> return request.urlFor(TargetType.TYPE_COLLECTION, params);
>>>> }
>>>>
>>>> This behavior doesn't seem right to me. Any ideas on the escaping?
>>>>
>>>
>>> Damn. Sorry. That's my fault. I completely zoned out on the fact
>>> that a URI template variable cannot span multiple segments. I'll get
>>> that fixed this evening.
>>>
>>>
>>>> 4. In SimpleAdapter - getHref and getFeedBaseUri should return the
>>>> same thing right? They're just two different ways of doing so?
>>>>
>>>
>>> Ummm.. yes. I believe so.
>>>
>>> - James
>>>
>>>> Thanks,
>>>> - Dan
>>>>
>>
>>
>
>
Re: TargetBuilder/TargetResolver questions
Posted by Dan Diephouse <da...@mulesource.com>.
OK follow up question. I got my app mostly working, but I broke the
CustomerAdapter test case. If you look at it I made the URI structure
like this:
/ - the services document
/foo/acme/customers - the collection.
Given this initialization:
CustomerAdapter ca = new CustomerAdapter();
ca.setHref("foo/acme/customers");
And this getHref(..) method:
public String getHref(RequestContext request) {
Map<String,Object> params = new HashMap<String,Object>();
params.put("collection", href);
return request.urlFor(TargetType.TYPE_COLLECTION, params);
}
I get back out URIs of the sort - "/foo%2Facme%2Fcustomers".
Do I just need to accept this as a limitation of the target builder
code? Or can URI templates actually include other path segments?
Thanks
- Dan
Dan Diephouse wrote:
> Thanks for the quick fix!
> - Dan
>
> James M Snell wrote:
>>
>>
>> Dan Diephouse wrote:
>>> I'm trying to migrate my app to the new codebase but am having
>>> problems in the area of URI resolution still. I have a few questions...
>>>
>>> 1. Looking at CustomProvider, it seems the TargetBuilder completely
>>> specifies the URI space. We should be able to deduce all of the
>>> stuff the RegexTargetResolver does in that case from the
>>> TargetBuilder. So it seems to be that at the very least
>>> TemplateTargetBuilder should implement Resolver<Target>.
>>>
>>
>> The problem with that is that URI Templates are not always
>> reversable. For instance, if I have a template like "/{a}{b}{c}/", i
>> have no way of reliably parsing for a, b or c without having an
>> associated regex for each.
>>
>> StructuredTargetResolver and RouteManager, on the other hand, each
>> implement Resolver<Target> and TargetBuilder, demonstrating that it
>> is definitely possible for one object to implement both.
>>
>>> 2. Is a TargetBuilder always going to be required now (for the
>>> RequestContext.urlFor methods)?
>>>
>>
>> Yes.
>>
>>> 3. Given this expression:
>>>
>>> setTemplate(TargetType.TYPE_COLLECTION,
>>> "{target_base}/{collection}{-opt|?|q,c,s,p,l,i,o}{-join|&|q,c,s,p,l,i,o}");
>>>
>>>
>>> And a "target_base" of "/api", I get out URIs like:
>>> "%2Fapi/registry". I'm simply using this method in SimpleAdapter
>>> inside AbstactCollectionAdaptor:
>>>
>>> public String getHref(RequestContext request) {
>>> Map<String,Object> params = new HashMap<String,Object>();
>>> params.put("collection", href);
>>> return request.urlFor(TargetType.TYPE_COLLECTION, params);
>>> }
>>>
>>> This behavior doesn't seem right to me. Any ideas on the escaping?
>>>
>>
>> Damn. Sorry. That's my fault. I completely zoned out on the fact
>> that a URI template variable cannot span multiple segments. I'll get
>> that fixed this evening.
>>
>>
>>> 4. In SimpleAdapter - getHref and getFeedBaseUri should return the
>>> same thing right? They're just two different ways of doing so?
>>>
>>
>> Ummm.. yes. I believe so.
>>
>> - James
>>
>>> Thanks,
>>> - Dan
>>>
>
>
--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog
Re: TargetBuilder/TargetResolver questions
Posted by Dan Diephouse <da...@mulesource.com>.
Thanks for the quick fix!
- Dan
James M Snell wrote:
>
>
> Dan Diephouse wrote:
>> I'm trying to migrate my app to the new codebase but am having
>> problems in the area of URI resolution still. I have a few questions...
>>
>> 1. Looking at CustomProvider, it seems the TargetBuilder completely
>> specifies the URI space. We should be able to deduce all of the stuff
>> the RegexTargetResolver does in that case from the TargetBuilder. So
>> it seems to be that at the very least TemplateTargetBuilder should
>> implement Resolver<Target>.
>>
>
> The problem with that is that URI Templates are not always reversable.
> For instance, if I have a template like "/{a}{b}{c}/", i have no way
> of reliably parsing for a, b or c without having an associated regex
> for each.
>
> StructuredTargetResolver and RouteManager, on the other hand, each
> implement Resolver<Target> and TargetBuilder, demonstrating that it is
> definitely possible for one object to implement both.
>
>> 2. Is a TargetBuilder always going to be required now (for the
>> RequestContext.urlFor methods)?
>>
>
> Yes.
>
>> 3. Given this expression:
>>
>> setTemplate(TargetType.TYPE_COLLECTION,
>> "{target_base}/{collection}{-opt|?|q,c,s,p,l,i,o}{-join|&|q,c,s,p,l,i,o}");
>>
>>
>> And a "target_base" of "/api", I get out URIs like:
>> "%2Fapi/registry". I'm simply using this method in SimpleAdapter
>> inside AbstactCollectionAdaptor:
>>
>> public String getHref(RequestContext request) {
>> Map<String,Object> params = new HashMap<String,Object>();
>> params.put("collection", href);
>> return request.urlFor(TargetType.TYPE_COLLECTION, params);
>> }
>>
>> This behavior doesn't seem right to me. Any ideas on the escaping?
>>
>
> Damn. Sorry. That's my fault. I completely zoned out on the fact that
> a URI template variable cannot span multiple segments. I'll get that
> fixed this evening.
>
>
>> 4. In SimpleAdapter - getHref and getFeedBaseUri should return the
>> same thing right? They're just two different ways of doing so?
>>
>
> Ummm.. yes. I believe so.
>
> - James
>
>> Thanks,
>> - Dan
>>
--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog
Re: TargetBuilder/TargetResolver questions
Posted by James M Snell <ja...@gmail.com>.
Dan Diephouse wrote:
> I'm trying to migrate my app to the new codebase but am having problems
> in the area of URI resolution still. I have a few questions...
>
> 1. Looking at CustomProvider, it seems the TargetBuilder completely
> specifies the URI space. We should be able to deduce all of the stuff
> the RegexTargetResolver does in that case from the TargetBuilder. So it
> seems to be that at the very least TemplateTargetBuilder should
> implement Resolver<Target>.
>
The problem with that is that URI Templates are not always reversable.
For instance, if I have a template like "/{a}{b}{c}/", i have no way of
reliably parsing for a, b or c without having an associated regex for each.
StructuredTargetResolver and RouteManager, on the other hand, each
implement Resolver<Target> and TargetBuilder, demonstrating that it is
definitely possible for one object to implement both.
> 2. Is a TargetBuilder always going to be required now (for the
> RequestContext.urlFor methods)?
>
Yes.
> 3. Given this expression:
>
> setTemplate(TargetType.TYPE_COLLECTION,
> "{target_base}/{collection}{-opt|?|q,c,s,p,l,i,o}{-join|&|q,c,s,p,l,i,o}");
>
> And a "target_base" of "/api", I get out URIs like: "%2Fapi/registry".
> I'm simply using this method in SimpleAdapter inside
> AbstactCollectionAdaptor:
>
> public String getHref(RequestContext request) {
> Map<String,Object> params = new HashMap<String,Object>();
> params.put("collection", href);
> return request.urlFor(TargetType.TYPE_COLLECTION, params);
> }
>
> This behavior doesn't seem right to me. Any ideas on the escaping?
>
Damn. Sorry. That's my fault. I completely zoned out on the fact that a
URI template variable cannot span multiple segments. I'll get that
fixed this evening.
> 4. In SimpleAdapter - getHref and getFeedBaseUri should return the same
> thing right? They're just two different ways of doing so?
>
Ummm.. yes. I believe so.
- James
> Thanks,
> - Dan
>