cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@d-haven.org>
Subject [RT] The Real Component Simplification
Date Wed, 04 Jan 2006 15:08:03 GMT
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.


Mime
View raw message