Martin Probst wrote:
>> Now that i have a really clear idea about what you are trying to do I
>> am wondering if you can do what you require with a ResourceProvider.
>> ResourceProvider's are responsible for instantiating resource classes
>> and managing the life-cycle, often they defer to the component
>> provider. They are like factories for resources.
>
> Hey, that's what I meant with the factory for resources. I admit that I
> asked my question in the probably most confusing way possible :-)
>
Well i think i should take most of the blame :-) i am trying to
multi-task on too many things!
> I'll try that out and update my article accordingly.
>
>> But this will not work for the POST method you presented in the Books
>> class. However, you could do this:
>>
>> Book b = new Book();
>> provider.inject(b); // Perhaps you don't need to inject for using
>> Book as an representation ?
>> book.setFields(...);
>> session.persist(book);
>> return book;
>
> I will need to inject, as I currently plan to have a "getURI()" method
> in all my resources, so I can easily link to them in the views. And that
> of course needs a UriInfo. Or does it?
If you could access UriInfo from your templates would that work? I can
easily add it as a "standard" property, as i do for the model. BTW you
can access the servlet request/response using "_request" and "_response".
> I only need the UriInfo for host,
> port and scheme
More accurately would it be the base URI the application is deployed at?
> - simply instantiating a UriBuilder gives URLs like
> "//:-1/...". Is that a bug (I think I've seen it behave differently)?
Can you send code to how you are building? For example i can build a
relative path as follows:
UriBuilder.fromPath("rel").path("sub).build();
IIRC there might have been an issue that i fixed, but my memory is a bit
hazy on the matter.
> If
> yes, how would I create a relative link?
>
>> One way to avoid this is to return the URI to the book you created.
>> Use Response.created(URI). For browsers you may have to do a redirect
>> (303 i think using Response.seeOther). The disadvantage is of course
>> that it requires another GET by the client.
>
> I think it's accepted to do it this way. Is there a recommended way to
> separate the two cases - Created vs. See other for browsers vs.
> automated clients?
>
Ideally there should be just one way. For example, a browser that
receives a 201 created with no content and a Location header would
perform GET from the URI declared in the Location header. IIRC firefox
does not do this. Unfortunately i think we have a split :-(
One way you could hide things underneath is to have a servlet filter
that checks the User-Agent and converts a 201 (Created) to a 303 (See
Other).
Another solution is to use 303 when HTML is acceptable and a 201 otherwise.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109