On Sun, 24 Oct 2004 21:57:20 -0500, Eddie Bush <[EMAIL PROTECTED]> wrote:
> Hola Amigos!
>
> AFAICT this is an issue only in the html:form tag. If we were to introduce
> something to trigger XHTML 1.1, couldn't we just "lie" to validator about the "name"
> by telling it the ID instead of the name? Would the resulting syntax emitted by
> validator still be ok?
If you look at the static Javascript methods produced by Commons
Validator, you'll note the following code in each of the validation
methods (using just one of them for an example):
function validateFloatRange(form) {
...
var formName = form.getAttributeNode("name");
...
}
In other words, the validators all assume that they can acquire the
name of the form (which is then used to look up the appropriate
validation rules) based on the "name" attribute of the form element
that is passed in as an argument. This value is used to dynamically
calculate the name of a dynamic JavaScript function that implements
the specific tests for this particular form (which is part of the code
generated when you say <html:javascript dynamic="true"/>).
Without a change to the validator code itself, then, the only way to
"lie" to it would be to have some sort of JavaScript that dynamically
added the expected form name as the "name" attribute of the form
element at runtime, perhaps in an "onload" handler on the <body>
element. That would be such an egregious hack that I would not
support it.
If we want the validator to work with XHTML 1 1, instead of XHTML 1.0
Transitional, we've got a bit of work to do. I suspect there is more
to it than just the "name" attribute on a <form> element (although
IMHO the XHTML spec did the world no favors when they dumped "name" on
the form element but kept it on the input elements -- that's just
grounds for confusion).
>
> Perhaps we should force XHTML 1.1 if <html:html xhtml="true" ...> or <html:xhtml/>?
> That seems kind of pushy to me though. Maybe in 2.0. For now, perhaps enable some
> sort of flag (<html:xhtml version="1.1"/>) to allow XHTML 1.1? We could poke it in
> pre-deprecated with note that it's going away in 2.0.
As far as I'm concerned, the HTML tags as a whole aren't going to be
part of 2.0 -- there are substantially better options (my proposal on
that topic is coming very soon). But that die has yet to be cast by
the consensus of the developers.
In the mean time, we should explore a solution to this on the 1.x path
that does the right thing, instead of a hack. I think it's reasonable
to aim for XHTML/1.1 (or XHTML/1.0 Strict) output being a viable
option.
>
> Anyhoo ... the Form tag could then check to see if it should emit XHTML (which it
> already does) and which version. If it's being asked to be 1.1 compliant, it could
> "lie" and render 'name="name"' as 'id="name"'.
>
That's the *easy* part of the problem :-). But yes, one could
certainly make the form tag smarter about what it emits based on which
version of XHTML you want.
> What do you all think? I'm listening ...
>
> If the validator would require a change, I think I might be up for fixing that as
> well. It's pretty well written, so I don't see modification being too large an
> issue. Yes, I'm aware it probably needs to stay backward-compatible, but I think I
> might can strategize a way to accomplish that. I'd love to hear potential hurdles
> you all see to accomplishing that though!
>
I think there'd be a different way to do this, but it's likely to
require a fair bit of surgery. In particular, I do not believe it's
reasonable to require the rendered "id" attribute of a <form> element
to contain Struts's notion of a form name -- yet it seems that a lot
of code does depend on being able to use this value to look up the
correct set of validation rules. If it is necessary to communicate
that to the client side, a new strategy is going to be necessary to
provide it (since we can't just add an arbitrary attribute without
violating the DTD).
If I sound a little irked about this, it's because I am ... it turns
out that the generted JavaScript function names for Commons Validator
1.1.3 (included with Struts 1.2.x) are different than the generated
names in the version of Validator that was included in Struts 1.1, and
it cost me more hours than I want to admit to figure out how to make
Struts-Faces support client side validation with both versions.
> Eddie
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
