[EMAIL PROTECTED] wrote:
On 1/4/06, Andreas Hartmann <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
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.
(Writing from extremely limited knowledge about Cocoon) Cocoon is a
development tool. Does it include any applications that might be
useful "out of the box"?
No, but IMO Lenya doesn't include them either. Like Cocoon, it provides
samples what the included components are capable of. But we make the
mistake of announcing the samples as complete applications.
Lenya is a CMS. The default publication includes enough to be useful
"out of the box". From the comments on the User ML, it seems many
people use it with cosmetic changes, and some do not even change the
look.
That's why I dislike the default publication. It gives the impression
that it provides everything Lenya is capable of.
I thought our goal was to make the default publication so good that
everybody will be "so lucky that the default publication is just what
[they] were looking for".
IMO this is the wrong way. The example publications should be moved
from the webapp directory to a top-level directory (like modules) to
emphasize their purpose as basic examples. In the end, modules could
ship with sample publications presenting their functionality.
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.
(Writing as someone with much experience in enterprise software)
Large companies are using Lotus Notes/Domino (over a decade of proven
usefulness for content management with versioning and many features
other software can only dream about) or Oracle (because they have
great salespeople). Some companies are trying to build CMS using
Microsoft software (because they do not know better.) Add Documentum
and other smaller players, and the few enterprises using Lenya are
those committed to OSS.
I expect Lenya to be used by small businesses looking for an
inexpensive solution. That is how I sold it. We quickly changed the
look. Then I worked around the broken security (in 1.2.2), fixed
Search, and added Register/Login, Contact Us, Sitemap, and Newsletter
functionality. The only thing that took more than a day was the
Newsletter, because it required complex programming, and I used Flow
so it could be integrated easily. (I had trouble because I never
figured out how to use Flow to modify the XML being passed back to the
XMAP.) I was able to meet our requirements without changing the core.
This is very good to hear. Changing the core shouldn't ever be required
to implement custom functionality.
I do not understand how adding configuration options reduces quality.
It does not necessarily reduce quality, but I have the impression that
it suggests people that configuration is the only option for
customization. Tasks in Lenya 1.2 are such an example - you can
configure them in tasks.xconf and in targets.xml, but you reach the
limits quite soon. You need a separate copy of targets.xml for each
publication, which is terrible.
[...]
== 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.
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.
Imagine creating a new Publication by checking a list of
functionality, choosing a layout, and attaching a few graphics (e.g.
corporate logo), all handled using the GUI. That requires a good list
of included modules. Is that a good ultimate long range goal for
Lenya?
It would be absolutely great to have something like that. But:
- With respect to the limited size of our community, it is IMO quite far
away.
- Lenya shouldn't be limited to that. It must provide an API to implement
custom functionality.
Editing XSLT and CSS using the GUI is not difficult. That will
probably be finished soon after creating new doctypes becomes easy.
Which will happen shortly after creating modules becomes easy. Which
should happen about the time 1.4 is released.
It will be good when a module uses the publication's files if they
exist, then the template's files, then the parent template's files,
continuing until it must use the global files. That could become a
maintenance nightmare, but adding the ability to gather all the files
used for the current functionality into a new template will solve
that. That would remove the ability to apply bug fixes at the various
levels, but most likely it would be used to locate the bug, then
applied to the correct file in the hierarchy.
That sounds useful, I'm curious how these things will develop.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
