Dear Wiki user, You have subscribed to a wiki page or wiki category on "Lenya Wiki" for change notification.
The following page has been changed by RenaudRichardet: http://wiki.apache.org/lenya/LenyaModules The comment on the change is: drafted new Modules page New page: ## page was renamed from PubletsProposal = LenyaModules = - TARGET-AUDIENCE: '''*dev*''' [[BR]] - LENYA-RELEASES: 1.4.x[[BR]] - DOCUMENT-STATUS: '''*draft*''' [[BR]] ---- 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. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
