[Htmlparser-developer] registerScanners going bye bye

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Two questions for users and developers...

As part of the refactoring going on, the scanners are being obviated.
This means that except for the TagScanner, CompositeTagScanner and 
ScriptScanner, the scanners package will be empty.
Instead of registering scanners, programmers will register tags.
These will be cloned as needed to be returned as parsed nodes.

I'm in a position now to remove the registerScanners() method, and I'm 
wondering if the state of a new Parser shouldn't be preloaded with tags 
it recognizes.
This is directly opposite to the current implementation where one needs 
to do a two phase setup:

    parser = new Parser ();
    parser.registerScanners ();

I've looked at all the code I have available, and in every case (except 
for unit test cases) the new Parser call is immediately followed by 
registerScanners.

Question: Should a new parser be already configured and ready to rock 
with tags registered?

Of course there will be ways to get the original behaviour.
After much discussion with Joshua, I've broken out the NodeFactory as a 
class, so currently this might look like (my unsubmitted codebase):

    parser.setNodeFactory (new PrototypicalNodeFactory (true));

where the boolean indicates the node factory should be constructed empty.
Of course, you can add (or remove) whatever specific tags (even your own 
custom ones) you want to receive:

    PrototypicalNodeFactory factory = new PrototypicalNodeFactory (true);
    factory.registerTag (new LinkTag ());
    factory.registerTag (new ImageTag ());
    parser.setNodeFactory (factory);

which could also be written:
    parser.setNodeFactory (new PrototypicalNodeFactory (new Tag[] {new 
LinkTag (), new ImageTag ()}));

An empty node factory generates undifferentiated tag, string and remark 
nodes, just like the Lexer.
Then - I need to know how far I should go.

Question: Should the node factory, and hence the Parser, have *all* the 
possible tags it knows about registered by default?

This would be the equivalent of the current registerDomScanners() method 
call, which adds <HTML>, <HEAD> and <BODY> recognition.
This may be slightly more problematical, since I can find very few 
(none?) instances of it's use.
Realistically, if your program isn't handling recursing into node 
children now, you are probably doing it wrong, and adding one more level 
to the node tree won't cause a problem.
My preference is to load it up completely, as it makes for a cleaner 
design, but if somebody can provide a compelling reason not to, I'll listen.

In the absence of responses, I will take the answers as an emphatical 
Yes and Yes.

Derrick