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