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:
GETto get a view on the DocumentObject
POSTto create a DocumentObject
PUTto update a document object
DELETEto 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
DELETEmethods 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:
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
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:
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 is an important aspect in order to correctly understand the behavior of the
$This object exposed in templates.
skindirectory. Views may live in two places:}
Baseand a resource of type
Derivedthen all views defined on type
Baseapply on type
Derivedtoo. You may override these views by redefining them on type
view_id + [-media_type_id] + ".ftl"The
media_type_idis 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
indexwhen the response media-type is
application/atom+xmlyou can define a mapping of this media type to the media_type_id
atomand then you can use the file name
index-atom.ftlto specify a specific index view when
atomoutput is required.
|Constructor and Description|
|Modifier and Type||Method and Description|
Get the index view.
Get the WebObject (i.e.
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 © 2011 Nuxeo SA. All Rights Reserved.