[Html-widget] opinions of removing implicit fieldset / breaking back-compat

Andreas Marienborg omega at palle.net
Thu Nov 9 09:52:39 GMT 2006


I think a fork might be the right thing to do, so people can continue  
using HTML::Widget as it is now, as a simple way to create simple forms.

The new project sounds more like a way to specify more complex  
structures than just forms? In that essence a new namespace might be  
appropriate, I just dont know what it should be.


Some things I wish could happen in the new one:

- A way to get the element for the label.
- A simpler way to combine elemnts, so I dont have to keep writing  
theese "TextfieldButton", "TextfieldSpan" classes.

- Shorter classes on the elements, and instead more classes for each  
element

- Formated output by default.


just of the top of my head :)


andreas


On 9. nov. 2006, at 10.30, Carl Franks wrote:

> On 08/11/06, Andreas Marienborg <omega at palle.net> wrote:
>> I think the idea of moving away from autocreating the container is
>> probably a good idea.
>>
>> What I would like it to do is to refuse to add non-block elements
>> directly to the form tag, so you ensure that they create the block
>> themselves. That would also make it easier to find the places with
>> missing containers as they would create deaths in tests.
>
> This sounds the best course of action, but I'm think I'm at the stage
> where I either need to release a HTML::Widget::Compat that people can
> switch to when everything breaks - or create a fork under a different
> name.
>
> Not only will these changes break things for anyone using an implicit
> sub-container, but removing the implicit sub-container will break
> things for anyone using almost any $result method other than as_xml().
> Unfortunately, $result->elements() has a hack for implicit
> subcontainers, so that it returns the fieldset's elements.
> Get rid of the implicit sub-container, and elements() just returns the
> top-level fieldsets you've added. Making it recursive isn't much
> better, as it doesn't just return form fields, but all types of
> elements.
> What's really needed is a fields() method that recursively returns all
> form fields.
>
> If things are going to be broken, I also want to incorporate the
> changes to elements()/fields() I mentioned recently, so that they
> return more helpful objects, rather than HTML::Element objects.
>
> Rather than just start hacking, I'm going to edit the existing pod,
> and make the files available somewhere online, so that everyone can
> contribute to the design.
> I'm also going to make sure that this goes through several cpan 'dev'
> releases, so things are done right before committing to an API.
>
> Carl
>
> _______________________________________________
> Html-widget mailing list
> Html-widget at lists.rawmode.org
> http://lists.rawmode.org/cgi-bin/mailman/listinfo/html-widget




More information about the Html-widget mailing list