I've rewritten StringEscapeUtils by putting a mini-framework underneath it:

https://issues.apache.org/jira/browse/LANG-505

On the one hand, Lang has not been a place for frameworks. On the
other hand, StringEscapeUtils has repeatedly shown a need to be much
more pluggable and not tie the user into a particular way of working.
We have bugs that are really different requirements.

In essence the design is very similar to Entities, but taken a step
further. This will also resolve the "Make Entities public" ticket/todo
if that's still open. Other tickets can then be resolved by letting
the users cheaply implement their own utility method on top of our
code, or adding an alternative to Lang.

StringEscapeUtils itself will probably get an API change anyway -
escapeSql needs deleting imo. It needs escapeHtml32, 40, 50 variants,
and escapeXml10, 11 variants. Or people need to be encouraged to call
something like   StringEscapeUtils.escape(Entities.XML_1_1_ESCAPE) and
maybe the various escapeHtml type methods go away.

Anyway... any opinions very much appreciated. Otherwise I'll keep
hacking on things :)

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to