[Html-widget] Offer of help / question about H::W status

[Michael Gray]

On Fri, 28 Jul 2006, Ash Berlin wrote:

> Anyway - if either of you want to start working on the changes as shown 
> by Michael's test - that looks good.

Aristotle and I are talking (slowly).  

I started penning a suggested refactoring, but needed to take a step 
back.

At the moment an HTML::Widget is a Jeckyll and Hyde character which 
contains EITHER:

 (a) A list of elements, which get surrounded by a stealth <fieldset>
     (the sub_container), and then by a form, by as_xml().

OR:

 (b) A collection of embedded widgets, each of which get turned into
     <fieldset>s, and then all put in a <form>.

AND the top-level widget also contains lists of all the constraints
and all the filters to be applied.   

However, the embedded widgets in case (b) are second-class citizens
which cannot contain further embedded widgets, and which (probably
un-intentionally) do not get their elements process()-ed when the
top-level H::W->process() is called.

Furthermore, if a type-(a) Widget has one or more Widgets embedded
into it, its own elements are more-or-less forgotten.  

So I think that the refactoring is going to have to make the implicit
fieldset in an element-only Widget rather more explicit, and will have
to provide a better-defined collection of methods for joining and
merging widgets and/or fieldsets.  The fieldset will probably need to
be a 'Collection Element' which can take its place amonst a list of
ordinary elements.

Then a Widget will contain one or more 'Collection Element' fieldsets,
treat them equally, and process them recursively.  Down the line,
someone might want to allow for other block-level collection elements
(divs, tables, etc.)

The trick will be to make these changes whilst maintaining backwards
compatibility.

Thoughts?

-- 
Michael