On Sun, 30 Mar 2003, Alex Chaffee / Purple Technology wrote:
> There are a few nitpicky issues I'd like some consensus on: > > * StringEscapeUtils is a bit much to type for a quick static API call > -- should we rename it EscapeUtils? It's not like there will be any > other type of Escape... I'm fine with either name. > * Java strings can handle raw single-quotes inside strings, but I > don't think JavaScript can (or at least it's dangerous since a > JS string may very well have ' as a string delimiter). So on the > principle that you should escape only what you have to -- why add an > unnecessary backslash? -- I made escapeJava pass single quotes > through. (Unescape still turns \' into ', of course.) This is a > change from the existing StringUtils.escape. +1. > * escapeJava now uses lowercase letters for hex codes. Are there any > feelings about switching to capital letters? I prefer caps (like > \uCAFE instead of \ucafe) but I could go either way. Ditto, I'm not bothered. > * I made use of (and thus contributed) my StringPrintWriter class. Do > you think it's useful enough to make it part of the public API (and > add tests and docs for it)? I think we should keep it private for this release at least. Technically it should go in the slowly moving Commons-IO project. > Todo: > > * The HTML escaper builds a static hash table mapping entities to > ints; I still need to make it initialize this lazily so casual users > don't pay an up-front penalty (however slight) for linking to the > library. > > * XML escape, SQL escape. They're both easy, at least in the first > pass. But does anyone know how to escape high-bit and control > chars in SQL? (I know that JDBC has its own curly-brace escapes; > that's out of scope for this function.) > > * make StringUtils.escape call StringEscapeUtils.escapeJava &c. instead > of reimplementing. I'm happy to leave this one be for a while until > people are comfortable with the StringEscapeUtils. > > * add a Writer-based version for HTML escape and unescape > > * I think it'll be ready to roll for 2.0, but if we decide to > postpone, I'll have to change the build.xml to exclude it from the > jar. I'm -1 for it going into 2.0 just on the general principle of trying to keep the release target focused and not letting it slip with additions. If it should be finished and ready though... I''d happily release it. As for excluding it, I tend to just remove all undesired packages/classes before doing a build, then put up an RC release so people can pick over the legitimacy. Also a maven generated site. If that succeeds, I cvs tag the files, push the release and we go back to the easier situation of throwing in new ideas [to be thrown out later :) ]. Hen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
