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

[Ash Berlin]

Michael Gray wrote:
> 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?
>
>   
First lets make sure I understand what you're saying properly. Basically 
you are suggesting the following:

 * HTML::Widget - similar to it is now, but instead of containing 
elements/embedded widgets, only contains containers (or block level 
elements - BLEs)
 * Fieldset/Container/BLE - this would contain other BLEs or the 
elements themselves, along with associated constraints.

So in a lisp like arrangement:

H::W( BLE( e, e, BLE( e, e, e)), BLE(e, e))

If so yes, that makes sense - in fact I almost ended up doing something 
akin to that before, but I found out I didn't need to.

I think the one caveat is to make sure the old behaviour is maintained. 
This would basically entail putting all of the functionality you 
describe in the BLE class which isa HTML::Widget::Element.

Yes?

Ash