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, initialize, isInstanceOf, isRoot, newAdapter, newObject, redirect, setNext, setPrevious, setRoot, toStringpublic ExtendedDocumentsObject()
Copyright © 2015 Nuxeo SA. All rights reserved.