[Html-widget] Offer of help / question about H::W status

Bogdan Lucaciu bogdan at wiz.ro
Fri Aug 4 15:02:38 CEST 2006

On Fri, 2006-08-04 at 12:08 +0100, Carl Franks wrote:
> On 02/08/06, Bogdan Lucaciu <bogdan at wiz.ro> wrote:
> >
> > I might go a bit off-thread with this, but I noted some problems that
> > might need fixing (and were not already discussed on the list):
> >
> > 1. You can't control the 'comment' by using a custom Container, unless
> > you start modifying the label element (find the comment, remove it, move
> > it somewhere else) . The comment's position is hardcoded in mk_label.
> > This is useful , because I might need:
> >  Phone number: [ input ] (don't forget the area code)
> > CSS positioning might not be enough for most cases.
> Maybe move the comment code out of mk_label() and into a new
> mk_comment() that could be overridden?
>From Container.pm: 
  if ($self->label) {
                my $l = $self->label->clone;
                # Do we prepend or append input to label?
                $e = ($class eq 'checkbox' or $class eq 'radio') ?
$l->unshift_content($e) : $l->push_content($e);

The comment is already embedded in the label, they should be separated
(in order to allow the container to arrange them).

Your suggestion does just that, and I should get an accessor for the
comment html (created with mk_comment).

> > 2. I should be able to simply add a 'required' marker on elements with
> > 'All' constraint, that does not interfere with the comment (like a red
> > asterisk)
> I don't think that's the way to do it - as the All constraint might be
> applied to Hidden elements.
> How about subclassing the base class H::W::Element to add a new
> accessor, and do what you will with it during as_xml() ?
That is a good ideea.

> > 3. I should be able to put a callback constraints that run the
> > constraint _once_ with all the elements as parameters. Now the callback
> > is ran multiple times,  for every element.
> I don't think this is correct.
> The process() method in HTML/Widget.pm loops over the constraints, and
> for each one, calls $constraint->process( $widget, \%params, $uploads
> )
Yes, and $constraint->process runs $self->validate for each param. That
means the callback is ran multiple times.

> > 4. Grouping constraints (like Any or Equal) should not cause the error
> > message to be displayed on every element, it's quite ugly. I'm not sure
> > what the solution is, maybe only the first element in the group should
> > show the error.
> The simplest way I can think of doing this, would be to use css to
> ensure that a particular name/constraint ID is never displayed.
> It sounds reasonable to want the xml output like this though.
> The extra elements would still be invalid, even though they wouldn't
> display the errors.
> I think I would prefer the constraints Any/All to have an accessor by
> which you could state which element name you want to display the
> error.
> The renderer could then call can() to see if the constraint supports
> it, and then only if the element name matches, display the error.
> This would provide the advantages of being both backwards-compatable,
> and also providing more control than simply adding the error to the
> first element found.
sound cool.

> > 5. process should be able to track by itself  if the form was submitted
> > (by using a hidden field for example). If I supply the request object it
> > fires the constraint code even if the form was not submitted.
> > Now I have to do the check myself:
> > if ($c->req->params->{submitted}) {
> >         $w->process($c->req);
> > } else {
> >         $w->process;
> > }
> If you set $w->indicator, then Catalyst::Plugin::HTML::Widget will
> figure out itself that the form's been submitted.
> If you don't use Catalyst, then you could create a helper for your
> choice of framework, which mimics C::P::H::W's behaviour.
My bad :) Of course, C::P::H::W's reference should describe this

Thanks! I'll be away for a couple of days, but we'll talk on IRC about
my patches when I get back ;)

Bogdan Lucaciu <bogdan at wiz.ro>

More information about the Html-widget mailing list