public class ExtendedDocumentsObject extends DocumentsObject
base=BaseModule in the
NuxeoWebModule directive in MANIFEST.MF file. This
way the new module will inherit all templates and resources defined in the
base module. You can thus create a chain of inherited web modules.
Here is how template resolution will be impacted by the module inheritance:
If a template T is not found in skin directory of derived module then
search the template inside the base module and so on until a template is
found or no more base module exists. The view resolution is similar to
the template one but it will use the WebObject inheritance too:
Note that only the skin directory is stacked over the one in
the base module. The other directories in the module are not inheritable.
Also, resource types defined by the base module will become visible in the derived one.
In this example you will also find a very useful feature of WebEngine: the
builtin view service adapter. This adapter can be used on any web
object to locate any view declared on that object. Let's say we define a view
named info for the Document WebObject type. And the following
request path will point to a Document WebObject: /my/doc. Then
to display the info view we can use the builtin views adapter this
way: /my/doc/@views/info.
Obviously, you can redefine the WebObject corresponding to your document type
and add a new method that will dispatch the view /my/doc/info. But this involves changing code.
If you don't want this then the views adapter will be your friend.
This example will extend the resource defined in sample4 and will reuse and add more templates. Look into template files to see how base module templates are reused.
Almost any template page will contain links to other pages in your application. These links are usually absolute paths to other WebObjects or WebAdapters (including parameters if any). Maintaining these links when application object changes is painful when you are using modular applications (that may contribute new views or templates).
WebEngine is providing a flexible way to ease link management. First, you should define all of your links in module.xml configuration file. A Link is described by a target URL, an enablement condition, and one or more categories that can be used to organize links.
AND will be used between
them.
Apart conditions you can group links in categories. Using categories and conditions you can quickly find in a template which are all enabled links that are part of a category. This way, you can control which links are written in the template without needing to do conditional code to check the context if links are enabled.
Conditions and categories manage thus where and when your links are displayed in a page. Apart this you also want to have a target URL for each link.
handler</handler> link attribute.
The handler will be invoked each time the link code need to be written in the output stream so that it can programatically generate the link code.
path
attribute you specified in link definition to the current WebObject path on
the request. This behavior is good enough for most of the use cases.
This example will demonstrate how links work. Look into
module.xml for link definitions and then in
skin/views/Document/index.ftl on how they are used in the
template.
| Constructor and Description |
|---|
ExtendedDocumentsObject() |
| Modifier and Type | Method and Description |
|---|---|
Object |
getInfo()
We are reusing bindings declared in the main class from sample5 and only
add a new one.
|
doGet, getRepositoryViewdisptachAdapter, isAdaptercheckGuard, 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, toStringpublic Object getInfo()
Copyright © 2011 Nuxeo SA. All Rights Reserved.