cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy Larson <>
Subject Re: [Woody patch] Class, New, Struct, and Union widgets
Date Sat, 22 Nov 2003 20:39:40 GMT

--- Bruno Dumon <> wrote:
> On Fri, 2003-11-21 at 14:37, Timothy Larson wrote:
> I found the naming of the class/new widgets confusing. In fact, I think
> it is confusing to call them widgets at all, even if they might be
> implemented as widgets. Maybe calling them "define" and "use" is better,
> and I wouldn't document them as being widgets.

I am fine with any changes that make it better/clearer.
You are right, Class and New are not widgets (they only have definitions
and builders after all).  The names "Class" and "New" came from the idea
that at some point we might need to parameterize the instantiation of the
class of widgets.  For example, we may want to give nested unions a
different default case than their parents.  This could be specified as
parameters to the "New" element.  BTW, the current names do not quite sit
well with me either.

> I'm not a native english speaker, but I wonder if the struct/union names
> will say much to non-programmers, or even Java programmers. OTOH, I
> don't have any good alternatives yet.

The name came from their counterparts in the "C" language.
More intuitive names would be greatly appreciated.
> Anyway, these are just small polishing remarks, next step is to dive
> into the code. Could you also provide the complete patch, i.e. which
> includes changes to all the widgets, so that I can see better how the
> class/interface hierarchy fits together?

When I modified all of the widgets the abstraction classes were not as
well developed as they are in the current patch.  If the abstraction
is found beneficial, I will put the work into updating the old
(unsubmitted) patch.  Here is the general idea however:

(Roughly, if I remember right...)
Form: ContainerWidget, AbstractContainerWidget
FormDefinition: ContainerDefinition, AbstractContainerDefinition
Field: ValueWidget, AbstractValueWidget
FieldDefinition: ValueDefinition, AbstractValueDefinition
BooleanField: ValueWidget, custom code instead of AbstractValueWidget
BooleanField: ValueDefinitions, AbstractValueDefinitions
AggregateField: CompositeWidget, AbstractCompositeWidget
AggregateFieldDefinition: CompositeDefinition, AbstractCompositeDefinitions
Struct: ContainerWidget, AbstractContainerWidget
StructDefinitions: ContainerDefinitions, AbstractContainerDefinition
Union: CompositeWidget, AbstractCompositeWidget
UnionDefinitions: CompositeDefinition, AbstractCompositeDefinition
Repeater: ContainerWidget, custom code instead of AbstractContainerWidget
RepeaterRow: ContainerWidget, AbstractContainerWidget
RepeaterDefinition: ContainerDefinitions, AbstractContainerDefinition

>From your other email:
> Need to look into the code yet, but I saw the comment in the TODO list
> about slow operation on deeper nesting levels, and was curious about
> what this is caused by? Something on the processRequest or template
> side?

I did not get a chance to track this down yet.  I just noticed it and
documented it to look into later.  If you (or anyone) has a good
debugging/profiling environment you will probably beat me to it :)

Thanks for the interest,
--Tim Larson

Do you Yahoo!?
Free Pop-Up Blocker - Get it now

View raw message