On 11/22/05, Renaud Richardet <[EMAIL PROTECTED]> wrote:
> Let's say I have a pub called mypub, with the default pub as template. I
> would like for example to disable "edit with Kupu". For that I have to
> create a file mypub/lenya/modules/homepage/config/menus/homepage.xsp and
> modify it, correct? So, the logic is: put new modules under
> mypub/modules and override existing modules in mypub/lenya/modules, correct?
>
> Another point: what would you use as a convention to name module? Since
> they are all copied in the same dir during the build process, the name
> must be unique. Also, modules have very different functionalities (eg
> homepage to implement a new ressource type and lucene to implement the
> whole indexing logic). Does it makes sense to have them all at the same
> place?
These are my guesses about how modules will eventually be implemented.
I believe all modules should be in the same place so configuration
and replacement is standardized. This is a great improvement over the
old design of separating files by type (mentioned again at the
bottom.)
Default modules will be at the server level. "admin", "bxe", "kupu",
"login", "search", "xhtml", "xhtml-homepage" are standard functions
available for all publications.
Configuration of which modules are included is decided by a conf file
in each publication. It should set the default for modules not
listed:
<modules default="include">
<exclude module="bxe" />
</modules>
Modules are overridden for a publication by copying them into the
{pub}/modules directory. If programmed well, only the modified files
would be included in that directory; otherwise the entire module would
be copied. Of course new modules would need all their code.
Example: page2xhtml-homepage.xsl should be the only file in the
xhtml-homepage module.
Naming only matters when overriding a server-wide module. Each
developer can choose their own naming convention, until the module is
submitted for inclusion with Lenya.
In Lenya 1.2, "login" is not an overridable module. To replace it, I
created a "session" module (actually Usecase). When "login" is a
module, I can replace it by creating a "login" module within the
publication.
- Under the old structure, login used an XSL and an XSP file, each in
a different directory. Under the new structure, my login module would
keep the 4 XML files (for Flow), the JS file, the XSLs, and even the
XMAP (currently usecase-session.xmap) all in the same directory.
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
