org.nuxeo.ecm.webengine.samples
Class ExtendedDocumentsObject

java.lang.Object
  org.nuxeo.ecm.webengine.model.impl.AbstractResource<ResourceTypeImpl>
      org.nuxeo.ecm.webengine.model.impl.DefaultObject
          org.nuxeo.ecm.webengine.samples.DocumentsObject
              org.nuxeo.ecm.webengine.samples.ExtendedDocumentsObject

All Implemented Interfaces:

Resource, Adaptable

public class ExtendedDocumentsObject
extends DocumentsObject

Web Module Extensibility.

This sample is demonstrating how existing web modules can be extended. To extend another module you should use the 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 info using a pretty path like /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.

Managing links.

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.

Here are the possible conditions that you can use on links:
• type - represent the target Web Object type. If present the link will be enabled only in the context of such an object.
• adapter - represent the target Web Adapter name. If present the link will be enabled only if the active adapter is the same as this one.
• facet - a set of facets that the target web object must have in order to enable the link.
• guard - a guard to be tested in order to enable the link. This is using the guard mechanism of WebEngine.

If several conditions are specified an 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.

You have two choices in specifying such a target URL:
• define a custom link handler using the 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.
• use the builtin link handler. The builtin link handler will append the 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.

Author:

Bogdan Stefanescu

Constructor Summary

ExtendedDocumentsObject()

Method Summary

Object

getInfo() We are reusing bindings declared in the main class from sample5 and only add a new one.

Methods inherited from class org.nuxeo.ecm.webengine.samples.DocumentsObject

doGet, getRepositoryView

Methods inherited from class org.nuxeo.ecm.webengine.model.impl.DefaultObject

disptachAdapter, isAdapter

Methods inherited from class org.nuxeo.ecm.webengine.model.impl.AbstractResource

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

Methods inherited from class java.lang.Object

equals, getClass, hashCode, notify, notifyAll, wait, wait, wait

Constructor Detail

ExtendedDocumentsObject

public ExtendedDocumentsObject()

Method Detail

getInfo

public Object getInfo()

We are reusing bindings declared in the main class from sample5 and only add a new one.