Hi Ryan,
[...]
> Queries for specific resources ( i.e. /users/admin) currently
> return an RDF XML document. In the RDF document, the URI
> identifying the resource is referenced. Inside the resource
> are references to child resources, and they are also
> identified by URI. The problem is: at RDF construction, how
> do I know the URIs?
As you seem to build your resource (representations) dynamically, you could
pass the parent resource's URI to its constructor. The properties available
are:
- Request.resourceRef
- Request.resourceRef.baseRef
- Request.rootRef (new in upcoming RC2 and in SVN trunk)
You should also implement your URI generation logic using the
Resource.identifier property (note that Resource.identifiers has been
deprecated in RC2).
> When producing the "top" node, this is trivial, because the
> URI is obviously that passed in the Request. It gets more
> complicated for each of the child nodes, however. There, the
> RDF writer has to have knowledge of what the URI should be,
> and has to manually construct the URI. What is disapointing
> to me about this is that this means now that the list of URI
> -> resource mappings it maintained in two places: once in
> whatever sets up routes to the Router, and once in the bit
> that produces the RDF representation of my data model.
I have thought about something similar recently but then I realized that a
Resource class could be identified by different URIs, for example think
about a localized application, where each URI path is translated to
different languages for UI friendliness.
This means that there isn't necessarily one identifier for a given Resource
instance and that the routing of a request to a target resource may be very
dynamic. Routers can also be nested for deeper hierarchies, which makes it
hard to centralize all URI mappings.
> Ideally, however, I would like one registry which:
> * sets up the router to attach patterns to their Restlets
> * has the list of all the patterns
> * can be a reference point for the RDF (or whatever other
> representation) builder to go to and say "for something of
> resource type X, the URI is Y"
This is tempting indeed, but I'm not sure that this could be generalized at
the API level, even thought it might work very well in your case. I'd like
to discuss it more.
> I tried to build something up based on Template, but what I
> really need to make this happen is for Template to have a
> method which would produce a string with variables substituted.
Agreed, the Template is too tighly bound to the Request/Response classes,
I've just added to SVN some new parse/format methods based solely on a
Map<String, Object>.
> Here's an example of what I mean:
>
> Inside my "RDFTransformationVisitor":
>
> public Resource accept(Module module) {
> Resource moduleR = rdfModel.createResource(baseURI +
> "/modules/" + module.getCode());
>
> moduleR.addProperty(rdfModel.createProperty(URI,
> "name"), module.getName()).
> addProperty( rdfModel.createProperty(URI,
> "code"), module.getCode()).
> addProperty(rdfModel.createProperty (URI,
> "visible"), module.getVisible().equalsIgnoreCase("Y")).
> addProperty(rdfModel.createProperty (URI,
> "url"), module.getAppDeployUrl());
>
> return moduleR;
> }
>
> Instead of that 'baseURI + ...' bit, I would prefer to have
> something like:
>
>
> baseURI +
> URIRegistry.get(Module.class).getTemplate().substitute("module
> ", module.getCode())
>
>
> Additionally, when declaring the routings for my application,
> I could do:
>
>
> router.attach(
> URIRegistry.get(Module.class).getTemplate().getPattern(),
> URIRegistry.get(Module.class).getHandler() )
>
>
> Am I way out in left field, or is this something someone else
> could use? It seems like a pattern other people would be
> interested in. However, it requires modifications to
> Template, lest I have to write my own parser for the same
> format that Template uses.
Please test with the updated Template in SVN (1.0 RC2 should be released
very soon otherwise, maybe today). On my side, I'll think more deeply about
your proposition.
Best regards,
Jerome
