Why Plugins

• Seperate Functionality from core
• Create a 3rd party plugin ecosystem

Technical foundation

• can likely be implemented using UsecaseFramework

• fallback:/ pseudo protocol
• XPatch at runtime (???)

Problems

• Extension versus inheritance

To be clarified

• What does a plugin consist of
• How should plugins be handled in Lenya
• Do plugins apply only to authoring or to live as well?
• Are plugins the same as blocks in Cocoon?

Project decisions

• Should plugins be a compile time or a runtime feature?

Prototyping Plan

(by J. Wolfgang and Torsten (without "h"))

• Define a PluginExperimentPublication in trunk

• Implement a publication specific generic (i.e. editor independent) EditDocument usecase which will use a EditPlugin through a well defined interface (contract) to handle the actual editor (see below)

• Implement a publication specific LenyaCMSMenuGenerator Avalon component which

  • will read an XML file with structure similar to the result of today's Default publication generic.xsl.

  • will replace placeholders in the XML menu skeleton with menu options supplied by plugins: for example EditorPlugins

  • the rest of the menu.xmap pipeline will remain unchanged for now

• Develop a publication specific BXE EditorPlugin as an example to proof the concept