On Tue, Oct 5, 2010 at 7:27 PM, Christopher Schultz <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > All, > > Wow, nothing? :( > > Usually Niall will at least tell me that nobody cares :)
Nobody cares :) Niall > - -chris > > On 10/1/2010 11:29 AM, Christopher Schultz wrote: >> All, >> >> Any suggestions? I've even considered using a multi-valued "msg" using a >> comma as a separator for the two. Something like this: >> >> msg="errors.xhtml.syntax, errors.xhtml.no-end-tag" >> >> Does anyone have any better ideas? >> >> Thanks, >> -chris >> >> On 9/29/2010 2:09 PM, Christopher Schultz wrote: >>> All, >> >>> I've been happily using commons-validator 1.3.1 with Struts 1.3 for some >>> years, now, and I've recently developed my own custom validator that >>> checks for XHTML syntactic validity. Technically, it checks for XHTML >>> validity only when the input looks like this: "<html>....</html>": >>> everything else validates successfully with no actual XHTML syntax check. >> >>> Recently, it became clear that users were sometimes forgetting the >>> "</html>" at the end of the input. This caused two problems: first, the >>> input wasn't being validated as XHTML, and second, when the data was >>> then displayed in a web page, it was escaped instead of being rendered >>> as actual HTML. >> >>> My first instinct was to add a "mask" validator that checked for an >>> appropriate pattern (that is, "<html>" up front with no trailing >>> "</html>"). I implemented that and it works quite well. Then, it >>> occurred to me that I might want some other pattern for some reason for >>> those fields, and that the correct place for that check ought to be in >>> the XHTML validator itself. >> >>> So I started moving the check described above into my custom validator. >>> Everything was fine until I had to render the error message. Since I'm >>> doing essentially two checks (one for <html> and matching </html>, and a >>> second for actually checking the XHTML syntax), I need two distinct >>> error messages. The configuration for a validator only allows one single >>> "msg" attribute as shown in my configuration below: >> >>> <validator name="possibleXhtml" >>> classname="....PossibleXhtmlValidator" >>> method="validatePossibleXhtml" >>> methodParams="java.lang.Object, >>> org.apache.commons.validator.ValidatorAction, >>> org.apache.commons.validator.Field, >>> org.apache.struts.action.ActionMessages, >>> org.apache.commons.validator.Validator, >>> javax.servlet.http.HttpServletRequest" >>> depends="" >>> msg="errors.xhtml" /> >> >>> I could simply hard-code the error message key into the validator, but >>> that seems less maintainable than I'd like it to be. Is it possible to >>> provide more than one error message key to a validator like this? >> >>> Other options for me include creating a custom validator that does >>> nothing but check for the <html>...</html> that won't interfere with, >>> say, the "mask" validator. >> >>> It still seems to me that my goal ought to be a single validator that is >>> basically self-contained, rather than having two validators that >>> essentially /must/ be used together. >> >>> Does anyone have any suggestions? >> >>> Thanks, >>> -chris >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > - --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkyrbg0ACgkQ9CaO5/Lv0PD73QCeKJ1yMStcSXf2zmjxZI7Vf2Ju > NRwAoL9KqTrjllCW1jJhlLeoohCfxNLg > =YBSz > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
