|
|
[Html-widget] retain_default() for a HTML::Widget::Element::Button?
By Bernhard Graf at May 10, 2007, 8:48 pm UTC
HTML::Widget::Element::Button has a retain_default() accessor. <cite> If true, overrides the default behaviour, so that after a field is missing from the form submission, the xml output will contain the default value, rather than be empty. </cite> But why? A button value (the label) cannot or at... More...
HTML::Widget::Element::Button has a retain_default() accessor.
<cite>
If true, overrides the default behaviour, so that after a field is
missing from the form submission, the xml output will contain the
default value, rather than be empty.
</cite>
But why?
A button value (the label) cannot or at least should not be changed by
the user (see bottom of page) - or do I overlook something?
I ask because I struggled some time with HTML::Widget to find out why a
submit button of a form didn't get a value. Finally I found the reason
is because for the corresponding form I always call process with the
HTTP request object as argument -
$widget->process($c->request)
- even at the initial call (*).
I set retain_default(1) on this submit element now and it works, but
actually as I said I think retain_default() is unappropriate for a
button element and in HTML::Widget::Element::Button::containerize() the
line
and $self->retain_default || not $args->{submitted};
should be removed.
(*) To set and check initial form values. Thus currently (and without
retain_default(1)) I'm also able to set the value of the submit button
(the name is also "submit") by calling the page like this:
http://my.domain/path/to/page?submit=My+Personal+Search-Button
Does anybody need or want this behaviour?
0 Replies
|
|
|
[Html-widget] dedicated html-formfu mailing list
By Carl Franks at May 2, 2007, 3:30 pm UTC
mst has kindly created a new list on the scsys server, so we now have our own formfu mailing list. You can subscribe via the list info page: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/html-formfu Once subscribed, the list address is: html-formfu@lists.scsys.co.uk Cheers, Carl More...
mst has kindly created a new list on the scsys server, so we now have
our own formfu mailing list.
You can subscribe via the list info page:
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/html-formfu
Once subscribed, the list address is:
[email protected: html-f...@lists.scsys.co.uk]
Cheers,
Carl
0 Replies
|
|
|
[Html-widget] formfu: recent developments
By Carl Franks at May 2, 2007, 08:06 am UTC
The list's been quite quiet the past couple weeks, so here's an update of what's been happening in svn... To complement $form->javascript(), there's a new method; $form->javascript_src() which accepts a URI, and renders as a script tag with a src="" attribute to load an external javascript file. It... More...
The list's been quite quiet the past couple weeks, so here's an update
of what's been happening in svn...
To complement $form->javascript(), there's a new method;
$form->javascript_src() which accepts a URI, and renders as a script
tag with a src="" attribute to load an external javascript file. It
accepts a single URI, or a list of URIs which renders as multiple
script tags.
When render_processed_value() is used to display the result of the
value after being processed by any Filters, Inflators and
Transformers, the value is now also run through any associated
Deflators.
All constraints which have an others() method now share a common base-class.
They now have new methods:
attach_errors_to_base(1)
attach_errors_to_others(1)
attach_errors_to(\@names)
which determine which fields any errors should be associated with (see
POD for details).
Each constraint has it's own defaults for these methods.
There's a new force_errors() method which can be set at the form-,
block-, element- or constraint-level.
It makes error messages be displayed, regardless of whether or not
there were input errors.
Forced errors are only returned by get_errors() if a true 'forced'
argument is supplied.
$form->get_errors({ forced => 1 });
Forced errors are ignored by has_errors(), valid() and submitted_and_valid().
When using the render object, field.errors is actually just a hash
key, so it returns both real and forced errors.
The MinMaxNeeded constraint has been renamed to MinMaxFields to make
its intent more clear.
It's also been changed so that by default, errors are only associated
with the base field.
You can restore the old behaviour by setting
attach_errors_to_others(1) in the constraint definition.
What might be a nice feature; though I'm not sure yet of an interface;
would be associating the error message with the base field, and
allowing the other fields to have a CSS error class set, but not an
error message. This would provide a visual prompt for where there
errors are, but not complicate things by needlessly repeating the same
error message more than once.
$form->render->field('foo')->as('text');
With the changes to constraints / errors now largely complete, I've
fixed field->as() so it once again correctly handles field errors.
Several of these additions to formfu have been with client-side
validation in mind, so...
The client-side/javascript constraint proof-of-concept has been updated:
http://www.fireartist.com/tmp/client-side-constraint.html
It demonstrates the use of filters, multiple constraints, and multiple
forms on a single page.
There's still some way to go until this is actually generated by
formfu, but the work is progressing :)
Carl
0 Replies
|
|
|
[Html-widget] FormFu: form_error_message not an error?
By Jason Kohles at May 1, 2007, 08:08 am UTC
It seems that setting form_error_message on a form that has no other errors will not have any effect. Is this the intended behavior, and if so does anyone else think it doesn't make sense? :) In particular, I was trying to use form_error_message as a kind of 'error-handler of last resort', by doing... More...
It seems that setting form_error_message on a form that has no other
errors will not have any effect. Is this the intended behavior, and
if so does anyone else think it doesn't make sense? :) In
particular, I was trying to use form_error_message as a kind of
'error-handler of last resort', by doing this in a Catalyst app:
if ( $form->submitted_and_valid ) {
my $user = $c->model( 'DB::User' )->new( {} );
eval { $user->populate_from_formfu( $form ) };
if ( $@ ) {
$c->log->error( $@ );
$form->form_error_message( "FATAL ERROR: $@" );
} else {
$c->post_redirect( '/thank_you' );
}
}
Does it seem like this should work, or does anyone have a suggestion
for a better way to handle this?
3 Replies
|
|
|
[Html-widget] FormFu: validating complex structures
By Jonas Alves at Apr 27, 2007, 3:53 pm UTC
Hi all, I would like to use FormFu to validate a complex structure. It may come from a JSON file or from a form expanded with CGI::Expand. How hard would be to patch HTML::FormFu to process something like this? I thought that container fields could act as a container to a sub-hash. Something like... More...
Hi all,
I would like to use FormFu to validate a complex structure. It may
come from a JSON file or from a form expanded with CGI::Expand.
How hard would be to patch HTML::FormFu to process something like this?
I thought that container fields could act as a container to a sub-hash.
Something like this:
elements:
- type: text
name: user
- type: text
name: email
- type: fieldset
name: address
- type: text
name: street
- type: text
name: code
Would validate a structure like:
{
user => 'John',
email => 'john@mail.com',
address => {
street => 'xxxxxxx',
code => 1000,
}
}
And would generate a form with dotted name convention like:
<form>
<input name="user">
<input name="email">
<fieldset>
<input name="address.street">
<input name="address.code">
</fieldset>
</form>
That could be translated in a complex structure with CGI::Expand.
This functionality would not be the default of course, but could be
activated with a config parameter.
What do you think? I can try to hack this in HTML::FormFu, just need
to know the internals a little better.
Cheers,
0 Replies
|
|
|
[Html-widget] HTML::FormFu::Constraint::DBIC::Unique
By Jonas Alves at Apr 26, 2007, 6:36 pm UTC
Hi all, I needed a constraint to verify unique values in a db table using DBIx::Class so I created HTML::FormFu::Constraint::DBIC::Unique. It may be useful to someone else so here it goes attached. Carl, it has docs and tests in the case you want to had it to the svn repo. SYNOPSIS:... More...
Hi all,
I needed a constraint to verify unique values in a db table using
DBIx::Class so I created
HTML::FormFu::Constraint::DBIC::Unique.
It may be useful to someone else so here it goes attached.
Carl, it has docs and tests in the case you want to had it to the svn repo.
SYNOPSIS:
$form->stash->{schema} = $dbic_schema; # DBIC schema
$form->element('text')
->name('email')
->constraint('DBIC::Unique')
->resultset('User')
;
$form->stash->{context} = $c; # Catalyst context
$form->element('text')
->name('email')
->constraint('DBIC::Unique')
->model('DBIC::User')
;
$form->element('text')
->name('user')
->constraint('DBIC::Unique')
->model('DBIC')
->resultset('User')
;
or in a config file:
---
elements:
- type: text
name: email
constraints:
- Required
- type: DBIC::Unique
model: DBIC::User
- type: text
name: user
constraints:
- Required
- type: DBIC::Unique
model: DBIC::User
field: username
Cheers,
0 Replies 
|
|
|
[Html-widget] FormFu: Catalyst FormConfig + manual constraints
By Tobias Kremer at Apr 25, 2007, 11:13 am UTC
I just started playing around with HTML::FormFu and I'm really liking it up to now. However I haven't been able to use the FormConfig attribute in my Catalyst controller to load the basics of a form _AND_ afterwards add constraints manually. Here's my latest try: sub signup : Local : FormConfig {... More...
I just started playing around with HTML::FormFu and I'm really liking
it up to now. However I haven't been able to use the FormConfig attribute
in my Catalyst controller to load the basics of a form _AND_ afterwards
add constraints manually. Here's my latest try:
sub signup : Local : FormConfig {
my( $self, $c ) =3D @_;
$c->stash->{ 'form' }->constraint( {
type =3D> 'Callback',
name =3D> 'captcha',
callback =3D> sub { return 0; # just to see if it's working }
} ); # as documented in HTML::FormFu::Constraint::Callback's POD
my $form =3D $c->stash->{ 'form' };
if( $form->submitted_and_valid ) { .. }
}
The constraint is not added to the form loaded via Config::Any. Am
I doing something wrong? Or is it impossible to add constraints after
using FormConfig to prepare the form?
Thanks!
--Tobias
_______________________________________________ _ _
(web) http://www.funkreich.de
(last.fm) http://www.last.fm/user/soulchild77
12 Replies
|
|
|
Re: [Html-widget] formfu - deflators
By Carl Franks at Apr 25, 2007, 10:47 am UTC
I'd forgotten that there was a render_processed_value() method which ensures the processed value is displayed to the user. (I was on holiday when I initially replied!) I agree that if render_processed_value() is true, the values should also be run through the Deflators. I've added a task to the... More...
On 10/04/07, Daisuke Maki <daisuke@endeworks.jp> wrote:
>
> > The way they work at the moment, they=B4re intended to be run on values
> > you set yourself: $field->default($obj)
> > such as when you recieve a DateTime object from DBIx::Class.
> > When you redisplay a form, the original submitted value is used.
> > Filtered / inflated values aren=B4t used, so it shouldn=B4t prove a
> > problem that the deflators are only used when it=B4s not been submitted=
.
> > Of course, this is only how I think it should work - the code might
> > differ from my memory! I=B4m also open to suggestions on how it might
> > work better, as well.
>
> Thanks, I think I get the current status now.
> my perception was that
>
> $form->process()
>
> runs Filters, Constraints, Inflators, and Validators and
>
> $form->render()
>
> runs Deflators before outputting xhtml to produce values to be used for
> rendering.
>
> Basically what I wanted to do was
>
> 1. Receive an form
> 2. Inflate an element to an Object
> 3. Refer to, and change some values of the object
> 4. Deflate the object back to a string and see its
> results in the form.
>
> For example, if I inflated a column to a DateTime object and then I
> changed the value to be a year ago the specified date (and perhaps
> explicitly set it as the value of that param), I was expecting the
> change to be visible when render() was called.
>
> I guess it's really the naming of the modules: there's an inflator, and
> a deflator, I expected one to compliment the other. So if inflators
> always run, then deflators always do too, or something like that.
>
> I don't have too strong of an opinion as to whether this should be
> changed to not -- I just thought that was a natural sequence of events.
I'd forgotten that there was a render_processed_value() method which
ensures the processed value is displayed to the user. (I was on
holiday when I initially replied!)
I agree that if render_processed_value() is true, the values should
also be run through the Deflators.
I've added a task to the issue tracker for this.
Cheers,
Carl
0 Replies
|
|
|
[Html-widget] formfu - HTML::FormFu::Localize
By Daisuke Maki at Apr 25, 2007, 10:31 am UTC
I'm trying to use a custom localize object so I can display errors from my custom validator, and added this to my yaml config: localize_class: 'My::I18N' This barfed on me at HTML/FormFu/Localize.pm line 95, where the class is being required. The errors stated was "class argument missing" in... More...
I'm trying to use a custom localize object so I can display errors from
my custom validator, and added this to my yaml config:
---
localize_class: 'My::I18N'
This barfed on me at HTML/FormFu/Localize.pm line 95, where the class is
being required. The errors stated was "class argument missing" in
require_class().
So I looked at the code, and I'm guessing this is the culprit:
Index: lib/HTML/FormFu/Localize.pm
===================================================================
--- lib/HTML/FormFu/Localize.pm (revision 189)
+++ lib/HTML/FormFu/Localize.pm (working copy)
@@ -151,9 +151,7 @@
#warn "+ loading ".$localize_data->{localize_object};
$localize_data->{localize_object} =
- $self->get_localize_object_from_class(
- $localize_data->{localize_object}
- );
+ $self->get_localize_object_from_class( $self->localize_class );
$localize_data->{dies_on_missing_key} =
$self->get_localize_object_dies_on_missing_key(
Is my correction above right? This is the first time I try out to change
localize_class, so I wasn't too sure if this was indeed the intended
behavior.
--d
1 Reply
|
|
|
[Html-widget] FormFu: creating multi form elements
By Thorsten Domsch at Apr 20, 2007, 11:05 am UTC
problem: I want to create a custom FormFu Element consisting out of a few ordinary HTMl Elements via formFu. Let's say a date combo consisting of three select boxes (Day,Month,Year named $self->name."_d", "_m" ,"_y"), creating something like this is easy, writing the three boxes in my template file... More...
problem:
I want to create a custom FormFu Element consisting out of a few ordinary HTMl Elements via formFu. Let's say a date combo consisting of three select boxes (Day,Month,Year named $self->name."_d", "_m" ,"_y"), creating something like this is easy, writing the three boxes in my template file childsplay, but how do i get formfu to correctly evaluate the three boxes as one (constraints, errormsgs ??) ??
1 Reply
|
|
|
[Html-widget] literals
By Bernhard Graf at Apr 18, 2007, 2:29 pm UTC
Short question: Is there a way for literal texts in labels in HTML::Widget? I need labels with HTML code being untouched. More...
Short question:
Is there a way for literal texts in labels in HTML::Widget?
I need labels with HTML code being untouched.
2 Replies
|
|
|
[Html-widget] Deleting an element from a widget?
By Dave Richards at Apr 15, 2007, 12:19 am UTC
Hi all, I am a newbie, so please be gentle... I have a widget that I have created, that I would like to reuse (I am using HTML::widget with Catalyst). The cut down example is: $w->element('Textfield', 'name' )->label('Real Name')->size(20); $w->element('Textfield', 'email'... More...
Hi all,
I am a newbie, so please be gentle...
I have a widget that I have created, that I would like to reuse (I am using HTML::widget with
Catalyst). The cut down example is:
$w->element('Textfield', 'name' )->label('Real Name')->size(20);
$w->element('Textfield', 'email' )->label('Email')->size(20);
$w->element('Textfield', 'username' )->label('Username')->size(12);
$w->element('Password', 'password' )->label('Password')->size(12);
However, I do not want to use the username or password field (the real example is much more
comprehensive, so would like to reuse if I can).
Is there any way to 'undef' the username and password elements?
Thanks,
Dave.
0 Replies
|
|
 | |
