FAQ
I'm playing with CP::FormValidator::Simple and I like it all right
but I feel like there must be something better than it and
CP::FormValidator.

Putting the form profiles in YAML seems to work great (even though I
hate the fairly ridiculous arrays of arrays grammar). For example:

In Controller:

$c->form($c->config->{form_profile}->{user});

In myapp.yml

form_profile:
user:
- last_name
-
- NOT_BLANK
-
- LENGTH
- 1
- 50
- suffix
-
-
- REGEX
- !!perl/regexp '(?-xism:\A[IVX]{1,3}\z)'
- email
-
- NOT_BLANK
- EMAIL
-
- LENGTH
- 6
- 80

As crazy as it is, I like having it out of the code and into the
config stuff.

I'm leaning more and more to having *all* of this stuff defined
(validation patterns, user messages for invalid input, clues for CGI
fields) in the Model (DBIC; I love it and never find time to try
Rose). Sort of a super phat Model. If it's not defined exclusively
there, it ends up defined there (via schema), the controller,
possibly the templates (messages), and even client-side in JS. I know
I'm showing my tremendous grasp of the obvious when I say, this is
just effing awful.

What are best practices? DBIx::Class::Validation reusing your form
package profiles? But you still have to write your own forms. I've
searched around a lot and can't find a thorough, coherent Catalyst
related doc about it.

I really want one, final approach to this I'll use every time from
now on instead of experimenting with packages and home rolled stuff
over and over. If someone is there, or even close. Please kick down.

As always, I appreciate everyone's time and expertise.

Thanks!
-Ashley

Search Discussions

  • Christopher Laco at Dec 5, 2007 at 2:00 am

    Ashley Pond V wrote:
    I'm playing with CP::FormValidator::Simple and I like it all right but I
    feel like there must be something better than it and CP::FormValidator.

    Putting the form profiles in YAML seems to work great (even though I
    hate the fairly ridiculous arrays of arrays grammar). For example:

    In Controller:

    $c->form($c->config->{form_profile}->{user});

    In myapp.yml

    form_profile:
    user:
    - last_name
    -
    - NOT_BLANK
    -
    - LENGTH
    - 1
    - 50
    - suffix
    -
    -
    - REGEX
    - !!perl/regexp '(?-xism:\A[IVX]{1,3}\z)'
    - email
    -
    - NOT_BLANK
    - EMAIL
    -
    - LENGTH
    - 6
    - 80

    As crazy as it is, I like having it out of the code and into the config
    stuff.

    I'm leaning more and more to having *all* of this stuff defined
    (validation patterns, user messages for invalid input, clues for CGI
    fields) in the Model (DBIC; I love it and never find time to try Rose).
    Sort of a super phat Model. If it's not defined exclusively there, it
    ends up defined there (via schema), the controller, possibly the
    templates (messages), and even client-side in JS. I know I'm showing my
    tremendous grasp of the obvious when I say, this is just effing awful.
    Take a look at Mango::Form. I sort of wanted that too. The profile,
    messages, and validation rules are all in yaml config files in a merged
    format.

    I've tinkered with stuffing all of that somewhere in DBIC schemas... but
    in my case, I need to use it even when I'm not using DBIC...
    What are best practices? DBIx::Class::Validation reusing your form
    package profiles? But you still have to write your own forms. I've
    searched around a lot and can't find a thorough, coherent Catalyst
    related doc about it.

    I really want one, final approach to this I'll use every time from now
    on instead of experimenting with packages and home rolled stuff over and
    over. If someone is there, or even close. Please kick down.

    As always, I appreciate everyone's time and expertise.

    Thanks!
    -Ashley
    I have form solutions. We all write our own because they all suck in
    there own special ways. IMHO, forms are one of those things in which
    there will never be a solution that is flexible enough and still be usable.

    YMMV.

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 249 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.scsys.co.uk/pipermail/catalyst/attachments/20071204/fdfb5508/signature.pgp
  • Peter Karman at Dec 5, 2007 at 2:36 am

    Ashley Pond V wrote on 12/4/07 7:47 PM:

    I really want one, final approach to this I'll use every time from now
    on instead of experimenting with packages and home rolled stuff over and
    over. If someone is there, or even close. Please kick down.
    Rose::DBx::Garden::Catalyst is one attempt. It doesn't take the approach you've
    described (put it all in Model) and it doesn't use DBIC (hence the package
    name...) but it does attempt a sane layout for forms, ORM, models and
    controllers. Still on the todo list is automatically generated JS client-side
    validation based on the data types defined in the form classes (a'la FormBuilder).

    There's an Advent entry on RDGC coming up Soon.

    --
    Peter Karman . http://peknet.com/ . peter@peknet.com
  • Bill Moseley at Dec 5, 2007 at 4:38 am

    On Tue, Dec 04, 2007 at 05:47:27PM -0800, Ashley Pond V wrote:
    Putting the form profiles in YAML seems to work great (even though I
    hate the fairly ridiculous arrays of arrays grammar). For example: ...
    As crazy as it is, I like having it out of the code and into the
    config stuff.
    Specifically into the config? Or just out of the controller?

    I think it would not be hard to make any of the form systems use YAML
    to read in their config, but when I've done that I find it quickly
    gets too limiting for specifying validation.

    I'm leaning more and more to having *all* of this stuff defined
    (validation patterns, user messages for invalid input, clues for CGI
    fields) in the Model (DBIC; I love it and never find time to try
    Rose). Sort of a super phat Model. If it's not defined exclusively
    there, it ends up defined there (via schema), the controller,
    possibly the templates (messages), and even client-side in JS. I know
    I'm showing my tremendous grasp of the obvious when I say, this is
    just effing awful.
    Again, I think you can only put so much in storage, so you need a
    place for the form logic code that can't be represented in simple
    regular expressions, ranges, etc.

    The Rose form code is very cool. That's what I based my forms on.

    I don't find automatic form markup creation that useful -- the forms
    always seem to need customization. So, I generate the markup with
    templates. So my forms end up looking like:

    http://search.cpan.org/src/HANK/Catalyst-Plugin-Form-Processor-0.05/example/FormProcessor/root/templates/user/edit.tt

    Here's an example of how my forms work in Catalyst:

    http://search.cpan.org/~hank/Catalyst-Plugin-Form-Processor-0.05/lib/Catalyst/Plugin/Form/Processor.pm

    http://search.cpan.org/~hank/Form-Processor-0.15/lib/Form/Processor.pm


    --
    Bill Moseley
    moseley@hank.org
  • Aristotle Pagaltzis at Dec 5, 2007 at 12:37 pm

    * Bill Moseley [2007-12-05 05:45]:
    The Rose form code is very cool. That's what I based my forms
    on.
    Disclaimer: I haven?t used Form::Processor. However from what
    I have seen so far, it seems to solve the *right* problem, with
    the right level of abstraction for common things and tweakability
    for individual needs, so it currently seems like the most likely
    validation framework to work for me.
    I don't find automatic form markup creation that useful -- the
    forms always seem to need customization.
    Template system of choice + HTML::FillInForm works for me and
    keeps things reasonably low-effort.

    Regards,
    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>
  • Ashley Pond V at Dec 5, 2007 at 8:25 pm
    Really good food for thought from everyone. Strangely enough, at
    least when I notice, Bill's code is the most like my own of anyone on
    the list; in approach and style. I'm less certain than ever, of
    course, what I'll end up with but I'm better informed.

    Thanks everyone.
    On Dec 5, 2007, at 4:37 AM, A. Pagaltzis wrote:

    * Bill Moseley [2007-12-05 05:45]:
    The Rose form code is very cool. That's what I based my forms
    on.
    Disclaimer: I haven?t used Form::Processor. However from what
    I have seen so far, it seems to solve the *right* problem, with
    the right level of abstraction for common things and tweakability
    for individual needs, so it currently seems like the most likely
    validation framework to work for me.
    I don't find automatic form markup creation that useful -- the
    forms always seem to need customization.
    Template system of choice + HTML::FillInForm works for me and
    keeps things reasonably low-effort.

    Regards,
    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>

    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/
    catalyst@lists.rawmode.org/
    Dev site: http://dev.catalyst.perl.org/
  • Zbigniew Lukasiak at Dec 6, 2007 at 10:19 am
    By the way - I've created a page on Form Processing at the P5 wiki:
    http://www.perlfoundation.org/perl5/index.cgi?form_processing

    --
    Zbyszek
    On Dec 5, 2007 8:25 PM, Ashley Pond V wrote:
    Really good food for thought from everyone. Strangely enough, at
    least when I notice, Bill's code is the most like my own of anyone on
    the list; in approach and style. I'm less certain than ever, of
    course, what I'll end up with but I'm better informed.

    Thanks everyone.

    On Dec 5, 2007, at 4:37 AM, A. Pagaltzis wrote:

    * Bill Moseley [2007-12-05 05:45]:
    The Rose form code is very cool. That's what I based my forms
    on.
    Disclaimer: I haven't used Form::Processor. However from what
    I have seen so far, it seems to solve the *right* problem, with
    the right level of abstraction for common things and tweakability
    for individual needs, so it currently seems like the most likely
    validation framework to work for me.
    I don't find automatic form markup creation that useful -- the
    forms always seem to need customization.
    Template system of choice + HTML::FillInForm works for me and
    keeps things reasonably low-effort.

    Regards,
    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>

    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/
    catalyst@lists.rawmode.org/
    Dev site: http://dev.catalyst.perl.org/

    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
    Dev site: http://dev.catalyst.perl.org/


    --
    Zbigniew Lukasiak
    http://brudnopis.blogspot.com/
  • Valentin Tumarkin at Dec 6, 2007 at 1:26 pm
    I would love to see a single "Form" framework which can be used both
    for HTML and AJAX forms (JSON data). Imagine having the View (and not
    the Controller) decide how the form will be presented - as HTML or
    ExtJS widgets.

    I understand that this can be built on top of existing modules, like
    Form::Processor. However with so many existing HTML Form modules out
    there, it seems that this problem would be better solved as a
    plugin/branch of existing High-Level Form module.

    A quick&dirty hack solution would be to write a module which populates
    Catalyst/CGI::FormBuilder form with data taken from JSON object.
    However this alone will not shift the presentation decision to View.
    Also support for hierarchical data structures (JSON) would probably be
    lost.

    A real-life example: one of my work projects is currently using
    Catalyst / FormBuilder. I want to move part of the web interface
    provided by the application to ExtJS, while keeping another part
    compatible with "non-AJAX" browsers.

    Regards,
    Valentin
  • Moritz Onken at Dec 6, 2007 at 1:57 pm
    Hi,

    I had the same problem with extJS but I use FormFu. I wrote a pretty
    simple extension for FormFu which generates the items-list for ExtJS
    from formfu config files.
    It supports tables, checkboxes, text, select, date, fieldset etc. Not
    everything yet. But I'm on it. Validation, transformation, de/inflation
    etc still works.

    These forms can be populated by the "default" value of any item. You can
    easily turn the Module on or off, so you can get a non-JS version if the
    form.

    I'm still working on it. But I want to publish it on CPAN.

    Regards,

    moritz

    Am Donnerstag, den 06.12.2007, 15:26 +0200 schrieb Valentin Tumarkin:
    I would love to see a single "Form" framework which can be used both
    for HTML and AJAX forms (JSON data). Imagine having the View (and not
    the Controller) decide how the form will be presented - as HTML or
    ExtJS widgets.

    I understand that this can be built on top of existing modules, like
    Form::Processor. However with so many existing HTML Form modules out
    there, it seems that this problem would be better solved as a
    plugin/branch of existing High-Level Form module.

    A quick&dirty hack solution would be to write a module which populates
    Catalyst/CGI::FormBuilder form with data taken from JSON object.
    However this alone will not shift the presentation decision to View.
    Also support for hierarchical data structures (JSON) would probably be
    lost.

    A real-life example: one of my work projects is currently using
    Catalyst / FormBuilder. I want to move part of the web interface
    provided by the application to ExtJS, while keeping another part
    compatible with "non-AJAX" browsers.

    Regards,
    Valentin

    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
    Dev site: http://dev.catalyst.perl.org/
  • Bill Moseley at Dec 6, 2007 at 3:13 pm

    On Thu, Dec 06, 2007 at 03:26:06PM +0200, Valentin Tumarkin wrote:
    I would love to see a single "Form" framework which can be used both
    for HTML and AJAX forms (JSON data). Imagine having the View (and not
    the Controller) decide how the form will be presented - as HTML or
    ExtJS widgets.
    Isn't that how Catalyst works already?

    When processing my forms the code has no idea if it was submitted via
    AJAX or standard post. And in the cases where a controller is shared
    between AJAX non-AJAX requests the controller typically doesn't know
    what the final output will be.

    For example, my main template dispatcher knows to not wrap a template
    in the site's layout if the request is an AJAX request. And the view
    knows to generate JSON vs. html, as well.

    Indeed, for simple partial page updates via AJAX (sorting, paging)
    turning off javascript results in almost all the same code executing.

    If I was to start over I might be more inclined to use
    Catalyst::Action::REST as described in:

    http://catalyst.perl.org/calendar/2006/9
    http://catalyst.perl.org/calendar/2007/2

    Although, I'm not sure I it can ever be that simple when it comes to
    coding the real application. In general the stash that's needed for
    the html template isn't always the same one to expose in JSON or XMLRPC
    responses.



    --
    Bill Moseley
    moseley@hank.org
  • Dami Laurent (PJ) at Dec 5, 2007 at 7:54 am

    -----Message d'origine-----
    De : Ashley Pond V
    Envoy? : mercredi, 5. d?cembre 2007 02:47
    ? : The elegant MVC web framework
    Objet : [Catalyst] State of the art in form validation;
    opinion poll... Model based forms/validation?

    I'm playing with CP::FormValidator::Simple and I like it all right
    but I feel like there must be something better than it and
    CP::FormValidator. [snip]
    I'm leaning more and more to having *all* of this stuff defined
    (validation patterns, user messages for invalid input, clues for CGI
    fields) in the Model (DBIC; I love it and never find time to try
    Rose). Sort of a super phat Model. If it's not defined exclusively
    there, it ends up defined there (via schema), the controller,
    possibly the templates (messages), and even client-side in JS. I know
    I'm showing my tremendous grasp of the obvious when I say, this is
    just effing awful.

    What are best practices? DBIx::Class::Validation reusing your form
    package profiles? But you still have to write your own forms. I've
    searched around a lot and can't find a thorough, coherent Catalyst
    related doc about it.

    I really want one, final approach to this I'll use every time from
    now on instead of experimenting with packages and home rolled stuff
    over and over. If someone is there, or even close. Please kick down.

    As always, I appreciate everyone's time and expertise.

    Thanks!
    -Ashley
    Hi Ashley,

    We are building a big application for State of Geneva, and here is what we do :

    - assemble HTML forms using plain Template Toolkit. Initial values are all empty. Field names use a dot notation ? la CGI::Expand.

    - initial data is passed as a JSON tree, and some javascript code on the client-side fills the form from that tree. Users can also save the tree locally and reload it into the form later.

    - upon submit, the form data is sent through Ajax. The server pipes that data into CGI::Expand, and then into Data::Domain. If the data is OK, it performs the action; otherwise it returns a JSON tree of error messages. Javascript code on the client-side navigates through these messages and puts the focus on appropriate fields.

    So all business rules and error messages are described in Data::Domain. The actual data storage is maintained independently by the DBA, directly within the database. Inbetween sits DBIx::DataModel, a thin ORM that deals mostly with associations through primary and foreign keys, but knows very little about other columns (data just passes through).

    So in contrast with some other approaches, here the data description is not centralized : if you add a new field, you have to act on the database, on the Data::Domain validation rules, and on the Template displaying the form. For quick scaffolding of an application, this would definitely be slower, but in the long run it pays off, because each component does just what it knows best to do : storing the data, presenting the data, validating the data. And you can have different people with different skills maintaining these 3 sides.

    This approach was presented at YAPC::EU::07; you can grab the slides at http://laurent.dami.free.fr/slides/YAPC07/

    Enjoy,

    Laurent Dami
  • Carl Franks at Dec 5, 2007 at 9:16 am

    On 05/12/2007, Ashley Pond V wrote:
    What are best practices? DBIx::Class::Validation reusing your form
    package profiles? But you still have to write your own forms. I've
    searched around a lot and can't find a thorough, coherent Catalyst
    related doc about it.

    I really want one, final approach to this I'll use every time from
    now on instead of experimenting with packages and home rolled stuff
    over and over. If someone is there, or even close. Please kick down.
    I'm really happy with how HTML::FormFu is coming along.
    Like your example, you can define your entire form in any config file
    Config::Any supports. Although I (predictably) prefer the FormFu style
    declarations.

    It has lots of little shortcuts that make things easier, such as auto_label().
    If you set, for example, auto_label('label_%n') at the form-level,
    then all fields will automatically use localize() to set their own
    label (replacing the '%n' with their field name).
    Like many settings, this can be set at either the form-, the
    fieldset-, or the field-level, and when the method's used as a
    'getter', it traverses the field's parents, searching for a value.

    There's also an auto_error_message() which can get error messages from
    your localize() object, based on the field's name and/or type.

    (the next couple of features are currently only in svn, and will be
    released to cpan in the next week...)

    By default, the form's markup is generated internally by perl
    subroutines. However, by simply setting render_method('tt') it
    switches to using TT templates (which are installed using
    File::ShareDir) and generates the exact same markup.
    If you wish to customise the form markup, you can create a local copy
    of the templates, and change the form however you want.
    You can also use your own, single TT file, much like claco's example
    earlier in this thread, explicitly placing individual fields.

    There's also DBIC integration, which I'm currently in the process of
    documenting - again, on it's way to cpan soon.

    If you had, say, these 2 tables:

    table: user
    cols: name
    might_have: address

    table: address
    cols: user, street, city
    belongs_to: user

    Then you could create a form like so:

    ---
    elements:
    - name: name

    - type: Fieldset
    nested_name: address
    elements:
    - name: street
    - name: city

    - type: Submit

    If you then pass that form a 'user' row, it will automatically
    traverse the 'address' relationship, filling in the form fields:
    $form->values_from_model( $user_row );

    And when the form's submitted, you can save the changes back to the
    database, again, automatically following the relationship:
    $form->save_to_model( $user_row );

    It also handles has_one, has_many, and many_to_many relationships.

    To finish off, here's an example of how I'd probably write your form
    (as far as I can interpret it):

    ---
    auto_fieldset:
    legend: user

    elements:
    - name: last_name
    constraints:
    - type: Required
    - type: Length
    max: 50

    - name: suffix
    constraints:
    - type: Regex
    regex: '?-xism:\A[IVX]{1,3}\z'

    - name: email
    constraints:
    - type: Required
    - type: Email
    - type: Length
    max: 80

    - type: Submit

    If you're interested in looking further, the svn location is:
    http://html-formfu.googlecode.com/svn/trunk/HTML-FormFu
    or you can ask any questions on the mailing list:
    http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/html-formfu

    Cheers,
    Carl
  • Zbigniew Lukasiak at Dec 5, 2007 at 1:06 pm
    What I like about the FormFu approach is that it gives you a *path*
    for the development. For a quick start you just stay with the
    defaults - they still are displayed OK and you can show the project to
    someone. Then when need to customise it's look and feel you generate
    the templates and tickle them to submission.

    --
    Zbyszek
    On Dec 5, 2007 9:16 AM, Carl Franks wrote:
    On 05/12/2007, Ashley Pond V wrote:
    What are best practices? DBIx::Class::Validation reusing your form
    package profiles? But you still have to write your own forms. I've
    searched around a lot and can't find a thorough, coherent Catalyst
    related doc about it.

    I really want one, final approach to this I'll use every time from
    now on instead of experimenting with packages and home rolled stuff
    over and over. If someone is there, or even close. Please kick down.
    I'm really happy with how HTML::FormFu is coming along.
    Like your example, you can define your entire form in any config file
    Config::Any supports. Although I (predictably) prefer the FormFu style
    declarations.

    It has lots of little shortcuts that make things easier, such as auto_label().
    If you set, for example, auto_label('label_%n') at the form-level,
    then all fields will automatically use localize() to set their own
    label (replacing the '%n' with their field name).
    Like many settings, this can be set at either the form-, the
    fieldset-, or the field-level, and when the method's used as a
    'getter', it traverses the field's parents, searching for a value.

    There's also an auto_error_message() which can get error messages from
    your localize() object, based on the field's name and/or type.

    (the next couple of features are currently only in svn, and will be
    released to cpan in the next week...)

    By default, the form's markup is generated internally by perl
    subroutines. However, by simply setting render_method('tt') it
    switches to using TT templates (which are installed using
    File::ShareDir) and generates the exact same markup.
    If you wish to customise the form markup, you can create a local copy
    of the templates, and change the form however you want.
    You can also use your own, single TT file, much like claco's example
    earlier in this thread, explicitly placing individual fields.

    There's also DBIC integration, which I'm currently in the process of
    documenting - again, on it's way to cpan soon.

    If you had, say, these 2 tables:

    table: user
    cols: name
    might_have: address

    table: address
    cols: user, street, city
    belongs_to: user

    Then you could create a form like so:

    ---
    elements:
    - name: name

    - type: Fieldset
    nested_name: address
    elements:
    - name: street
    - name: city

    - type: Submit

    If you then pass that form a 'user' row, it will automatically
    traverse the 'address' relationship, filling in the form fields:
    $form->values_from_model( $user_row );

    And when the form's submitted, you can save the changes back to the
    database, again, automatically following the relationship:
    $form->save_to_model( $user_row );

    It also handles has_one, has_many, and many_to_many relationships.

    To finish off, here's an example of how I'd probably write your form
    (as far as I can interpret it):

    ---
    auto_fieldset:
    legend: user

    elements:
    - name: last_name
    constraints:
    - type: Required
    - type: Length
    max: 50

    - name: suffix
    constraints:
    - type: Regex
    regex: '?-xism:\A[IVX]{1,3}\z'

    - name: email
    constraints:
    - type: Required
    - type: Email
    - type: Length
    max: 80

    - type: Submit

    If you're interested in looking further, the svn location is:
    http://html-formfu.googlecode.com/svn/trunk/HTML-FormFu
    or you can ask any questions on the mailing list:
    http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/html-formfu

    Cheers,
    Carl


    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
    Dev site: http://dev.catalyst.perl.org/


    --
    Zbigniew Lukasiak
    http://brudnopis.blogspot.com/

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedDec 5, '07 at 1:47a
activeDec 6, '07 at 3:13p
posts13
users10
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2022 Grokbase