Re: XHTML Form Tag
--- Craig McClanahan [EMAIL PROTECTED] wrote: snip 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. The function names changed as a result of a bug report (duplicate names I think). David Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XHTML Form Tag
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]
Re: XHTML Form Tag
First off, you don't sound irked, but it sounds as though you're well within
your right to be!
remainder in-line ...
- Original Message -
From: Craig McClanahan [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Sent: Sunday, October 24, 2004 10:36 PM
Subject: Re: XHTML Form Tag
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/).
I missed that one. Eh ... ok.
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.
I'll pass on that one too. That's likely to break more than it fixes.
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).
Aye - I see that now. Doesn't it seem rude to force folks into something
like that? Perhaps we should come up with a way to facilitate rendering
either ... hrm ... maybe we could leverage XSLT here? Nah, there's likely a
better approach. Perhaps we could somehow factor-out the
form.getAttributeNode('name') to something that is smart enough to return
the right thing -- or generate that on the fly by tossing in a function that
returns the appropriate node depending on the specification.
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.
Well, you've peaked my attention. You're saying this because you expect
faces to replace them entirely?
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.
I agree. I was thinking perhaps it might be easy to do the right thing.
Obviously I missed some things :-O which is why having you guys out there
watching my back is so darned handy ;-)
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
