abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <dan.diepho...@mulesource.com>
Subject Re: TargetBuilder/TargetResolver questions
Date Tue, 29 Jan 2008 15:36:20 GMT
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


Mime
View raw message