Jörn Nettingsmeier wrote:
[...]
== 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?
Sorry, my wording was not correct - I didn't mean that robustness can't
be achieved using script languages. But, imagine the environment you're
describing is maintained by developers all over the world who hardly
know 20% of the code and don't care about the other 80%. You have to
let them tweak some stuff without breaking anything else. When you change
something, they have to be informed that they have to update their
customized code, preferrably without reading the SVN logs. They want
auto-complete when typing something, they want mouse-over code documentation
(as it is provided by Javadocs). IMO that's where compiled languages excel.
[...]
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).
IMO it doesn't make sense to add that to the existing API, because it
is not designed to modify publication configurations during run-time.
We should take care of it in the new repository API.
[...]
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.
Why? IMO polymorphism is a key concept when you work with frameworks.
Delegation and configuration won't be sufficient in all cases.
You have to find a way to make it manageable.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
