[Html-widget] Offer of help / question about H::W status
mjg17 at eng.cam.ac.uk
Tue Aug 1 13:53:44 CEST 2006
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
At the moment an HTML::Widget is a Jeckyll and Hyde character which
(a) A list of elements, which get surrounded by a stealth <fieldset>
(the sub_container), and then by a form, by as_xml().
(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
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
More information about the Html-widget