[Html-widget] HTML-FormFu example xhtml

[Carl Franks]

On 30/01/07, Xavier Robin <robin0 at etu.unige.ch> wrote:
> On Friday 19 January 2007 18:41, Carl Franks wrote:
> > I've mentioned a couple of times recently that I've been working on a
> > replacement for H-W.
> > It's codename is HTML::FormFu, and I've decided to post an example of
> > the markup it currently generates, including example css, in case
> > anyone's interested in giving feedback.
>
> Well, even if I am a bit late, I think it looks pretty nice.
> I think it is a really sensible evolution for HTML::Widget, even if I'm not
> sure to see the point of having this under another name... wouldn't it be
> backward-compatible with HTML::Widget?

It's similar, but not back-compatible.
I'll not go into details, as some parts of the API have changed even
since that example file, as it's getting used in different ways.
I'm not wanting to release anything until it's settled down a bit more.

> I like the "add_container_attrs()" and "content()", as I was somewhat
> frustrated not to be able to add markup in select options (I hope it is what
> content is really intended for...).
> The "comment()" is nice also, but it would be even better if it allowed HTML
> (but perhaps it does?) and if one could define comments that may go above the
> field (perhaps it does also?).

The content() method is only available on ContentButton fields, which
allow arbitrary markup between the 'button' tags.

You can add markup to select options, labels, comments, anything,,, by
one of three methods.
Using one of the new *_xml() accessors.
By passing a reference to a string or variable.
Or using the new literal() subroutine.

$element->label_xml( '<b>contains markup</b>' );
$element->label( \'more <i>markup</i>' );
use HTML::FormFu::Util 'literal';
$element->label( literal( 'yet <b>more</b> markup' ) );

> About the select outgroups, it's a nice idea.
> Concerning the syntax :
> { group => [ [ 1 => 'one' ], [ 2 => 'two' ] ], label => 'opt1' },
> I don't see the point of the double level arrayref here. Why not just:
> { group => { 1 => 'one', 2 => 'two'}, label => 'opt1' },
> ? I think it would be more readable than this double arrayref. But perhaps it
> has got a good reason to be so which I do not know.

Hash keys aren't ordered, so if it were a hash-ref, the order of items
could change each time the program's run.
It would also unnecessarily restrict the items to each have a unique key.

Some argument forms might seem strange, but the reason is to support a
couple of new ways of building the form.
The first is by passing all arguments to a single constructor, instead
of chained methods:
$form->element( Text => 'foo', { label => 'Foo' } );
or even:
$form = HTML::FormFu->new({
  id => 'x',
  action => '/y',
  elements => [
    [ Text => 'foo', { label => 'Foo' } ],
    [ Text => 'bar', { label => 'Bar' } ],
    [ 'Submit' ],
  ],
});
The second is like:
$form->load_config_file( 'form.yml' );
Where form.yml is any format supported by Config::Any, and consists of
a data structure like that above.
Config files can also set a load_config_file() value, so that you can
easily set global defaults in a single file.

> For the Image element, an "alt()" would be useful to set an alternate text I

That's a good idea.

> think (by the way, is it possible to mix Image and Submit?)

I don't see any reason to limit someone from doing so.
The example page was just demonstrating all the elements, which was
why it had both.

> Concerning the HTML rendering, the radio buttons seems to miss a <label> that
> would allow to click on the text rather than on the button itself.

Ah, the labels seeem to be missing the 'for' attribute. I'll look into that.

> Apart of that, why do the ids always be different from names? Is there a
> reason for that?

By default, nothing is automatically given id's.
If you set a form id, then form fields are given an id of the form
$formid . "_" . $fieldname
I imagine there could be options for different types of auto-generated id's.

> Last comment for rendering, when you disable the CSS stylesheets, all the
> fields are lined one after another in a cabbalistic manner that make it
> nearly impossible to understand for a normally-constituted human. This may be
> an issue for disabled people or those using older browsers. I think it would
> be worth putting each field in a <p> or something like that.

Because it uses TT, each project will need it's own copy of FormFu's
template files available somewhere.
To make a change like that affect all elements, you just need to edit
the tag in the 'field' template file. You could also do the same to
wrap it in a list or table.

> Finally, I wonder if we will be able to access every element and its content
> individually, for example using [% result.element('t1').label %] or
> [% FOREACH radio in result.rg3; radio.field; END %] for example? That would be
> really useful for people who, like me, want to have a complete control on the
> output, far beyond what can be allowed by any widget module. ;-)

Yup, that kind of thing will work.

> Well, that makes quite a lot of comments, I hope they will be useful !

Thanks!
Carl