FAQ
I've always admired the form helpers used by Rails (see [1]) - essentially
helpers for use in templates for creating form controls that are linked to
underlying model objects so that they can be pre-populated and so that the
controls can be named to make subsequent update of the objects easy. It
strikes me that something like this could be useful when creating forms
that are more complex then solutions like HTMLWidget can conveniently cope
with.

Catalyst-Plugin-Params-Nested already provides support for something very
like the Rails naming scheme, but I can't see anything that provides
anything like the helpers themselves. Before I start creating something,
probably as a DBIx::Class component, please can anyone tell me if I'm
re-inventing the wheel?

Jon.

[1] http://api.rubyonrails.org/classes/ActionView/Helpers/FormHelper.html#M000389

--
Jon Warbrick
Web/News Development, Computing Service, University of Cambridge

Search Discussions

  • Ash Berlin at Sep 20, 2006 at 4:58 pm

    Jon Warbrick wrote:
    I've always admired the form helpers used by Rails (see [1]) - essentially
    helpers for use in templates for creating form controls that are linked to
    underlying model objects so that they can be pre-populated and so that the
    controls can be named to make subsequent update of the objects easy. It
    strikes me that something like this could be useful when creating forms
    that are more complex then solutions like HTMLWidget can conveniently cope
    with.

    Catalyst-Plugin-Params-Nested already provides support for something very
    like the Rails naming scheme, but I can't see anything that provides
    anything like the helpers themselves. Before I start creating something,
    probably as a DBIx::Class component, please can anyone tell me if I'm
    re-inventing the wheel?

    Jon.

    [1] http://api.rubyonrails.org/classes/ActionView/Helpers/FormHelper.html#M000389
    Maybe look at FormBuilder. (?)

    Also suggest a situation that is "complex then solutions like HTMLWidget
    can conveniently cope with" and I'll tell you if it is (or will be -
    refactor is coming)

    Ash Berlin
  • Jon Warbrick at Sep 21, 2006 at 9:25 am

    On Wed, 20 Sep 2006, Ash Berlin wrote:

    Maybe look at FormBuilder. (?)
    Definitely a possibility, but I haven't got my head around it yet...
    Also suggest a situation that is "complex then solutions like HTMLWidget
    can conveniently cope with" and I'll tell you if it is (or will be -
    refactor is coming)
    person, telephone_number and email_address have multiple columns. person
    has_many telephone_numbers, person has_many email_addresses. I want a form
    to manage information about a particular person, including the ability to
    update existing telephone numbers and email addresses, and with buttons to
    delete any particular number and to add new ones. I don't think HTMLWidget
    can do that (though I'd be happy to be proved wrong).

    There is also the issue that a complex form it may need careful manual
    layout of the various controls to make it usable. As I see it this is
    something for the designer to do, working in the relevant templates,
    whereas with HTMLWidget at least the ordering and grouping, and to some
    extent the layout, is defined in the model class. I accept there is much
    that can be done about this with CSS, but I also suspect that there are
    some things that can't.

    Jon.

    --
    Jon Warbrick
    Web/News Development, Computing Service, University of Cambridge
  • Andreas Marienborg at Sep 21, 2006 at 9:41 am

    On 21. sep. 2006, at 11.25, Jon Warbrick wrote:
    On Wed, 20 Sep 2006, Ash Berlin wrote:

    Maybe look at FormBuilder. (?)
    Definitely a possibility, but I haven't got my head around it yet...
    Also suggest a situation that is "complex then solutions like
    HTMLWidget
    can conveniently cope with" and I'll tell you if it is (or will be -
    refactor is coming)
    There is also the issue that a complex form it may need careful manual
    layout of the various controls to make it usable. As I see it this is
    something for the designer to do, working in the relevant templates,
    whereas with HTMLWidget at least the ordering and grouping, and to
    some
    extent the layout, is defined in the model class. I accept there is
    much
    that can be done about this with CSS, but I also suspect that there
    are
    some things that can't.

    You dont need to use HTML::Widgets as_xml method to render your form
    you know. You can get each field and place them however you want, or
    write your own HTML for that matter.

    HTML::Widget doesnt know what posted to it, so you dont need it to be
    the HTML it would generate, although the names of the fields must
    match ofc.

    andreas
  • Zbigniew Lukasiak at Sep 21, 2006 at 9:50 am
    Hi,

    Commenting on:
    person, telephone_number and email_address have multiple columns. person
    has_many telephone_numbers, person has_many email_addresses. I want a form
    to manage information about a particular person, including the ability to
    update existing telephone numbers and email addresses, and with buttons to
    delete any particular number and to add new ones.
    This is what I am trying to do in Catalyst::Example::Controller::InstantCRUD
    - the form is generated from the database schema and then when you do update
    the respective tables are updated. It works - but I am not happy with the
    overall architecture and as I've wrote in my previous email I am now
    rethinking the whole concept. In the new version the form is generated from
    an intermediate config not directly from the db schema.

    The whole thing is a app generator (scaffolding) - but my goal is to
    Catalyst::Example::Controller::InstantCRUD usable also without the
    generator.

    --
    Zbyszek


    On 9/21/06, Jon Warbrick wrote:
    On Wed, 20 Sep 2006, Ash Berlin wrote:

    Maybe look at FormBuilder. (?)
    Definitely a possibility, but I haven't got my head around it yet...
    Also suggest a situation that is "complex then solutions like HTMLWidget
    can conveniently cope with" and I'll tell you if it is (or will be -
    refactor is coming)
    person, telephone_number and email_address have multiple columns. person
    has_many telephone_numbers, person has_many email_addresses. I want a form
    to manage information about a particular person, including the ability to
    update existing telephone numbers and email addresses, and with buttons to
    delete any particular number and to add new ones. I don't think HTMLWidget
    can do that (though I'd be happy to be proved wrong).

    There is also the issue that a complex form it may need careful manual
    layout of the various controls to make it usable. As I see it this is
    something for the designer to do, working in the relevant templates,
    whereas with HTMLWidget at least the ordering and grouping, and to some
    extent the layout, is defined in the model class. I accept there is much
    that can be done about this with CSS, but I also suspect that there are
    some things that can't.

    Jon.

    --
    Jon Warbrick
    Web/News Development, Computing Service, University of Cambridge

    _______________________________________________
    List: Catalyst at lists.rawmode.org
    Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
    Searchable archive:
    http://www.mail-archive.com/catalyst at lists.rawmode.org/
    Dev site: http://dev.catalyst.perl.org/


    --
    Zbigniew Lukasiak
    http://brudnopis.blogspot.com/
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.rawmode.org/pipermail/catalyst/attachments/20060921/02c85e90/attachment.htm
  • Bill Moseley at Sep 21, 2006 at 12:46 pm

    On Thu, Sep 21, 2006 at 10:25:37AM +0100, Jon Warbrick wrote:
    person, telephone_number and email_address have multiple columns. person
    has_many telephone_numbers, person has_many email_addresses. I want a form
    to manage information about a particular person, including the ability to
    update existing telephone numbers and email addresses, and with buttons to
    delete any particular number and to add new ones. I don't think HTMLWidget
    can do that (though I'd be happy to be proved wrong).
    The form code I use handles this -- by looking at the relationships of
    the object its updating. One-to-many relationships end up as
    drop-downs or radio selects (depending on the size of the option list)
    and many-to-many are either checkbox groups or multi-select drop-
    downs.

    I can handle multi-widget fields (area code + prefix + number or date
    + time) but I don't use those -- I just uses simple text input fields
    and parse and validate. (It also drives me crazy when I see
    instructions on fields "Enter credit card number without the dashes".)

    You should check out Rose::HTML::Objects if you have not already.


    There is also the issue that a complex form it may need careful manual
    layout of the various controls to make it usable. As I see it this is
    something for the designer to do, working in the relevant templates,
    Yes, my forms code doesn't do any layout of the fields. I do that
    manually. I always seem to need to hand tweak the layout of the
    forms.

    Also, my form code doesn't generate the actual html -- again, that's
    done in a separate template. Most of the formatting is with css, but
    I can use a different form template if I want to change the field
    generation in ways the css can't handle.


    My forms are all (well almost all) separate modules. So my
    controllers looks like this:

    sub edit : Local {
    my ( $self, $c, $id ) = @_;

    $c->stash->{form} = WS2::Form::Admin::Organization->new( $id );

    # Now validate
    $c->stash->{form}->update_from_form( $c->req->parameters )
    if $c->form_posted;
    }


    With the form module:

    package WS2::Form::Admin::Organization;
    use strict;
    use warnings;
    use base 'Form::Model::CDBI';


    # Define the object class that this form handles
    sub object_class { 'DB::Organization' }



    sub profile {
    my ( $self ) = @_;

    return {
    required => {
    name => 'Text',
    active => 'Boolean',
    organization_type => 'Select',
    groups => 'Multiple',
    },

    optional => {
    parent_organization => 'Select',
    contact => 'Text',
    email => 'Email',
    phone => 'Phone',
    address1 => 'Text',
    address2 => 'Text',
    city => 'Text',
    state => 'Select',
    zip => 'USZipcode',
    url => 'URL',
    comment => 'TextArea',
    },
    dependency => [
    [qw/ address1 city state zip /],
    ],
    };
    }

    # extra validation can be here:

    sub validate_foo {
    my ( $form, $field ) = @_;

    $field->add_error('Foo must be "bar"')
    unless $field->value eq 'bar';
    }


    1;


    Then finally, the form that handles the above would looks something
    like:

    [% # Form to edit an oranization

    item = form.item;

    page.title = 'Organization: ' _ (item ? item.name : 'New Entry');
    page_heading;

    page_link( 'list', 'list all organizations' );

    WRAPPER form_wrapper; PROCESS fields; END;

    %]


    [% BLOCK fields;

    "<fieldset><legend>Organization Information</legend>";
    field('Organization Name', 'name');
    field('Organization Type', 'organization_type' );
    field('Organization Active', 'active');
    field('Member Of Groups', 'groups' );

    field('Parent Organization', 'parent_organization' );

    field('Contact Person', 'contact');
    field('Phone', 'phone',
    'Please enter the number to reach the contact');

    field('Email', 'email');
    field('URL', 'url');
    "</fieldset>";


    "<fieldset><legend>Mailing Address</legend>";
    field('Address line 1', 'address1' );
    field('Address line 2', 'address2' );
    city_state_zip(); # does ajax updated zip-lookup.
    "</fieldset>";

    END %]


    --
    Bill Moseley
    moseley at hank.org
  • Zbigniew Lukasiak at Sep 21, 2006 at 7:04 am
    Hi,

    I don't know if I grap the idea of the helpers in full - could you explain
    their functions here in short? For me it looks like they just create form
    elements just like the $w->element('...', '...') does. There is something
    also about using them for the updates - could you a bit elaborate on that?
    HTML::Widget also works on the update side - at least can check the
    constraints, but it does not set values of an object - do the RoR helpers?

    In related news I am working on Catalyst::Example::InstantCRUD - a kind of
    scaffolding for Catalyst with DBIx::Class as persistance layer. It has some
    code to autogenerate the forms from the DBIx::Class schema - but I am not
    happy with it and just now I am restructuring it to use a config, generated
    from the schema instead of using the schema directly.

    --
    Zbyszek
    On 9/20/06, Jon Warbrick wrote:

    I've always admired the form helpers used by Rails (see [1]) - essentially
    helpers for use in templates for creating form controls that are linked to
    underlying model objects so that they can be pre-populated and so that the
    controls can be named to make subsequent update of the objects easy. It
    strikes me that something like this could be useful when creating forms
    that are more complex then solutions like HTMLWidget can conveniently cope
    with.

    Catalyst-Plugin-Params-Nested already provides support for something very
    like the Rails naming scheme, but I can't see anything that provides
    anything like the helpers themselves. Before I start creating something,
    probably as a DBIx::Class component, please can anyone tell me if I'm
    re-inventing the wheel?

    Jon.

    [1]
    http://api.rubyonrails.org/classes/ActionView/Helpers/FormHelper.html#M000389

    --
    Jon Warbrick
    Web/News Development, Computing Service, University of Cambridge

    _______________________________________________
    List: Catalyst at lists.rawmode.org
    Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
    Searchable archive:
    http://www.mail-archive.com/catalyst at lists.rawmode.org/
    Dev site: http://dev.catalyst.perl.org/


    --
    Zbigniew Lukasiak
    http://brudnopis.blogspot.com/
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.rawmode.org/pipermail/catalyst/attachments/20060921/99dee908/attachment.htm
  • Jon Warbrick at Oct 13, 2006 at 12:42 pm
    Sorry, I've been a bit slow replying to your questions :-)
    On Thu, 21 Sep 2006, Zbigniew Lukasiak wrote:

    I don't know if I grap the idea of the helpers in full - could you explain
    their functions here in short? For me it looks like they just create form
    elements just like the $w->element('...', '...') does.
    Yes, that's about it. They are just shortcuts for use in templates to
    create form elements, except that

    1) They deal with the stickiness/defaulting for you; and

    2) They know how to name the elements to make updating the underlying
    model objects easier. So a text box for editing the 'name' field of a
    person record might be called 'person.name' (see below).

    2) They know about the error flags that appear in the model objects
    following validation failure and so can adapt their behaviour
    accordingly (display with error flags, add error messages, etc).
    There is something
    also about using them for the updates - could you a bit elaborate on that?
    On form submission, these parameters are parsed into data structures in
    the equivalent of $req->parameters (so the edited name value from above
    might be in $req->parameters->{person}->{name}). The huge value of this is
    that the model objects can directly accept these structures for creation
    or update, e.g.

    $c->model('Person')->update($req->parameters->{person});
    HTML::Widget also works on the update side - at least can check the
    constraints, but it does not set values of an object - do the RoR helpers?
    A lot of this functionality exists in HTML::Widget. The main difference
    seems to be that in HTML::Widget you decide how you want your form
    controls to look in the model class, and in Rails you do it in the
    template.

    Jon.

    --
    Jon Warbrick
    Web/News Development, Computing Service, University of Cambridge
  • Zbigniew Lukasiak at Oct 16, 2006 at 8:41 am

    I was thinking a bit about this:
    in HTML::Widget you decide how you want your form
    controls to look in the model class, and in Rails you do it in the
    template
    The standard answer to that is that the looks should be defined in the
    CSS, but actually I don't buy that argument. It is good for the start
    but then there are too many things that you need eventually to tweak
    about the HTML. So eventually you start replacing more and more of
    the generated HTML with the templates and in the end you would use
    only the validation part of HTML::Widget.

    This is very similar to the scaffolding idea and I think HTML::Widget
    should support this process. Now we can generate the whole form by
    HTML::Widget or use only the validation part, with the iteration over
    the elements we can generate the elements but not the whole form and
    at the last step we can have the whole HTML in the templates and use
    only the validation part of HTML::Widget. We can add yet another
    intermediate step by delaying the declaration of a input type to the
    call in the templates. Something like:

    In controller: my $el = $w->element('age'); $el->constraint( ....
    In template: [% w.render_element('age, 'Textfield') %]

    --
    Zbyszek

    - but than this would leave only the validation part in the HTML::Widget

    On 10/13/06, Jon Warbrick wrote:
    Sorry, I've been a bit slow replying to your questions :-)
    On Thu, 21 Sep 2006, Zbigniew Lukasiak wrote:

    I don't know if I grap the idea of the helpers in full - could you explain
    their functions here in short? For me it looks like they just create form
    elements just like the $w->element('...', '...') does.
    Yes, that's about it. They are just shortcuts for use in templates to
    create form elements, except that

    1) They deal with the stickiness/defaulting for you; and

    2) They know how to name the elements to make updating the underlying
    model objects easier. So a text box for editing the 'name' field of a
    person record might be called 'person.name' (see below).

    2) They know about the error flags that appear in the model objects
    following validation failure and so can adapt their behaviour
    accordingly (display with error flags, add error messages, etc).
    There is something
    also about using them for the updates - could you a bit elaborate on that?
    On form submission, these parameters are parsed into data structures in
    the equivalent of $req->parameters (so the edited name value from above
    might be in $req->parameters->{person}->{name}). The huge value of this is
    that the model objects can directly accept these structures for creation
    or update, e.g.

    $c->model('Person')->update($req->parameters->{person});
    HTML::Widget also works on the update side - at least can check the
    constraints, but it does not set values of an object - do the RoR helpers?
    A lot of this functionality exists in HTML::Widget. The main difference
    seems to be that in HTML::Widget you decide how you want your form
    controls to look in the model class, and in Rails you do it in the
    template.

    Jon.

    --
    Jon Warbrick
    Web/News Development, Computing Service, University of Cambridge

    _______________________________________________
    List: Catalyst at lists.rawmode.org
    Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst at 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
postedSep 20, '06 at 4:36p
activeOct 16, '06 at 8:41a
posts9
users5
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2021 Grokbase