[Html-widget] v1.08 released

[Carl Franks]

On 14/08/06, Adam Sjøgren <asjo at koldfront.dk> wrote:
> On Mon, 14 Aug 2006 16:07:25 +0100, Carl wrote:
>
> > If for some reason someone creates a constraint like so:
> > $w->constraint( In => "foo" )->in( @values );
> > and @values is empty - the constraint will not mark "foo" as invalid,
> > regardless of the submitted value of "foo".
>
> > Now that you bring it up, I wonder why it was necessary. I'll look
> > through the mail archive and see what problem it was supposed to
> > solve.
>
> I think it originated in this email: <7pu084munn.fsf at sille.nzcorp.net>
> on the Catalyst mailinglist - in which I have an AllOrNone-constraint
> that includes a Select-element. I would like it to be valid to not
> choose anything in the drop-down and not fill out the rest of the
> elements in the AllOrNone-constraint.
>
> So either I need a way to not have/remove the In-constraint on the
> Select, or the In shouldn't mark empty as invalid - either way, or a
> third, is fine with me.

Hmm, ok. This fix doesn't even solve your original problem - as it's
not taking into account whether the key was submitted - only whether
$constraint->in() contains values.

I also recall sri saying he wanted the implicit In constraint on
Select elements to be scrapped - too much magic.
That at least would fix your problem - though it would break backwards
compatability for people relying on that constraint being silently
added...

I'm going to leave this until tomorrow, and hope sri's reading this
and makes a call.
I think the 2 choices are:
remove the implicit In constraint, but add an accessor to keep the
current behaviour,
or
add an accessor to override current behaviour by not adding the
constraint (which was Adam's original suggestion!).

Any opinions / other ideas?

Carl