Den 29. feb.. 2008 kl. 12.13 skrev Paul Sandoz:
> Marc Hadley wrote:
>>> Maybe I haven't understood the model good enough, but the second
>>> problem I have is that the jsr-311 model seems to dictate a
>>> duplication of the domain model in a seperate resource layer on
>>> top. All my resource objects need to know the mapping between the
>>> domain objects and the correponding resource objects containing
>>> the annotation mapping (and usually som hard coded path attibutes
>>> as well) for every link it is to generate.
>>>
>> See the UriBuilder.fromResource and UriBuilder.path(Class) methods.
>> These allow you to generate URIs without duplicating the value of
>> @Path annotations. Is that the kind of thing you are looking for ?
>>
>
> What we are missing is a way to get access to 'breadcrumbs', namely
> the list of URI paths that have been used in the hierarchical
> matching stages *and* the resource instances associated with those
> URI paths.
>
> I still think there is some more innovation required for better
> representation formats than handle links. I wonder if it is possible
> to have a general link-aware JAXB processing step, that takes a JAXB
> bean and transforms some field values to URIs (or relative URIs to
> absolute URIs).
Paul probably makes more sense than me, but I'll try to explain in a
bit more detail.
I have been using UriBuilder.fromResource, but in practice I haven't
seen an example where it adds any more real value than a hard coded
string would have. I still have to manually map model objects to
resource objects. And even if I do that, I have to map the correct
object property to specific uri constructs (in "/path/{id}", what is
the id of the returned object?).
As an example, look at the storageservice example, where you rely on
providing the container uri in the constructor. If it was easy to
avoid that, I guess you would have done it? I'll elaborate a bit more
in the bottom from my own app [*].
Since the annotations are on a seperate layer above the objects
returned in the model, I don't see how there's any way to automate the
link construction. The classes containing the annotations seems to be
too disconnected from the real objects (and properties) they represent
(that are the ones to be serialized). I might be trying to fit a
rather big square into a round hole, but what I really would like is
(from the top of my head):
1) A way to give domain objects a primary url, by explicitly linking
them to a resource (and corresponding properties, might use
conventions on names?)
2) Make the uri building more automated/complete, by applying the
conventions (no need for explicit uri building)
3) When serializing, have a "conventionalized"/configurable way to add
urls to the result
In 1), what I would really like is for domain objects to be annotated
directly (no need linking things that represents the same object), but
I suspect that it would be hard to figure out how to do that in a
clean way.
Jo
[*] A simple app with projects, researchers, units and publications
(all with corresponding path mappings). In the most basic case, they
are just gotten by id:
@Path("/projects/")
public class ProjectsResource {
@GET
@Path("{id}")
public Project getProjectById(@PathParam("id") String id) {
Projects links to researchers, units and publications. To make the
resulting xml contain urls to these resources, i need to iterate
through the projects' researcher/unit/pub sets and generate urls based
on the objects' resource representations, and manually add the correct
id (taken from the current object in some way).
The same goes when I access all the other resource types, So for both
researcher, project and publication, I need to do the same manual
creation of urls to unit..
I haven't found any hints to how this could be done more elegantly in
the examples or on the list, so I'm guessing this is more or less how
to do it for now?