abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James M Snell <jasn...@gmail.com>
Subject Re: TargetBuilder/TargetResolver questions
Date Tue, 29 Jan 2008 15:44:53 GMT
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
>>>>
>>
>>
> 
> 

Mime
View raw message