cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Larson <>
Subject Re: CForms "static final" widget definitions
Date Wed, 18 Feb 2004 04:58:05 GMT
On Tue, Feb 17, 2004 at 10:40:41PM +0100, Sylvain Wallez wrote:
> As I said in my previous post (sorry, not much interactivity as I 
> currently use a dialup connection), wanting removing all modifiers can 
> make the code difficult to write. We should better enforce this through 
> a "makeReadOnly" method.

I am experimenting with having the Assistant hold a (Hash)Map of
configuration data, such as location, id, datatype, selection list,
and value changed listeners.  The specialized builder class fills
the map, and then the definition constructor pulls what it needs
from the map.

This is evolving into an on-demand design where the builder can
prefill the map with whatever is already known, and when the
definition constructor asks for information not in the Assistant's
internal Map the Assistant transparently calls back into the
builder to get the requested data.

Of course, the definition constructor never needs to know about
any of this or even whether the builder is reading in the config
right then or is referencing cached config data shared between
several different form definitions or whatever else someone may
dream up.

How's that for for easy to write?  What issues do you see?
I like this back-and-forth that open source allows, and am
glad that "we" are smarter than "me", so go ahead and poke
holes in this plan to make it better.

> Another way would be by merging the WidgetDefinitionBuilder into the 
> WidgetDefinition, as has been done for the TreeProcessor in 2.2. I have 
> to think a bit more about this, but it's IMO the way to go (and would 
> remove 1/3 of the classes!)

Please don't take this route, because I am already planning
new builder sets to work beside the current DOM builders,
such as SAX-based and possibly database-based builders.

--Tim Larson

View raw message