[Html-widget] HTML-FormFu example xhtml

[Mario Minati]

Carl Franks schrieb:
> Mario,
>
> On 19/01/07, Mario Minati <mario at minati.de> wrote:
>> Few questions:
>>
>> The radiogroup rg3 doesn't show labels for the subgroups. On purpose?
>
> Well spotted!
> I think I was going to make the label appear within a span with the
> class-name "label".
> RadioGroups having sub-groups wasn't really an intended feature - but
> because they share the same baseclass as Select elements, I had to
> make the RadioGroup template handle sub-group data, rather than choke
> on it.
> It's important that they can handle each other's data - the reason
> they share a base class is so that you can do something like
> [% result.field('my_select').as('RadioGroup') %]
> in your template to cast between element types. You can also do the
> same between different 'input' types.
That's realy cool :-)
>
>> Why has the fieldset class in css a width of exactly 80%?
>
> I just added that at the last minute, to make the form look a bit
> better when it's on a page on it's own.
> Widths wouldn't normally be included in the example css, as that's
> more a 'style' issue that I expect would be different for each
> project.
That's what I thought.
>
>> The way you provide of highlighting error elements is fine, might there
>> be the possibility of setting a special class attribut for labels and/or
>> elements that are required/have a special kind of constraint. What I
>> mean is to set a css class based on the constraints of an element.
>
> Because of the possibly large number of constraints any element might
> have, I was planning on adding this as an optional feature.
> Something like $form->constraint_classes() to add all constraints as
> class names, along the lines of "required_constraint",
> "number_constraint".
> Or with arguments listing only the constraints for which class-names
> should be added
> $form->constraint_classes('Required')
Perfect.
>
>> Can I reimplement the form module later on, so that I implement a
>> special one for dojo with the use of formbind?
>
> Not sure exactly what you're meaning.
> As far as I can tell, FormBind only needs a javascript function
> defined somewhere, and doesn't require any changes to the form markup.
> http://dojotoolkit.org/api/#dojo.io
> http://manual.dojotoolkit.org/WikiHome/DojoDotBook/Book23
I found out that you have to do some hacking that a form realy submits 
itself with formBind.
When you just click the submit button the browser will ignore the 
onClick event, which is a know bug/feature.
So you have to disconnect the existing onClick function and provide a 
new one or hide the submit button and use a custom one and call the 
onclick function of the submit button. These ways work both as I read 
from the mailinglist, at the moment I'm useing the second one.
>
> Options for customisation include, being able to use a different
> Render class which either completely replaces the rendering, or
> subclasses what's already there so you can override as necessary.
> A more simple approach would be to either use accessors to change
> which template files are used, on an element-by-element basis, or
> customise the template files, on a project-by-project basis.
Did you think during the design of the new widget creating modules of 
the possibility to enrich the constraint classes to use javascript 
constraints like dojo.validation?
I bet you did ;-)
>
> Does that answer your question?
Yes, but I have some more ;-)

When will you share a first alpha of the code, as I would switch my 
current project to that.

Will you take care of creating a DBIX::Class::HTML::FormFu. Or shall 
someone else.

Greets,
Mario Minati