[EMAIL PROTECTED] wrote:
[...]
I think you are discussing the different attitudes between "Lenya as a
Platform" and "Lenya as a Base for Development".
I'm discussing the use of Lenya as a framework, which means developing
CMS applications using Lenya. Maybe there are users who want to use it
"out of the box" without customization, but I doubt that Lenya is the
right tool for this job (except you're so lucky that the default publication
is just what you were looking for).
Most users treat it as a Platform. Just configure and use (and many
will skip step #1.) If there is a bug, complain and hope it is fixed
in the next release.
Users who change the Java become developers.
I don't think so. I'd rather compare Lenya to Cocoon - if you're implementing
a generator or a transformer, you're still a Cocoon user. The same should
apply to Lenya. Implementing an instantiator is just using the framework.
Some of the core team
expects everybody to want to be a developer. As any software gains
popularity, the ratio of users-to-developers increases. The
popularity of software is based on usability by non-developers. For
Lenya to increase in popularity, we must expect users to be productive
with as few skills as possible.
== Business Logic
We (my company) implemented security as XSLT, because it was not "in
the platform" (as of Lenya 1.2.2). Yes, I totally agree it was "bad
style", but it kept the division between "configuration" and
"platform", and that was more important (and much easier) than
correcting the platform functionality.
"Correcting the platform functionality" to change access control behaviour
is only necessary if the design doesn't support polymorphism well enough.
If this is the case, it should be improved.
== Lenya users: Java vs. config
Lenya should be useful without any knowledge of Java.
But only if this is possible without compromises regarding maintainability
and robustness. In my experience, it is much harder to achieve quality
when you use non-compiled languages.
Many of the
posters to the User ML barely know HTML, and are learning XSLT
specifically to configure Lenya. The attitude that any configuration
requires recompiling limits the spread of Lenya.
OK, but I, personally, would rather limit the range of application
to heavily customized enterprise level CMS than make any compromises
regarding the above quality aspects. But I still think that both
ways are possible. The Lenya core should provide a solid repository
implementation, funcionality should be added using configurable
modules. At the moment we don't have these modules, so implementing
functionality using Java is necessary.
An opposing attitude is all configuration should be available from the
GUI to limit the need for file access. Creating new publications from
the GUI (rather than copying an existing pub using the OS) is a good
step towards this goal.
I agree.
Think like a user. A problem with the XSLT can be fixed in the
publication's configuration. A problem in Java is a bug in the Lenya
platform to be worked around.
Why that? If it's a core XSLT, the problem has to be fixed in the
core. You can override the XSLT in your publication, but you should
be able to override the Java component as well.
== Ant
I thought the Ant tasks were being moved to Java to remove a
dependency, and reduce the skills required for developing Lenya. As a
user, anything hidden behind Ant is part of the platform.
Yes, this is correct. Other reasons why Ant tasks are moved to Java are:
- complexity (to many delegation layers and parameter passing)
- the bad support for error handling
- the lack of transactional behaviour
== ConfigurableInstantiator
I have not read the code yet, but no list of files should be needed.
The copy (new pub) should contain the entire "template". "Templates"
should mostly use fallback to functionality in global elements (or
other templates), so there is little custom code in new publications.
If someone has 99 pubs based on a template, a change (such as a bug
fix) to a function should change all the pubs based on that template.
I agree. Publications should use functionality provided by modules.
Upon instantiation, a custom configuration of the functionality could
be generated which applies to the new publication.
There should be a divide between function and content, but templates'
content is the sample documents already created. We may want a
"Create Template from Publication": copy the function from a
publication and generate the default content.
Anything that does not work as expected (e.g. security using old pub's
config) should be fixed to work as expected.
Yes, of course.
A different approach is for Fallback to check the current pub, then
the templates, then global. Creating a new pub would be recording the
name of the desired template (and other base information such as the
Publication Name), and creating a new datastore for content. Until
functionality is added to the publication, it defaults to the
template's functionality.
This is how it's done now. But this concept should rather apply to
presentation options like XSLTs and CSS. I think fallback becomes quite
complex for functionality like usecases etc. Here I could imagine
configuration options or polymorphism towards the module providing the
functionality.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
