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
