htmlparser-developer

[Htmlparser-developer] FormScanner

[<dha...@or...>]

Hi,
=A0
I was checking out the code of form scanner and I saw that it contained
a list of all the INPUT tags and all the TEXTAREA tags. In addition we
need to add the list of SELECT tags also out here..
=A0
The SelectTag class has a List of OptionTags underneath it. However the
FormTag has a NodeList of InputTags and TextArea tags. I think these 2
should be synchronized for consistency.
=A0
Also no attributes not specified in the tag originally should be
displayed as a result of the toHtml() call.
=A0
For example, the following is happening:
<FORM></FORM>
=A0
is reproduced as=20
=A0
<FORM ACTION=3D""></FORM>
=A0
It should be correctly reproduced as <FORM></FORM>
=A0
Also I was wondering if it would be possible to store attributes in
Hastable in the case in which they are present on the page and hence
reproduce them similarly. This will minimise the difference between an
input HTML and a parsed output HTML. Only during comparisons or get
operations we can=A0synchronize the keys to either upper/lower case for
comparison.
=A0
I would be happy to take up any activity once we decide on its
feasibility.
=A0
Regards,
Dhaval
=A0

Re: [Htmlparser-developer] FormScanner (for Kaarle Kaila)

[Somik R. <so...@ya...>]

Hi Dhaval,

I was checking out the code of form scanner and I saw that it contained
a list of all the INPUT tags and all the TEXTAREA tags. In addition we
need to add the list of SELECT tags also out here..

Thanks for catching this. Done.

The SelectTag class has a List of OptionTags underneath it. However the
FormTag has a NodeList of InputTags and TextArea tags. I think these 2
should be synchronized for consistency.

Can you explain more ? FormTag does have the standard children's list, =
in addition to which, it has the input tags and textareas. There is =
redundancy, but its there to provide helpful searches.

Also no attributes not specified in the tag originally should be
displayed as a result of the toHtml() call.

For example, the following is happening:
<FORM></FORM>

is reproduced as=20

<FORM ACTION=3D""></FORM>

It should be correctly reproduced as <FORM></FORM>

If this is so, it is definitely wrong. Can you write a testcase for this =
? I am a bit surprised, bcos FormTag does not even have a toHtml() - it =
uses CompositeTag's toHtml().

Also I was wondering if it would be possible to store attributes in
Hastable in the case in which they are present on the page and hence
reproduce them similarly. This will minimise the difference between an
input HTML and a parsed output HTML. Only during comparisons or get
operations we can synchronize the keys to either upper/lower case for
comparison.

Hmm... that is not a bad idea. Though, we have to ask Kaarle -- he =
handles the AttributeParser.

Regards,
Somik