hi andreas, hi solprovider!
Andreas Hartmann wrote:
[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).
when i evaluated lenya, i tried to understand its workings, and i
concluded that the xml configuration files and xslts visible to me are
powerful and flexible enough for me to get the job done. i had never
even looked at the java source until this week. so i'm pretty much the
type of user solprovider has described.
i think in terms of cocoon when i design our new site, and then dig
through lenya in order to make it editable by users in a sane way. but
personally, all i ever want to touch are sitemaps, matchers,
aggregators. i'm your angled-bracket kinda guy. braces give me the creeps.
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.
for me, the generators and transformers that are already there are
sufficient. i only touch the xsl, not the transformer code.
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.
it's usually bad form in mailing lists, but: ME TOO! :-D
== 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.
sure. but i can't do it. it's exactly as solprovider characterized it: i
perceive such issues as limitations of the platform and/or my
understanding of it, so i try to work around it with the tools of my
trade. hence xslt, hence my approach to the config file format i suggested.
== 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.
ahem. i build and maintain networks and security infrastructure. my
multi-way firewall is created using a load of bash scripts. my servers
and raid arrays look after themselves thanks to scripts. do you want to
question my manhood, earthling?
;-)
to exaggerate a little bit, i don't care about code quality in lenya. i
care about decent data structures in my xml content and my stylesheets.
currently i'm using a very-poor-man's cocoon clone i've written three
years ago (in php3! YUCK!). it sucks, but it works and i don't care how
ugly it is, because my data is clean and i can drop it into cocoon
without modifications any time i feel like it. that's what i care for.
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.
agreed. i'm not whining that the code isn't there yet. i was howling at
your earlier statements, which seemed to imply that users will always
have to write java code to get things done.
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.
would be really nice, but a little beside the point imho. let's not use
up too many resources for this. lenya is not a cms for home users. you
will always have a lenya admin and lenya editors.
let's make life easy for editors with a spiffy gui. this has already
come a long way.
as to the admin, don't get in their way. let them customize to their
heart's content, give them control. no gui needed for that, just
documented and commented xml/xslts. (a gui would be nice at some point
to widen lenya's appeal, but it should not eat up resources that were
better spent on the infrastructure.)
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.
be able, yes. have to (even in common cases): noooo.
== 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.
great. can some java guru spare a little time for this? i tried on my
own and gave up for now. if it were so easy as in the example snippet
you posted (publication.setName(...);
publication.setDescription(...);), i think i could do it.
but right now the instantiator does ugly patching (which could have been
done more cleanly with an xslt).
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.
in fact, currently it's worse than that: it always uses the *default*
config for ac.
Yes, of course.
agreed.
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.
sounds frightening.
--
"Open source takes the bullshit out of software."
- Charles Ferguson on TechnologyReview.com
--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: [EMAIL PROTECTED], Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
