On 2/23/06, Andreas Hartmann <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > I am a little confused about how this would work, and doubt any
> > existing code would handle it properly. The code must check inherited
> > Templates, and that is a Lenya-specific feature. Three Templates
> > could have identically named Modules; this Publication only cares
> > about the Module it inherits.
>
> IMO we shouldn't support this, at least not at the moment. I think
> module dependencies should be resolved during compile time. Publication
> templating is IMO a runtime concept, at least this is what I had in
> mind when I implemented the first steps (creating several versions of
> the same publication, maybe overriding some XSLTs / pipelines)
> A publication instance shouldn't be allowed to declare additional
> modules.
>
> If we clearly separate compile time dependencies (which could be
> resolved using Gump) and runtime dependencies (instance -> template)
> there shouldn't be a problem.
>
> As soon as we've got this working properly we can think of adding
> runtime dependencies (hot-deploying modules, OSGi, ...), but IMO
> it's too early for that.
>
> > Missing modules is a completely different issue. Lenya will run
> > without a Module.
> IMO the build should fail if a required module is missing.
I am still confused. I may need to look at how "Lenya Modules" are
being implemented. Are you thinking of them like Cocoon's Input and
Output Modules? Java code that requires compilation for use? That
sounds much less useful, flexible, and easy to implement or modify
than what I was expecting.
I thought Lenya Modules were the evolution of Usecases: one directory
under {pub}/modules for each function. The entry point for each is
{pub}/modules/{moduleID}/sitemap.xmap. Depending on the purpose and
the parameters, Modules return a binary file "Asset", an HTML "Page",
or (most often) an XML "Document", all handled with XMAPs, XSL, XSP,
XML, and JS. Of course the XMAP can use various Generators,
Transformers, Serializers and other stuff compiled from Java, but
everything in the Module is interpreted for easy updates.
With this architecture, inheritance is simply checking the parent
templates until each file is found. Most of the "live" Module is at
the global level, but "page2xhtml.xsl" can be overridden by each
Publication.
Is this close to your concept of Modules, or should this
implementation still be called Usecases?
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
