On 13 December 2010 21:07, Octavian Rasnita <[email protected]> wrote:
> From: "Toby Corkindale" <[email protected]>
>
> On 9 December 2010 19:24, Octavian Rasnita <[email protected]> wrote:
>>> Using Moose Roles for forms is awesome.
>>
>> I also agree with this idea, but the fact that the most used constraints,
>> filters and validators should be also manually specified using Perl code is
>> not so nice.
>> It would be nice to have a form processor like H::FF that provides many
>> default HTML elements, constraints, filters and validators, and to be able
>> to create custom elements, constraints, filters and validators using Moose
>> roles, then to specify that those roles are used... using config files.
>
>> But.. That's what the custom fields, widgets, roles etc are there for.
>> Eg. If you need a field that can, say, only accept four characters and
>> they have to be a-d, then go in and make a custom field type that does
>> the check.. Then tell your designers to just say "type =>
>> 'mySpecialField'" when they need to use it.
>>
>> Or even better, develop entire classes of grouped widgets and their
>> validations, then get them to just incorporate those.
>> (Eg. an "Address" role, which brings in street, suburb, borough,
>> state, postcode, zip code, whatever.. and does all the validation..
>> You'll reuse that one a lot!)
>
>
> Yes, I wasn't very clear. The most important part is not the one that allow
> creating custom fields, constraints or filters, but the one that talks about
> using pre-defined very common fields.
> For example, if I just want to validate an email address, or some numbers, or
> other simple things like these, I don't want to write any kind of code if
> with H::FF I can just write a short code in a configuration file.
> It is more simple to write
>
> <constraint>
> type Email
> </constraint>
>
> ...than to write Perl code and apply a Moose role to a certain field.
It's not that hard, it's just:
has_field 'email_address'=> ( type => 'Email' );
>> Actually, I guess that is possible to create them using Moose with H::FF
>> although I am not sure.
>>
>> Ideally, the web designers that don't know Perl at all should be able to
>> change the design of the forms at least.
>
>> Agreed, and this is where neither FormFu or FormHandler succeeds.
>
> True, but for simple layouts, H::FF requires less effort for coding.
> I became interested in H::FH for using it in the case of more complex forms,
> especially after I heard that it is faster than H::FF, but it is not
> acceptable at all to use html code as strings in Perl code.
>
> The development version of H::FF also uses Moose, so only the fact that H::FH
> uses moose is not a relevant advantage.
>
>
>> FormFu's yaml syntax ends up being horribly complicated, and
>> FormHandler's Perl code is not much clearer.
>
>
> True, but FormFu can also use Config::General code which is much clearer (or
> other config formats accepted by Config::Any).
>
> It would be OK if H::FH would allow creating custom elements and validators,
> filters... using Moose, but only generic elements, not related with any form,
> and then allow us to use configuration files for using those elements and
> constraints. It is not nice at all to need writing Perl code using Moose for
> just creating an HTML form, but each one with his preferences. :-)
But you can do that if you want..
If you're just doing simple stuff, like name-of-field + type-of-field,
then you could do something like this:
my $form = HTML::FormHandler->new(
item => $c->model('DB::User')->find($id),
field_list => YAML::Load("form.yaml")
);
Where form.yaml looks a bit like:
---
username:
- type: Text
- required: 1
email_address:
- type: Email
- required: 1
favourite_colour:
- type: Select
- options:
- blue
- red
- green
- orange
- yellow
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
