FAQ
I've started implementing yet another form validator, main goals are
elegant syntax and integrated xml generator.

Features on the todo so far:

* Pluggable element/constraint support
(HTML::Widget::Element::Textfield, HTML::Widget::Constraint::String...)
* Both validation and xml generation are optional
* Clean xml output (easy to style with css)
* Chained accessors (makes complex data look simple)
* Extendable enough to support all kinds of Ajax hacks
* Client side JS validation


Here's a mockup:

use HTML::Widget;

my $w = HTML::Widget->new( { method => 'POST, 'action => '/foo/
action' } );
$w->element( 'Textfield', 'age' )->label('Age')->size(3);
$w->element( 'Textfield', 'name' )->label('Name')->size(60);
$w->element( 'Submit', 'ok' )->value('OK');
$w->constraint( 'Integer', 'age' )->message('No integer.');
$w->constraint( 'Required', 'age', 'name' )->message('Missing
value.');
my $form = $w->process;
my $form = $w->process($query);

[% form.as_xml %]

[% FOREACH element = form.errors %]
<p>
[% element %]:<br/>
<ul>
[% FOREACH message = form.messages(element) %]
<li>[% element %]:</li>
[% END %]
</ul>
</p>
[% END %]

<p><ul>
[% FOREACH element = form.errors %]
[% IF result.error( element, 'Integer' ) %]
<li>[% element %] has to be an integer.</li>
[% END %]
[% END %]
</ul></p>


The output of as_xml() is not yet defined, need a designer to create
a simple easy to theme form.
And no, there are no alternatives on CPAN that fit all my needs.


--
sebastian

Search Discussions

  • John Siracusa at Dec 1, 2005 at 1:17 am

    On 11/30/05 6:15 PM, Sebastian Riedel wrote:
    I've started implementing yet another form validator, main goals are
    elegant syntax and integrated xml generator.
    [...]
    And no, there are no alternatives on CPAN that fit all my needs.
    Can you list your needs? So far, it sounds to me like you could build what
    you want on top of Rose::HTML::Objects...and get some useful extra features
    as well (e.g., input/output filters, inflate/deflate, and compound fields)

    -John
  • Bill Moseley at Dec 1, 2005 at 7:29 am

    On Thu, Dec 01, 2005 at 12:15:17AM +0100, Sebastian Riedel wrote:
    Here's a mockup:

    use HTML::Widget;

    my $w = HTML::Widget->new( { method => 'POST, 'action => '/foo/
    action' } );
    $w->element( 'Textfield', 'age' )->label('Age')->size(3);
    $w->element( 'Textfield', 'name' )->label('Name')->size(60);
    $w->element( 'Submit', 'ok' )->value('OK');
    $w->constraint( 'Integer', 'age' )->message('No integer.');
    $w->constraint( 'Required', 'age', 'name' )->message('Missing
    value.');
    So are you defining a text field "age" and then adding an Integer
    constraint to that field? Kind of like DFV, where you define a field
    and then add constraints on that field?

    Seems like there's only a handful of different types of fields. So,
    how about $w->element( 'AgeField', age ) which knows it should be in
    the range of 0 to 200 (with a bit of luck). And then add additional
    validation if needed when you need a specific range.
    [% form.as_xml %]
    Is that the entire form? I can't imagine that working in most cases
    -- forms always seem to need to be customized, so I find that I have
    to build the form field-by-field in the template.

    One thing I think would be useful is to define reusable fieldsets that
    could be put together to make a form. An example might be an address
    that is made up of multiple fields. Often you might have multiple
    forms that include a place to enter an address. So it would be nice
    to define an object that represents an address and can be used on
    multiple forms. Rose-HTML-Objects can build multiple element fields,
    but I'm not sure if you can defined "formlets" and connect them
    together into a larger form.

    Unedited and a bit wordy, but here's my form setup:

    http://nopaste.snit.ch:8001/5611

    Perhaps forms are like templating systems -- everyone needs to write
    one once.


    --
    Bill Moseley
    moseley@hank.org
  • Sebastian Riedel at Dec 1, 2005 at 9:20 am

    Am 01.12.2005 um 07:35 schrieb Bill Moseley:
    On Thu, Dec 01, 2005 at 12:15:17AM +0100, Sebastian Riedel wrote:
    Here's a mockup:

    use HTML::Widget;

    my $w = HTML::Widget->new( { method => 'POST, 'action => '/foo/
    action' } );
    $w->element( 'Textfield', 'age' )->label('Age')->size(3);
    $w->element( 'Textfield', 'name' )->label('Name')->size(60);
    $w->element( 'Submit', 'ok' )->value('OK');
    $w->constraint( 'Integer', 'age' )->message('No integer.');
    $w->constraint( 'Required', 'age', 'name' )->message('Missing
    value.');
    So are you defining a text field "age" and then adding an Integer
    constraint to that field? Kind of like DFV, where you define a field
    and then add constraints on that field?

    Seems like there's only a handful of different types of fields. So,
    how about $w->element( 'AgeField', age ) which knows it should be in
    the range of 0 to 200 (with a bit of luck). And then add additional
    validation if needed when you need a specific range.
    Hooks are already there. :)
    [% form.as_xml %]
    Is that the entire form? I can't imagine that working in most cases
    -- forms always seem to need to be customized, so I find that I have
    to build the form field-by-field in the template.
    I've just uploaded a new snapshot that has exactly this feature. :)

    my @form = $f->element;
    my $age = $f->element('age');
    print $age->label_xml;
    print $age->element_xml;
    print $age->error_xml;


    --
    sebastian
  • John Siracusa at Dec 1, 2005 at 2:13 pm

    On 12/1/05 1:35 AM, Bill Moseley wrote:
    One thing I think would be useful is to define reusable fieldsets that
    could be put together to make a form. An example might be an address
    that is made up of multiple fields. Often you might have multiple
    forms that include a place to enter an address. So it would be nice
    to define an object that represents an address and can be used on
    multiple forms. Rose-HTML-Objects can build multiple element fields,
    but I'm not sure if you can defined "formlets" and connect them
    together into a larger form.
    You can just define an actual form for each fieldset, then aggregate all the
    sub-forms in a single master form. You'd extract each sub-form's fields in
    the master form's build_form() method, and you'd call each sub-form's
    validate() method from the master form's validate() method.

    Or, of course, you can also make a single compound "address" field have have
    it return an Address object. But then you'd need an address() attribute on
    your db object (or whatever) that knows how to pull the individual pieces of
    information out of an Address object as needed. (Or you could do that from
    within your controller too, I suppose.)

    -John
  • Sebastian Riedel at Dec 1, 2005 at 7:56 am
    Here are some first preview releases. :)

    http://files.oook.de/HTML-Widget-1.0.tar.gz
    http://files.oook.de/Catalyst-Plugin-HTML-Widget-1.0.tar.gz

    All the basics are implemented, missing are just JavaScript
    validators, inline error messages and more Elements/Constraints.
    Constraints should also get a bit more clever in the future, so they
    can auto-select/generate the right Element for you. ;)

    I've picked lots of features from DFV, DFV::Simple,
    CGI::FormBuilder...yada yada.
    FillInForm is also built-in and is much faster because we don't have
    to use a HTML parser!

    Examples:

    use HTML::Widget;

    # Create a widget
    my $w = HTML::Widget->new( { method => 'GET', action => '/foo/
    action' } );

    # Add some Elements
    $w->element( 'Textfield', 'age' )->label('Age')->size(3);
    $w->element( 'Textfield', 'name' )->label('Name')->size(60);
    $w->element( 'Submit', 'ok' )->value('OK');

    # Add some Constraints
    $w->constraint( 'Integer', 'age' )->message('No integer.');
    $w->constraint( 'Required', 'age', 'name' )->message('Missing
    value.');

    # Process it to a form
    my $form = $w->process;
    my $form = $w->process($query);

    my $xml = "$form"; # Yes, this really generates all the xml!

    [% form %]

    [% FOREACH element = form.errors %]
    <p>
    [% element %]:<br/>
    <ul>
    [% FOREACH message = form.messages(element) %]
    <li>[% element %]:</li>
    [% END %]
    </ul>
    </p>
    [% END %]

    <p><ul>
    [% FOREACH element = form.errors %]
    [% IF result.error( element, 'Integer' ) %]
    <li>[% element %] has to be an integer.</li>
    [% END %]
    [% END %]
    </ul></p>


    # And the Catalyst version ;)
    use Catalyst qw/HTML::Widget/;

    $c->widget( { method => 'GET', action => '/foo/action' } );

    $c->widget->element( 'Textfield', 'age' )->label('Age')->size(3);
    $c->widget->element( 'Textfield', 'name' )->label('Name')->size
    (60);
    $c->widget->element( 'Submit', 'ok' )->value('OK');

    $c->widget->constraint( 'Integer', 'age' )->message('No integer.');
    $c->widget->constraint( 'Required', 'age', 'name' )
    ->message('Missing value.');

    my $form = $c->widget->process;
    my $form = $c->widget->process($query);


    Not bad for 6 hours of work, eh? Now I better try to sleep a bit...


    --
    sebastian
  • Sebastian Riedel at Dec 1, 2005 at 10:33 am
    Now maintained in trunk, patches welcome.

    http://dev.catalyst.perl.org/repos/Catalyst/trunk/HTML-Widget/


    --
    sebastian
  • Yuval Kogman at Dec 1, 2005 at 8:08 am

    On Thu, Dec 01, 2005 at 00:15:17 +0100, Sebastian Riedel wrote:
    [% form.as_xml %]

    [% FOREACH element = form.errors %]
    <p>
    [% element %]:<br/>
    <ul>
    [% FOREACH message = form.messages(element) %]
    <li>[% element %]:</li>
    [% END %]
    </ul>
    </p>
    [% END %]

    Please also add


    $form->integrated_errors(1);

    [% form.as_xml %]

    should allow you to just style

    .error {
    border: 1px solid red;
    }

    and get small div or something around the actual form element, with
    the error text just before or after the <input>.

    Another thing to add is to please please please allow:

    1. good default error strings (validators know how to compose
    error messages with each other)

    2. as_xml should be easily broken up so that you can layout your
    form more freely:

    iterate elements by order

    extract elements by name

    be able to compose groups of elements, and iterate those

    --
    () Yuval Kogman <nothingmuch@woobling.org> 0xEBD27418 perl hacker &
    /\ kung foo master: /me supports the ASCII Ribbon Campaign: neeyah!!!

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 189 bytes
    Desc: not available
    Url : http://lists.rawmode.org/pipermail/catalyst/attachments/20051201/74ef50fe/attachment-0001.pgp
  • Sebastian Riedel at Dec 1, 2005 at 9:28 am

    Am 01.12.2005 um 08:13 schrieb Yuval Kogman:
    On Thu, Dec 01, 2005 at 00:15:17 +0100, Sebastian Riedel wrote:
    [% form.as_xml %]

    [% FOREACH element = form.errors %]
    <p>
    [% element %]:<br/>
    <ul>
    [% FOREACH message = form.messages(element) %]
    <li>[% element %]:</li>
    [% END %]
    </ul>
    </p>
    [% END %]

    Please also add


    $form->integrated_errors(1);

    [% form.as_xml %]

    should allow you to just style

    .error {
    border: 1px solid red;
    }

    and get small div or something around the actual form element, with
    the error text just before or after the <input>.

    Another thing to add is to please please please allow:

    1. good default error strings (validators know how to compose
    error messages with each other)

    2. as_xml should be easily broken up so that you can layout your
    form more freely:

    iterate elements by order

    extract elements by name

    be able to compose groups of elements, and iterate those
    All implemented in the new snapshot. :)




    --
    sebastian
  • Mikhail Shevchuk at Dec 2, 2005 at 6:09 pm
    Is there something similar to form.as_html('<>&'); It is useful I think
    to define unsafe characters.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedDec 1, '05 at 12:06a
activeDec 2, '05 at 6:09p
posts10
users5
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2022 Grokbase