commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [lang] Entity Escaping (HTML/XML)
Date Wed, 09 Apr 2003 22:54:26 GMT
I would be averse to HTML subclasses, as it is not very '[lang]'. lang uses
util classes with explicit names, as Alex suggested. [lang] is pretty much
not OO. So I actually like the method names from Alex (and they are going in
StringEscapeUtils aren't they....)
Stephen

----- Original Message -----
From: "Gary Gregory" <ggregory@seagullsw.com>
To: "'Jakarta Commons Developers List'" <commons-dev@jakarta.apache.org>
Sent: Wednesday, April 09, 2003 11:31 PM
Subject: RE: [lang] Entity Escaping (HTML/XML)


> I would prefer to see HTML code in an HTML class (HTMLUtils?), with
> subclasses for both HTML versions. HTML is clearly semantically different
> than simple Strings and StringUtils is already a 2000+ lines giant; these
> are new methods, so there is no back/w compatibility issues. IMHO, small
> classes with small methods seem to be a better philosophy in this
particular
> case.
>
> Having methods with version numbers does not seem very OO.
>
> Furthermore, if I wanted to migrate an app from "no version" HTML to 3.2
and
> then to 4.0, I would have to change call sites all over my app. With an
HTML
> set of classes, I would just change one line of code with the class name
or
> perhaps put the class name in a properties file for even easier
> configuration.
>
> Gary G.
>
> -----Original Message-----
> From: Alex Chaffee / Purple Technology [mailto:guru@stinky.com]
> Sent: Wednesday, April 09, 2003 2:48 PM
> To: Jakarta Commons Developers List
> Subject: [lang] Entity Escaping (HTML/XML)
>
> Now escapeHtml, escapeXml, and their unescape versions are checked in.
> Anyone who thinks they may use them, please doublecheck my code,
> tests, and conversion from the DTDs.
>
> Some further thoughts...
>
> These methods use the built-in named entities (like "&amp;" and
> "&eacute;") from the most current version of HTML (which is now 4.01)
> and XML (1.0).
>
> While most users will want to use the most current set of named
> entities, some will need to target a specific browser.  For them, the
> current version may have too many entities -- their target browser may
> not understand what "&Scaron;" means and they would prefer the escaper
> use "&#352;" instead.
>
> Is it worth worrying about this case?
>
> If we decide to provide a solution for this, we could use:
>
> String escapeHtml(String)
> String escapeHtml40(String)
> String escapeHtml32(String)
>
> However, that doesn't scale as well as the following:
>
> String escapeHtml(String)   -- always use the most current HTML
> String escapeEntities(String) -- use numeric escapes only
> String escapeEntities(String, Entities.HTML40) -- use HTML 4.0
> String escapeEntities(String, Entities.HTML32) -- use HTML 3.2
>
> ...and so on for other (as yet unknown) sets inside Entities.
>
> escapeEntities and Entities.HTMLXX are already in existence as private
> members.  To expose them would be straightforward.
>
> And if we made the Entities class public, then they could roll their
> own set.  This would be the most flexible but perhaps overly
> complicated.
>
> No urgency here, but I wanted to get my thoughts on record.
>
> Cheers -
>
>  - Alex
>
> --
> Alex Chaffee                               mailto:alex@jguru.com
> Purple Technology - Code and Consulting    http://www.purpletech.com/
> jGuru - Java News and FAQs                 http://www.jguru.com/alex/
> Gamelan - the Original Java site           http://www.gamelan.com/
> Stinky - Art and Angst                     http://www.stinky.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>


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


Mime
View raw message