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
