Differences between revisions 27 and 28
Revision 27 as of 2005-10-02 22:12:24
Size: 7431
Editor: 106
Revision 28 as of 2009-09-20 23:27:54
Size: 7431
Editor: localhost
Comment: converted to 1.6 markup
No differences found!

Note: the term Publets has been replaced by the term Modules, see LenyaModules for updated info.


{{{A Publet provides crosscutting functimonality, which can be plugged/pulled into a Publication. A Publication may use various Publets to assemble/aggregate a website and its content.}}}

A Publet uses the Lenya API to access workflow and other cms services in order to supply and manage its individual content services.


  • 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

Integration into the Lenya architecture

Investigate how this proposal can be implmented with the UsecaseFramework or Forrest Plugins.


A Publet needs to fulfil various contracts in order to provide "automagic" integration into Lenya.


Basically, a publet could be assembled using the following directory structure:




                /publet.xconf                         General configuration
                /usecases.xconf                       Patch file for cocoon.xconf to insert usecase declarations
                /*.xconf                              Other cocoon.xconf patches

            /documentation                            Documentation (Forrest document, can be included in main documentation)

            /resources                                Resources

            /java                                     Java code

            /lenya                                    Resources to use the fallback mechanism (e.g., usecases)

            /publet.xmap                              Sitemap to render resources

A publet comes with a predefined set of menu items which are placed in a certain location.

The following menu is an example for an XHTML resource type publet:


  <menu id="document">
    <menu id="create">
      <item available="global" uc:usecase="site/create" href="?resourcetype=xhtml">New XHTML document</item>
    <item available="publet" uc:usecase="site/deleteDocument">...
    <item available="publet" uc:usecase="site/createLanguage">...
    <item available="publet" uc:usecase="site/deleteLanguage">...

  <menu id="edit">
    <item available="publet" uc:usecase="edit/kupu" href="...">Kupu</item>


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 publets can contain the same menu item.

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 publet.

When a publication uses the XHTML resource type publet and the Docbook resource type publet, the resulting menu could look like this:


  <menu id="document">
    <menu id="create">
      <item uc:usecase="site/create" href="?resourcetype=xhtml">New XHTML document</item>
      <item uc:usecase="site/create" href="?resourcetype=docbook">New Docbook document</item>
    <item uc:usecase="site/deleteDocument">...
    <item uc:usecase="site/createLanguage">...
    <item uc:usecase="site/deleteLanguage">...

  <menu id="edit">
    <item uc:usecase="edit/kupu" href="...">Kupu</item>
    <item uc:usecase="edit/BXE" href="...">BXE</item>


Using Publets in Publications

The publets used by a publication are declared in publication.xconf:


   <publet id="blog"/>
   <publet id="calendar"/>


Resolving Publets

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 publets:

  • XHTML resource type
  • Calendar publet
  • news publet

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 publet menus. When a usecase is invoked, the appropriate resource has to be passed as a parameter.

Another possibility is that the usecase resolves te appropriate resource on its own, depending on the current URL. But this would imply that only one publet of a type may be used on a page.


The fallback concept has to be extended to publets:

publet -> publication -> (publication templates) -> core

The PubletResolver Component

One possibility would be to use a PubletResolver component which would act similarly to the DoctypeResolver by delegating the request to the URIParameterizer. Actually the DoctypeResolver would be a specialization of the PubletResolver.

URL Prefix

A publet could be determined by a custom URL prefix:


This would have the drawback of a reserved URL space. The approach could be implemented using a URLPubletResolver.


The fallback concept for usecases could easily be extended to support publets. The UsecaseResolver would be responsible to check if the usecase is overridden by the current publet.

ProposalPublets (last edited 2009-09-20 23:27:54 by localhost)