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 © 2015 Nuxeo SA. All rights reserved.