LenyaModules
- TARGET-AUDIENCE: *dev*
- LENYA-RELEASES: 2.0.x
- DOCUMENT-STATUS: *draft*
Note: the term Module was previousely called Publets, see ProposalPublets for background info.
ModuleDefinition
{{{A Module allows you to implement crosscutting functionality, which can be plugged/pulled into a Publication. A Publication may use various Module to assemble/aggregate a website and its content.}}}
A Module uses the Lenya API to access workflow and other cms services in order to supply and manage its individual content services.
ImplementedModules
- JCR
- Lenya Doc
- Links
- Notification
- Search
- Sitetree
- Xhtml
- Homepage (in default publication)
- ODT (open office document type)
PossibleModules
- Blog Publet
- Press Release Publet
- Phonebook Publet
- Calendar Publet
- Default Publet
- Project Management Publet
- DMS (Document Management) Publet
- Newspaper Publet
- Wiki Publet
- Newsletter
- Poll/Vote
- Form-To-Email Publet
feel free to add more here
Configuration
Here is a basic directory structure of a module, with frontpage as an example:
/lenya
+-modules
+-frontpage
|
+-config
| +-menus/ For automatic Lenya menu
| | +-frontpage.xsp generation ("create new frontpage")
| +-module.xconf General configuration
|
+-samples/ Sample template that will
| +-frontpage.xml be used to create a new frontpage
|
+-java/ Java code
|
+-ressources Ressources (images, css, ...)
|
+-xslt/
| +-frontpage2xhtml.xsl To render this module
|
+-menu.xmap Menu rendering
+-sitemap.xmap Main module sitemap
Menu Items
By configuring a the module's config/menus/frontpage.xsp, you can add your custom items to the Lenya menu:
<menu>
<menus>
<menu i18n:attr="name" name="Edit">
<xsp:logic>
String doctype = <input:get-attribute module="page-envelope" as="string" name="document-type"/>;
if ("frontpage".equals(doctype)) {
<block info="false">
<item wf:event="edit" uc:usecase="edit.bxe" href="?"><i18n:text>With BXE</i18n:text></item>
</block>
}
</xsp:logic>
</menu>
</menus>
</menu>The menus of all available publets are merged. Duplicate items, which means that all attributes and the item title are equal, appear only once. This way, several modules can contain the same menu item. TBD
The attribute item/@available denotes if the menu item should be available in menus of all pages or only in menus of pages which are handled by this module. TBD
Using different samples (templates)
TBD
Render Type
TBD
Using Modules in Publications
To use a module, you have to declare it in config/publication.xconf:
<publication> ... <resource-type workflow="workflow.xml" name="frontpage"/> ... <module name="frontpage"/> ... </publication>
Overriding a module
TBD
Discussion
PubletImplemenationContracts
A Publet needs to fulfil various contracts in order to provide "automagic" integration into Lenya.
Resolving Modules
We need a concept to determine if a request should be handled by a publet. This is related to the concept of aggregating a page from several resources. Let's create a simple example:
+------------------------------------------------------------------------+ | | | | XHTML document | Feb 2005 | | | 1 2 3 4 5 6 | | | 7 8 9 10 11 12 | | | ... | | | | | |------------------| | | | | | NEWS | | | | | | ... | | | ... | | | ... | | | | | | | | | | | | | | | | +------------------------------------------------------------------------+
This page contains resources managed by 3 modules:
- XHTML resource type
- Calendar module
- news module
This means that we need the appropriate menu items for all resources. When the menu is created, all resources available on the current page have to be determined. The menu is aggregated using the corresponding module menus. When a usecase is invoked, the appropriate resource has to be passed as a parameter.
Another possibility is that the usecase resolves the appropriate resource on its own, depending on the current URL. But this would imply that only one module of a type may be used on a page.
Fallback
The fallback concept has to be extended to modules:
module -> publication -> (publication templates) -> core
The ModuleResolver Component
One possibility would be to use a ModuleResolver component which would act similarly to the DoctypeResolver by delegating the request to the URIParameterizer. Actually the DoctypeResolver would be a specialization of the ModuleResolver.
Usecases
The fallback concept for usecases could easily be extended to support Module. The UsecaseResolver would be responsible to check if the usecase is overridden by the current Module.