On 2/24/06, Andreas Hartmann <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > 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.
I think I understand the disconnect. In Lenya 1.2, we can add most
functionality simply by adding a Usecase. The Usecase can contain
XMAPs, XSL, XSP, XML, and JS (Flow). We can build complex
applications with those components. I have not found a function that
cannot be implemented with these components. As soon as the hook is
added (usecase-function.xmap), the function is usable. As soon as a
change is made, it is active. None of this requires compiling or
restarting Lenya.
These Usecases depend on the Lenya platform for certain things:
- Generators, Transformers, Serializers and other elements of XMAPs
- Various protocols for retrieving data.
- Some standard functions implemented in XMAPs that could/should be
moved to Usecases.
http://lenya.apache.org/1_4/reference/modules/index.html
suggests that Modules will be able to add protocols. Protocols are
part of the platform and should not be added dynamically. Anyone
adding a protocol would have a development environment.
Lenya has been usable and very flexible without a development
environment. A binary version of Lenya is very flexible. I realize
that most Committers and some Developers have a development
environment, but most Developers do not, and should not, need one.
If Modules can contain Java, then:
1. Every Lenya Developer must have a development environment.
2. We have the dependency issues that started this thread.
I cannot see how it is good to force Users to install a development
environment. It increases the complexity and reduces the audience.
Lenya should become both easier and more powerful. Modules including
Java that needs to be compiled is a step in the wrong direction.
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
