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 <flame...@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-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
