[html-formfu] new 'force_default' attribute for elements

[Mario Minati]

On Friday 14 September 2007 11:10:02 Carl Franks wrote:
> Hi Mario,
>
> On 13/09/2007, Mario Minati <mario.minati at googlemail.com> wrote:
> > Today I had to implement a disabled form field, which should keep it's
> > value no matter what the user sends in the form data.
>
> Okay, when I was viewing the `svn diff`, I was wondering what it was
> for - but that makes sense.
>
> > So I created the 'force_default' attribute which overwrites the value in
> > param with the default value.
> >
> > The changes and documentation is in Elements::_Field.
>
> Tests needed! :)
Done.

>
> Also, regarding this snippet...
>
>     # if the default value has been changed after FormFu->process has been
>     # called we respect the change here
>     if (    $submitted
>          && $self->force_default
>          && defined $default
>          && $new ne $default ) {
>         $new = $default;
>     }
>
> The comment contradicts the code.
> It says "respect the change", but you're actually overwriting the change.
> Would a more suitable comment just be...
> # overwrite any changes
> ?
No, the description is a bit complicated. I tried to eas it:
    # if the default value has been changed after FormFu->process has been
    # called we use it and set the value to that changed default again
The problem I was facing is that the default value is not known during the 
automatic form creation from config file in my Catalyst controller. 
But 'process' is already called before I can set the default in my 
controller.
So I have to check in 'process_value' again if the default value has been 
changed. This changed value is used for form output.

But that leads into the caveat I'm describing in the docs of _Field:
The value for the forced field that is stored in param (from query) is the 
valuethat is given during form setup (before 'process' is called) and not the 
value that has been set later.

As it is a fixed field what one should use/need for data processing I'm 
tolerating that, but I'm not happy with it.

I had to put in some more code to handle radio and checkbox fields properly 
(thanks to tests). 

>
> > BTW: I changed the formatting of a complex ??:?: to understand it.
>
> Ok, but try to keep formatting changes to a separate commit, so if
> anything needs rolled back, it's easier.
I wanted to, but I had no net put it in svn when I did that. Won't happen 
again. ;-)

>
> Anyway, that was perltidy's formatting, so your change will get lost
> the next time I run perltidy on all the files.
> To help with consistency, I've added my ".perltidyrc" file into the
> trunk/HTML-FormFu directory, so if anyone else runs perltidy within
> that folder, it'll use the same settings
>
> If anyone's interested, the commands I use to run perltidy on all .pm
> files in "lib" and all .t files in "t" are:
>
>     $ find lib -name '*.pm' -exec perltidy -b '{}' \;
>     $ find t -name '*.t' -exec perltidy -b '{}' \;
>
> And to remove the backup files it creates:
>
>     $ find lib -name '*.bak' -exec rm -f '{}' \;
>     $ find t -name '*.bak' -exec rm -f '{}' \;
Thanks for sharing.

By the way, what editor do you use for development? At the moment I just use 
kate from kde, but I think I'm going to switch to eclipse and epic.

Greets,
Mario