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
_______________________________________________
Html-widget mailing list
Html-widget@lists.rawmode.org
http://lists.rawmode.org/cgi-bin/mailman/listinfo/html-widget
