Re: [Htmlparser-developer] RE: question about using HTMLParser in Apache JMeter

[Derrick O. <Der...@Ro...>]

Joshua,

Yes.  In the transition from using a straight Lexer to get basic nodes 
(lexer.nodes package), to using the Parser to get nodes that can be 
visited (htmlparser package), the Lexer needs to generate nodes it was 
not compiled with.  Hence the Parser replaces the Lexer as the 
NodeFactory that the Lexer calls when it needs to create a Node.

I'm thinking this concept should be augmented in the Parser's 
createTagNode to look up the name of the node (from the attribute list 
provided), and create specific types of tags (FormTag, TableTag etc.) by 
cloning empty tags from a Hashtable of possible tag types (possibly 
called mBlastocyst in reference to undifferentiated stem cells).
This would provide a concrete implementation of createTag in 
CompositeTagScanner, removing a lot of near duplicate code from the 
scanners, and allow end users to plug in their own tags via a call like
   setTagFor ("BODY", new myBodyTag())
on the Parser. Details on interaction with the scanners have to be 
worked out, but it seems the end user wouldn't have to replace the 
scanner to get their own tags out.

Derrick

Joshua Kerievsky wrote:

> Derrick Oswald wrote:
>
>> The StringNodeFactory you added is currently sidelined by the more 
>> generic NodeFactory. It would be easy to add it back in.
>> Derrick
>
>
> I deliberately added StringNodeFactory to the parser, not a generic 
> NodeFactory, because I had no need for a generic NodeFactory.  Have 
> you found a need for a generic NodeFactory?   --jk
>