Much has been talked about in regards to the component infrastructure.
That's a good thing, but after years of component based design, and
getting back to the roots of just plain old object oriented design, I
have to question why everything needs to be a component. Using good
OOD, we can create a solid and robust core--devoid of any configuration
settings--and only provide extension points. I.e. plugins.
Here's my reasoning, component based design (CBD) is a restricted form
of OOD with some initialization magic thrown in. The key weakness in a
CBD system is that everything is a moving part. While the flexibility
is a strength, the resultant instability is a weakness. It is much
easier to design for error tracking using plain old OOD than it is in a
system where you don't manage the objects you are using. There are
several OO tricks we can't use, or are not using. At the same time, we
have some aspects of our system that need to be extended with user
provided functionality. Much like Photoshop with filter plugins. The
block idea would be more analagous to complex macros for Photoshop.
They may provide new plugins to use in the package, but they allow you
to do predefined things.
There are three areas where we can use the plugin behavior: pipeline
components (generator, serializer, transformer, reader), processor
(sitemap, rails like router, blocks), and inter-block communication.
Everything else should be part of the core. For example, the core does
not need to worry about how to stylize the content of your blocks. That
is a function of inter-block communication. The core only needs to
worry about how to work the different things together. The core does
not need to worry about database connections, only how Cocoon extensions
relate to the environment. These should be very simple contracts. No
moving parts, no configuration for configuration's sake. No need for
reams of XML config files.
Java 1.4 provided some nice alternatives to dealing with
configurations. One notable example would be the Java Preferences API.
I have a nice utility that abstracts away the Preferences API vs. a
Properties file, and gives you a POJO interface for it. That will also
make it easier to create standalone configuration apps using the rock
solid JGoodies APIs. Oh, not to mention that my utility also allows you
to obfuscate configuration entries like database username and password.
The point is, that there are other approaches to configuration. Those
approaches are better than XML config files for two reasons: processing
the configurations is less complicated, and they are easily managed.
The real component simplification is to get rid of the components that
will never be swapped out. It's unnecessary for them to be components
anyway. That makes the task of providing an Avalon bridge for existing
components much easier. And it achieves the goal that the internals are
not a scary mess any more.
- [RT] The Real Component Simplification Berin Loritsch
-
