This is a follow to my offer to contribute some code to the ECS project. The
following notes apply to code changes on my hard drive, which can be use to
patch changes if they make sense to you. I had a chance to work on this for
a few hours over the weekend.
1) I developed a WebColor class which converts HtmlColor constants to Color
instances and supports the convertColor method to insure a safe translation
of Color objects into #-prefixed HTML color strings. I noted that the
getColor method in HtmlColor is never used, so I left it out of the WebColor
class.
2) I edited BaseFont, Font, TD, Table, Body, TH, TR to add new methods and
constructors that support the use of Color in setColor and setBgColor. None
of the existing methods or contructor variants that use HtmlColor were
removed. In theory they should probably be marked as deprecated.
3) I removed all but the 'process' method in the Filter interface. This may
be controversial but my observation was that this is the only method used in
any of the other ECS classes. Interfaces should be (as Einstein once said)
as simple as possible, but no simpler. They represent a minimal contract
between the classes that play a role and those that use them. By implication
all the other methods have to be supported but they have to do with the
implementation choice rather than the usage, so I'm assuming that simpler is
better.
4) This distillation down to the process method in a Filter made is easy to
implement two key classes, built on the Match interface (and implementations
from an article I mentioned when I first contacted the group). I placed
these classes in the package org.apache.ecs.filter.match. The concrete
implementations include RegularExpression, Wildcard, Soundex and Alike.
5) The first Filter implementation I wrote is called MatchFilter. It expects
an instance of the Match interface, a string defining token delimiters for
the StringTokenizer used within, and an Object which will replace the
maching token using its toString method. Matching everything is easy if you
define no delimiters (meaning that the string as a whole matches or not - if
delimiters are used, the individual tokens are tested and replaced when
matched). Since the user has control of the token delimiters, they can do
pretty much anything they want this way, providing maximum flexibility and
power for the user, without undue complexity.
6) The other Filter implementation is called MultiFilter and supports the
Filter interface and the inclusion of an arbitrary set of Filter instances.
Each will be tested when the process method executes in the order in which
they were added (using an addFilter method). A removeFilter method is also
provided. Note that this implementation adheres to the model I think you
were after but uncouples the ability to support multiple filters together
from the filter interface. I think you'll find this approach more flexible
and easier to use.
I made the assumption that you were shooting for maximum compatibility.
Though I typically use ArrayList instead of Vector and HashMap instead of
the Hashtable class in most of the current programs I write, I used Vector
in the MultiFilter implementation for this reason. If you are only concerned
with Java 1.2-compatibility and don't care about Java 1.1, the Collection
classes are usually faster (unsynchronized).
Of course, I haven't sent the code yet. I'd like to hear comments on these
changes first and I need to test the functionality, which I haven't done
thoroughly enough to make the code ready for check-in yet. Not having
contributed to an open source project before, I'd like to know that any
suggested improvements are in keeping with the overall vision of the
contributing team. I look forward to hearing from everyone. Sorry if I'm a
little too verbose.
--
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
