On Mar 3, 2008, at 12:09 PM, Marc Hadley wrote:
> 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
Or even a @ResourceClass annotation that identifies the resource for a
model..
> 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.
>
>
>
> ---------------------------------------------------------------------
> 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.