commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <flame...@gmail.com>
Subject Re: [LANG] Request for opinions
Date Wed, 17 Jun 2009 03:05:53 GMT
Very useful, and very similar to my intent. (And thanks for the reply :) ).

Currently I have a parent class, but that's because originally this
was an extension of FilterWriter. I suspect I'll go interface. I don't
have escape and unescape separately because I claim they're the same
concept, and they're not symmetric. Two separate escape algorithms are
likely to use the same unescape. Also I'm definitely aiming to have
the enum style approach, both for the top level 'XML' bit and for the
underlying rules 'BASE_XML', 'APOSTROPHES', 'HIGH_UNICODE' so that
people can build their own.

I hadn't thought about using actual enums - I'll give that a shot and
see how it feels :)

Thanks - both for the ideas and affirming the direction I'm going,

Hen

On Mon, Jun 15, 2009 at 6:42 AM, Michael Wooten<mwooten.dev@gmail.com> wrote:
> I'm just some random user, but I have no opposition to including a framework
> in Lang. For projects that I have worked on, I found a very useful pattern
> for frameworks like this that have a fairly fixed set of operations.
>
> I usually like to define an interface, which in this case could be something
> like StringEscape. There seem to be a fixed set of escape and unescape
> operations for each document type.
>
> i.e.
>
> interface StringEscape
> {
>    public String escape(String string);
>
>    public void escape(Writer writer, String string) throws IOException;
>
>    public String unescape(String string);
>
>    public void unescape(Writer writer, String string) throws IOException;
> }
>
> Since there are a fixed set of escapes that are supported, I usually like to
> create an enumeration for the known ones.
>
> public enum StringEscapes implements StringEscape {
>
>    CSV {
>        public String escape(String string) {
>            // CSV escape code here
>        }
>
>        public String unescape(String string) {
>            // CSV unescape code here
>        }
>    },
>
>    HTML_3_2 { ... },
>
>    ...
>
>    XML_1_1 { ...};
>
>    // Common code for all escapes
>
>    public void escape(Writer writer, String string) throws IOException {
>        writer.write(escape(string));
>    }
>
>    public void unescape(Writer writer, String string) throws IOException {
>        writer.write(unescape(string));
>    }
> }
>
> I've found multiple benefits to this approach. One, the enumeration provides
> one place where all of the known and most used implementations can be found.
> The enumeration can also share code that is common across all of the
> implementations (such as the Writer cases). The enumeration values can be
> used directly by calling "StringEscapes.CSV.escape(myCsvString);". Also,
> because the enumeration's behavior is defined in an interface, users are not
> restricted to just the enumeration values, and can create their own.
>
> While not necessarily needed, the StringEscapeUtils class could be modifed
> to only have static methods that represent the four common interface
> methods, but instead take a StringEscape as an additional parameter:
>
> class StringEscapeUtils {
>    public static String escape(StringEscape escape, String string) {
>        return escape.escape(string)
>    }
>
>    public static String unescape(StringEscape escape, String string) {
> return escape.unescape(string)
>    }
>
>    public static void escape(StringEscape escape, Writer writer, String
> string) {
>        escape.escape(writer, string);
>    }
>
>     public static void unescape(StringEscape escape, Writer writer, String
> string) {
>        escape.unescape(writer, string);
>    }
> }
>
> The would lead to client statements that looked like this, which might be
> useful just for clarity:
>
> StringEscapeUtils.escape(StringEscapes.CSV, myCsvString);
>
> But would also allow for custom implementations:
>
> StringEscape myStringEscape = new StringEscape() {
>    // Custom implementation code here
> };
> StringEscapeUtils.escape(myStringEscape, myString);
>
> Just ideas. It's a framework I've found useful when passing behavior around,
> especially when there's a fixed set of operations or a known subset to be
> supported.
>
> Hope that's useful.
>
> -Michael Wooten
>
> On 6/14/09, Henri Yandell <flamefew@gmail.com> wrote:
>>
>> 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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>

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


Mime
View raw message