On Wed, Feb 18, 2004 at 04:58:05AM +0000, Tim Larson wrote: > On Tue, Feb 17, 2004 at 10:40:41PM +0100, Sylvain Wallez wrote: > > 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.
BTW, using the Assistant model we can also remove most of those "1/3 of the classes". The definition constructors already know what information they need, and if you look through the builder classes you will see that they contain a lot of duplicate code for getting that info. By directly teaching the Assistant how to derive common things like location, id, selection lists, etc. we can eliminate all but the most unusual builder classes and let the on-demand resolving do the work, as described in the previous email. In short, the builder will supply the DOM/SAX/database specific resolving logic, but the definition constructors will drive the process without requiring duplicated logic in the builder classes. --Tim Larson
