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 05:35:46 GMT
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

View raw message