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
