public class BasicsObject extends DefaultObject
These adapters are useful to add new functionalities on Web Objects without breaking application modularity or adding new methods on resources. This is helping in creating extensible applications, in keeping the code cleaner and in focusing better on the REST approach of the application. For example let say you defined a DocumentObject which will expose documents as JAX-RS resources. A JAX-RS resources will be able to respond to any HTTP method like GET, POST, PUT, DELETE. So let say we use:
GET
to get a view on the DocumentObject
POST
to create a DocumentObject
PUT
to update a document object
DELETE
to delete a DocumentObject.
@GET @Path("lock") getLock()
or @POST @Path("lock") postLock()
.
But this approach is not flexible because you cannot easily add new functionalities on existing resources in a dynamic way.
And also, doing so, you will end up with a cluttered code, having many methods for each new aspect of the Web Object you need to handle.
To solve this problem, WebEngine is defining Web Adapters, so that they can be used to add new functionality on existing objects.
For example, to handle the lock actions on an Web Object we will define a new class LockAdapter which will implement
the GET
, POST
, DELETE
methods to manage the lock functionality on the target Web Object.
Adapters are specified using an '@' prefix on the segment in an HTTP request path. This is needed by WebEngine to differentiate
Web Objects from Web Adapters.
Thus in our lock example to request the lock adapter on an object you will use a request path of like the following:
GET /my/document/@lock
or POST /my/document/@lock
etc.
When defining a Web Adapter you can specify on which type of Web Object it may be used. (this is done using annotations)
There is a builtin adapter that is managing Web Objects views. The adapter name is @views
.
You will see in the view model an example on how to use it.
Thus, request paths will be resolved to a resource chain usually of the form: WebModule -> WebObject -> ... -> WebObject [ -> WebAdapter ].
Each of these resource objects will be served using the sub-resource mechanism of JAX-RS until the last resource is reached.
The last resource will usually return a view to be rendered or a redirection response.
The request resource chain is exposed by the WebContext object, so that one can programatically retrieve any resource from the chain.
In a given resource chain there will be always 2 special resources: a root and a target resource
The root resource is exposed in templates as the Root
object and the target one as the contextual object: This
.
Note that the root resource is not necessarily the first one, and the target resource is not necessarily the last one!
More, the root and the target resources are never WebAdapters. They can be only WebObjects or WebModule entry points
(that are aspecial kind of WebObjects).
The root resource is by default the module entry point (i.e. the first resource in the chain) but can be programatically set to point to any other WebObject from the chain.
The target resource will be always the last WebObject resource from the chain (so any trailing WebAdapters are excluded).
This means in the chain: /my/space/doc/@lock
, the root will be by default my
which is the module entry point,
and the target resource will be doc
. So it means that the $This
object exposed to templates (and/or views) will
never points to the adapter @lock
- but to the last WebObject in the chain.
So when an adapter view is rendered the $This
variable will point to the adapted WebObject and not to the adapter itself.
In that case you can retrieve the adapter using $This.activeAdapter
.
This is an important aspect in order to correctly understand the behavior of the $This
object exposed in templates.
skin
directory. Views may live in two places:}
Base
and a resource of type Derived
then all views
defined on type Base
apply on type Derived
too.
You may override these views by redefining them on type Derived
view_id + [-media_type_id] + ".ftl"The
media_type_id
is optional and will be empty for media-types not explicitly bound to an ID in modules.xml configuration file.
For example, to dynamically change the view file corresponding to a view
having the ID index
when the response media-type is application/atom+xml
you can define a mapping of this media type to the media_type_id atom
and then you can use the file name
index-atom.ftl
to specify a specific index view when atom
output is required.Constructor and Description |
---|
BasicsObject() |
Modifier and Type | Method and Description |
---|---|
Object |
doGet()
Get the index view.
|
Object |
getUserManager()
Get the WebObject (i.e.
|
disptachAdapter, isAdapter
checkGuard, dispose, getActiveAdapter, getAdapter, getContext, getFacets, getLinks, getModule, getName, getNext, getNextSegment, getPath, getPrevious, getTemplate, getTrailingPath, getType, getURL, getView, hasFacet, initialize, isInstanceOf, isRoot, newAdapter, newObject, redirect, setNext, setPrevious, setRoot, toString
public Object doGet()
public Object getUserManager()
Copyright © 2013 Nuxeo SA. All Rights Reserved.