[Html-widget] HTML::Widget::Element::Field

Brian Kirkbride brian.kirkbride at deeperbydesign.com
Mon Nov 6 22:52:39 GMT 2006


Carl Franks wrote:
> On 06/11/06, Zbigniew Lukasiak <zzbbyy at gmail.com> wrote:
>> Hi,
>>
>> Now when I think about this I think that you are probably right that
>> the designer does not normally need to change the type of the field.
>> The attributes, possibility to intersperse the inputs with additional
>> tags and to change the order of fields should be quite reasonable
>> range of customisation.  I would not care too much about fieldsets and
>> ul/ols in HTML::Widget - I would just left that for the templating,
>> but I would generate the hidden fields by the start_form helper.
>>
>> Unfortuntely I don't have any experience with designers in a Catalyst
>> project.  The interface_config.dat should not be too complicated - and
>> it can be made a bit simpler by choosing a separate directory for it
>> and having separate files for each Controller, and also by using some
>> config language instead of Perl datastructures.  But if it is only
>> used by InstantCRUD than I am afraid people would not accept it.
>>
>> And where is that guy that started me thinking about this with his 
>> Rails email?
> 
> I've been thinking some more about my idea of parsing a form out of a
> html/xml file, and it's maybe not as stupid as it first sounds.
> It also doesn't even require any template markup.
> 
> Point H-W to any html/xml file, or a variable already containing the 
> markup.
> Search for a form with the same name as the widget, or failing that
> the first form in the file.
> 
> For any markup which isn't a form input/button field, save it, so it
> can be output later unchanged.
> For any form input/button field, create a new element using the
> attributes/content from the markup.
> 
> You've then got a ready-made $widget which you can add constraints and
> filters to.
> 
> You could even then add any app-wide hidden fields to the end of the
> widget, and they'll be included within the FORM tags, without the
> designer having to know about it.
> 
> If I can get it working as I envisage, it's certainly something I'd use.
> Is it likely to solve the problem you're looking at?
> I'll have a hack, and see if I can come up with some working code.
> 
> Carl
> 


One possible issue: how to handle error markup?

One way would be to assume an attribute of id="{fieldname}_error" indicates a 
DOM node that would be removed on success or it's content replaced with the 
error message on error.

Another would be to have some sort of conditional markup.

The former would be less flexible, the latter ventures a bit too far into the 
realm of templates IMHO.

Overall, I still think that this would be a great way to get form design into 
the view and out of the controller/model.

- Brian



More information about the Html-widget mailing list