(as opposed to the conceptually very clean avalon-style configuration where a component is allowed to "read" from its configuration, but the configuration itself is passive),
Biased! Biased! :-p
ROTFL! Me? Nah..... ;)
Seriously, one could only consider it conceptually very clean, don't you think?
The avalon picture
------------------
- a container is responsible for finding/creating the configuration according to preset rules (delegating this responsibility to a specialized component of course), usually allowing for various people in various roles (end users, assemblers, component writers) to follow various contracts to define the configuration,
- a configuration object is then responsible only for existing (implementing the Configuration interface)
- a component is responsible for obeying the directives provided to it by the container in the form of the configuration it receives (and complaining if it doesn't know how).
Clean. Add in some more enforcable rules (like requiring component authors to provide a container-verifiable schema for the configuration format (like a DTD for XML) and component configurators to follow that schema), and, save for bugs, all behaviour is completely deterministic. Clean, safe, sound, understandable.
The downside? In practice, especially with java and xml, it means way many lines of code to write.
Note: its perfectly possible to write a very dynamic scripted avalon-framework container. It just happens to be the case that avalon (especially with Merlin) is moving further and further into the sound and safe, predictable and verifiable corner. In fact, some people (like Steve) assert that a container which is not predictable is a Bad Thing(tm). Me, I strongly disagree with that assertion :D
The scripted picture
--------------------
- a container will look for a configuration script according to preset rules and run it according to some more rules
- a configuration script had better exist and follow the rules
- a component is not required to do anything special
You lift some responsibility from the component and from the container at the price of requiring the end user to write a sensible configuration script or suffer the consequences.
The upside? Every piece in this system is a lot simpler, and usually you end up with less lines of code everywhere.
The balance ----------- You have a few axes that are not orthogonal:
clean <---------------------------> dirty
safe <---------------------------> unsafe
complex <---------------------------> simple
static <---------------------------> flexible
much effort <---------------------------> little effortSacrifice some conceptual cleanness and predictability and you end up with a system that is both simpler and more flexible, and, most importantly, requires less typing.
Choice
------
In a banking application, you had better make sure that a misconfiguration does not ever result in anything bad happening. I wouldn't want scriptable ATMs. In your average web server, its okay if a web page decides to topple over every now and then, as long as it is easily and quickly fixed.
cheers!
- Leo
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
