I'm about to head into a meeting so I'll have to be brief for now.
One of my assumptions all along is that javascript would not be the only
possible scripting language. IE supports vbscript and possibly other
languages and at some point HtmlUnit may want to support those as well.
This is one of the reasons for keeping all the javascript objects as a
completely seperate class hierarchy. The other reason (which may not
make sense anymore) is that I didn't want a dependancy on the rhino
engine. I wanted HtmlUnit to continue to work if js.jar wasn't in the
classpath. If the HtmlElement hierarchy and the javascript hierarchy
were intertwined then this wouldn't be possible.
Another assumuption I've been working with is that all data about the
document is stored in the xml dom model. The HtmlElement hierarchy does
not store any data itself (except in the rare case of faking out values)
so that it is possible to directly modify the xml dom and not have to
worry about the two trees being out of sync.
I hope this helps you understand why things have ended up the way they
are right now. I'm not particularly tied to the current implementation
so if there's a better way then I'm all for it :-)
Back later....
--
Mike Bowler
Principal, Gargoyle Software Inc.
Voice: (416) 822-0973 | Email : mb...@Ga...
Fax : (416) 822-0975 | Website: http://www.GargoyleSoftware.com
|
