[Html-widget] latest formfu developments

[Mario Minati]

Mario Minati schrieb:
> Carl Franks schrieb:
>> The past week has seen a few formfu developments...
> Hi Carl,
> you have really been active in the last two weeks, while I've been 
> away. And your code evolvs more and more. Congratulations.
>>
>> I18N support has been added, with all error messages being moved out
>> to the FormFu/I18N/en.pm package.
> I discovered that and found a bug (probably).
> When defining a constraint like this:
> $form->constraint( Required => qw/shortname name/ )->message('mm - 
> Required. ');
Of course the code had to be reworked like you wrote below, but the 
problem still exists.
> It tries to get a translation for 'mm - Required. ', which of course 
> is not available.
> So I think we need a way to bypass the I18N.
>> You can also alternatively provide your own i18n object or package, to
>> allow the messages to come from your main application's localized
>> message files.
>> The formfu catalyst controller now allows provides for integration
>> with the Catalyst::Plugin::I18N or a compatible module.
> I saw that but am not sure how to code it, could you put a little 
> example in the Catalyst FormFu Controller ;-)
>
> An other question about the FormFu Controller:
> First I was really amazed by the idea of creating forms from yml, but 
> than I realized, that I need Callback-constraints and to incoporate 
> data from different tables into select fields, which won't work via 
> yml files.
> Then I tried to use the FormFu Controller in FormMethod style to 
> create the form. But I don't understand yet how to create the data for 
> the populate function. If it is also 'only' a hashref like in the 
> .t-files than I also cannot create callbacks.
> If I am right (don't hope so) how can I create a form, as with the 
> Form Action the result gets calculated before I could add any elements 
> programatically.

> At the moment I am useing a Catalyst::Plugin::FormFu which I created 
> similary to the HTML::Widget Plugin, but I really would like to switch 
> to the Action style you started.
>>
>> Sitting alongside filters and constraints, there are now 2 new
>> namespaces: Deflator and Inflator.
>> These are similar in idea to DBIx::Class's InflateColumn.
>> If, for example, you feed $field->default() with a DateTime object,
>> and you want to ensure the field value is displayed in a certain
>> format, you could do:
>>    $field->deflator( 'Strftime' )->strftime( '%d/%m/%Y' );
>>
>> Likewise, you can ensure the value from $result->params->{date} is a
>> DateTime object with the following:
>>    $field->inflator( 'DateTime' )->parser( strptime => '%d/%m/%Y' );
>> (passing parser() any value that DateTime::Format::Builder::parser() 
>> accepts)
> That is really cool.
>>
>> These 2 features allow for seamless integration with DBIx::Class, all
>> from the form config/setup, without any extra code.
>> The Strftime deflator was developed specially for the
>> Dojo::DropdownDatePicker element - you would of course need a smarter
>> solution for parsing dates that a human will have typed.
>>
>> The css has also been updated to improve the rendering of error 
>> messages.
>> Also containers now automatically get the class name 'label' added if
>> the field has a label defined. This allows the example css to do away
>> with the 'nolabel' class name hack.
>> The css editor/preview application has also been updated with these 
>> changes:
>> http://www.fireartist.com/html-formfu-cssapp/
> I uploaded my first adjustments, but there will be more to come.
> One idea I am having in my mind is to provide an icon for every label 
> so the user has an improved GUI experience. What do you think is the 
> best way to realize that, with the xml attributes or enhanceing the code?
>>
>> Form fields now have a default() method.
>> For most fields, this is just an alias to value() - except for
>> Checkbox and Radio fields, where you would normally set its value, but
>> may or may not set a default value.
>> This means we no longer have to manually set the 'checked' attribute
>> in our code, instead just setting default().
>> The DBIx::Class::FormFu entension has also been updated - the
>> fill_formfu_values() method now expects a $form object, not a $result
>> - this is changed back to how DBIx::Class::HTMLWidget does it, as it
>> makes more sense conceptually, and (because it's setting
>> $field->default internally) it now works properly if the result is
>> being re-displayed after errors.
>>
>> The internals of constraints and filters has been completely reworked.
>> Now, if you list multiple names - like so:
>>    $form->constraint( Required => 'foo', 'bar' );
>> it creates a new constraint for each of the named fields.
>> This means fields which abused(?) this mechanism, such as
>>    $form->constraint( DependOn => 'foo', 'bar' );
>> now work differently:
>>    $form->constraint( DependOn => 'foo' )->others( 'bar' );
>>
>> Take note though, that if you list multiple names - because it returns
>> multiple constraints, chained methods no longer work.
>> Because I'm now tending to define all forms in config files, this
>> isn't an issue.
>> You could work around the issue with an idiom such as:
>>    map { $_->callback( \&my_sub ) }
>>        $form->constraints( Callback => 'foo', 'bar' );
>>
>> The constrain_fields() method has been removed, because now if you add
>> a constraint or filter without listing any names, it immediately
>> creates that constraint/filter for every field already on the form.
>>
>> I've also copied over lots more of the constraints from the
>> HTML::Widget package, and added support for 'Not_' constraint names.
> Perfect.
>
> I found the following problems in the code you send me two weeks ago, 
> so I am not sure if they are still relevant:
> - a fieldset cannot receive class attribute with add_container_attr, 
> only add_attributes worked
>    my $fs_last = $form->element('Fieldset')->add_attributes( { class 
> => 'fs_submit_area' } );
>
> - the xml/css for errors doesn't work, on FF2 the layout collapses 
> because of the span node that is created
>  maybe this is only a css problem but at present time it looks realy 
> ugly.
>  Do you have a working example, maybe you extend the 
> html-formfu-cssapp with a form with labels and errors.
>  Where do you think should be the place for the errors, where the 
> labels are, under the labels, where the comments are or under the 
> comments?
>  Can we provide a way to switch that programatically (ease of use) or 
> you think changing the templates is always the way to go?
That is ok for me now.
>       - value for submit/reset buttons gets changed to '' when calling 
> result
>  I think that only happens any longer on a reset button.
I got that one fixed, I think there was a bug in my form creating code. 
I am useing now:
    $multi_last->element('Submit')->value('Submit');
    $multi_last->element('Reset')->value('Reset');

>
>
>
> I have an other idea of extending the formfu. Actually It's more a 
> need than an idea.
> I need forms to submit n-times the same field, e. g. I want to be able 
> to submit telephone numbers, but don't know if it will be only one or 
> ten.
> My database is that flexible that it can hold as many numbers as given.
> Now I would like to create an javascript-supported form which gives me 
> in the beginning one field for a telephone number and a '+'-button 
> which creates an additional field.
> This concept should not only work for one single field that can be 
> repeated but also for a complete fieldset, so that I could submit 
> multiple address to give an other example.
>
> What do you think. I'll do the codeing, but I'll need definetly your 
> help on how to integrate it in the structures of formfu.

Greets,
Mario