Stefan Tilkov wrote:
> Is there some more information about the @Views annotation used in the
> Jersey Bookstore example?
>
It is an experimental feature of Jersey (hence the com.sun.* package)
for associating a view, say to produce HTML, with a resolved Java
object. Views are connected to the URI path of the resolved Java object
(equivalent to index.<view>) or as a sub-resource (e.g. could use such
views for forms, such as edit.<view>).
It is designed to be pluggable and there is an implementation for JSP (i
also implemented one for Jelly scripts, but Jelly is not widely used)
and would like to experiment with Velocity or integrating other
languages for views (e.g. Groovy). See the com.sun.ws.rest.spi.view
package and the com.sun.ws.rest.impl.container.servlet for the JSP
implementation.
The view information can be linked to the package namespace of the
resolved Java object and the view has access to that Java object as the
'it' variable. (It is possible but i have not implemented it for the
view to have access to the resolved path of Java objects, this can be
good for breadcrumbs support).
If using a good view technology one could provided pluggable web
applications that have their own views. Theoretically one could upload a
pluggable component to a web application and it would dynamically
incorporate the extension into that application (without requiring a
redeploy).
The idea for views was taken from Hudson [1] and Stapler [2] (as was the
Bookstore example).
I don't know if this kind of thing is suitable for the JSR (i suspect
not, i think it requires more investigation) but at least we can
experiment. What do you think?
All this requires more work! (help required!) Ideally i would like to
remove the View annotation and let the runtime pick up the views by
convention based on the resolved Java object (it possible to implement
but i have not had the time...).
Paul.
[1]
https://hudson.dev.java.net/
[2]
https://stapler.dev.java.net/
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109