1) There is command line handling and connection-oriented code in
HTMLParser. This code should be uncoupled. Perhaps an HTMLParserMain
class to handle the command line wrapper, keeping the HTMLParser code
dedicated to parsing?
Good suggestion. This refactoring should be done.
2) Thanks for filling in the toString methods in 1.2. I had noticed most
missing in 1.1 and was concerned. While there's room for minor
improvement (the use of StringBuffer to build strings and a consistent
naming conventions), these are minor quips. I've found it useful to have
a void toString(StringBuffer buffer); method variant in container
classes, for building up strings from contained classes more
efficiently.
We need to go thru a phase of optimization looking at the strings used. =
The toString(StringBuffer) method also sounds useful.=20
3) I love the existence of the toHTML(); methods.
This was the suggestion of Sam Joseph (it used to be toRawString() in =
older integration releases). Thanks Sam!
4) I see it's now possible to get something by calling getTag. This was
missing in 1.1. Thanks.
Hmm.. This method should actually read getTagName().=20
5) I noticed a lot of code in the HTMLTag class which is 'private
static'. This suggests the need for an external class to handle this
type of work. At peripheral glace, I'm presuming you're functioning as a
Finite State Machine (thus the 'automata' prefix)?
Ah yes, I have been thinking of doing this refactoring for a while, and =
also refactor the other finite state machines for strings and remarks.
Thanks for the big investment. I'd be happy to spend a little time
helping with some of the grunt work. If you think the use of the
Callback mechanism is good, for example, I could replace all the
System.out and System.err for you and send you the code.
You are most welcome to join us - as I mentioned, I'd be happy to add =
you as a developer.=20
6) I noticed that you don't have a custom exception class. I have code
kicking around that implements chained exceptions (as in Java 1.4) but
is compatible with earlier Java versions. Chained exceptions are
incredibly useful for wraping underlying exceptions into higher-level
exceptions while retaining the stack trace. This results in highly
usable libraries because it provides suitable high-level explanations of
a problem, while retaining lower level context.
Sounds like a great idea. Pls go ahead and add it to the CVS version.
7) I also have a very simple but versatile command line handler class
that you can use if you like. It lets you retrieve arguments as either
flags or parameter-followed options, single or multiple letter commands,
order-depentent, etc. While simple, this is one of those classes that
nobody should live without ;-).
It would be good to have this in the parser. Great to have you on board!
Cheers,
Somik
|
