Jörn Nettingsmeier wrote:
Andreas Hartmann wrote:
If the reason for the configuration options is that the API required
for implementation is too complex and too hard to understand, than
I'd prefer to simplify and clean up the API.
agreed.
do you think it could ultimately be made so friendly that i can just
look at one .java file without actual java or api knowledge, discover
patterns in it recognize stuff i know from elsewhere (like object
properties having the same name as xml elements in config files etc.)
and make useful (if simple) modifications at once?
I imagine something like the JCR API, but more high-level (documents
and meta data instead of nodes and properties, adding workflow
functions, notification etc.)
You'd read the API documentation, component diagrams and some
tutorials to get started.
[...]
Do you mean the fact that the publication's name and description are set?
IMO this is generic enough to implement it as the default behaviour.
nothing is ever "generic enough".
Exactly my words. Not generic enough for everything, but generic enough
to use it as a default.
if a default behaviour can't be
overridden, it's a bug. ("bug" being anything that requires touching
java, as per solprovider's very useful definition.)
:)
Imagine a Lenya application where you want to insert data from a custom
business application into a SAX stream. This requires writing a transformer.
Is this a bug?
If you want to change it - why not override the Java class? That's
done in a few minutes, if the base class is designed for inheritance
(small methods, template methods etc.)
it's good to know that this is so easy. but in my world, you don't write
custom code. you provide patches/enhancements that are so well designed
and generic that the developers will want to include it into their tree.
IMO lots of very good patches have been provided in this project as well.
We have a lot of nice functionality. But I haven't yet finished a project
without writing custom Java code.
[...]
Like so often, it's about people and not about the code :)
but users will take my path by default. the first thing you see is the
gui, then you read sitemaps, then you change xslts, then you change
sitemaps. this comes natural.
otoh, trying to grok and hack on the java code means crossing a huge and
frightening barrier.
For me it's the other way round. Before dealing with scripting and
configuration options which I'm not familiar with, I look at the Java
API of a product to learn about the architecture. I rather use the top-down
approach when I'm confronted with a framework.
<snip>
imho the servlet should provide all necessary functions (the
"mechanism"), but it should not second-guess the user's needs and
implement one particular behaviour ("policy").
the instantiator needs to be so general that most lenya users never need
to touch it. all its power must be accessible through the config file.
Hmmm, I don't share this opinion. We followed this strategy for a long
time, and it caused a lot of problems.
can you point me to mailing list threads where i can learn more about
these problems?
I rather know them from my own projects and from workshops with customers.
Some examples:
Notification
Many people ask how to enable notification. There is a configuration file
(notification.xconf), which allows to configure certain messages and supports
some basic tags, e.g. to include the published document's URL. When a customer
wants additional information (e.g. the publishing time) in the mail, or wants
to specify a CC to the manager, or send messages using IRC, you can tweak and
extend the configuration options. But this is a never-ending story.
Workflow
The workflow provides configuration using an XML file. We chose this option
(in favor of implementation) because we thought limiting to DFAs is not a
problem in a CMS application. People ask how they can add notification actions,
custom conditions and other functionality to workflow transitions. This is just
not possible in some casese, because the configuration is not sophisticated
enough (you can't pass custom parameters etc.). The workflow description
languages I'm aware of which are capable of such things are so complex it
takes days to get a basic grasp of them.
Tasks
We made tasks configurable and nestable instead of requiring to implement
them as components. I already mentioned some of the disadvantages.
I'll try to find some threads in the mailing list archives.
[...]
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
