I can imagine a somewhat convention driven approach but I think it
would hard to avoid some kind of configuration to link a resource and
model classes.
E.g. we could have a @Controller annotation that identifies the model
class for a resource. We could then use a convention driven approach
to identify the mapping between @Path parameters and properties of the
model. If the model class is a JPA entity bean the we could use the
@Id annotation to extract a unique identifier. A utility class could
create an initialized UriBuilder instance from a model class
automatically. An example:
@Entity
@Table(name = "WIDGETS")
@ResourceClass(WidgetsResource.class)
public class Widget implements Serializable {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
@Column(name = "ID", nullable = false)
private Integer id;
...
}
@Path("widgets/{id}")
public class WidgetsResource {
@GET
...
}
Widget widget = ...
URI widgetUri = UriBuilder.fromModel(widget).build();
The fromModel method identifies WidgetsResource as the applicable
resource class for this model by inspecting the value of the
@ResourceClass annotation. It then extracts the URI template from the
@Path annotation and builds a URI by substituting the value of
Widget.id into the template.
Is that the kind of thing you are looking for ?
Marc.
On Mar 1, 2008, at 5:05 PM, Jo Størset wrote:
>
> 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?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.