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 strategy is going to be necessary to provide it (since we can't just add an arbitrary attribute without violating the DTD).
That's what I was trying to avoid. Exactamundo. I'll have to study this some more. I still think it's plausible there might be a "simple" solution. I'm not much of one to jump through hoops if I can walk through an arch instead. Arches seem to be more difficult to find at times though.
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.
... and you want to avoid having that "opportunity" again - hence why you care that this happens so carefully. I understand.
I'm brain-storming :-) I was hopeful I'd get someone to pipe-up and I'm thankful you did. I'll strategize some more and see if I can come up with something more appealing. I'm open to any and all suggestions! In the end, any changes made to validator would have to go through one of you guys that actually have write-access to that repository anyway, so I'd love to have you folks involved in steering this.
Eddie
Craig
--- avast! Antivirus: Outbound message clean. Virus Database (VPS): 0443-3, 10/22/2004 Tested on: 10/24/2004 11:48:55 PM avast! - copyright (c) 2000-2004 ALWIL Software. http://www.avast.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
