[EMAIL PROTECTED] wrote:
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?
No, rather like Cocoon blocks.
> Java code that requires compilation for use?
Yes, they can contain Java code. But dependencies have to be checked
even if there's no Java code.
That
sounds much less useful, flexible, and easy to implement or modify
than what I was expecting.
Why?
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.
No, that's not the way it works at the moment. A module can provide
Java code and libraries as well, it has to be deployed on compile time.
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?
As I understand it, you're describing functionality offered by
resource types (generating assets / pages), modules (providing
arbitrary resources and classes), and usecases (classes and templates
for user interaction). Modules can contain resource types and usecases.
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
[EMAIL PROTECTED] [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
