Removal of KJS::getString()

David Faure faure at kde.org
Fri Oct 15 19:09:51 CEST 2004


On Friday 15 October 2004 14:19, Harri Porten wrote:
> David's stance was that only tests for each property would guarantee a
> safe conversion. But who's going to write those? ;(

The DOMTS testsuite has a test for every attribute listed in the DOM spec - hopefully.
That's the idea at least, and it's indeed the series of tests that spotted most of the
empty vs null problems.

Hmm, I just spotted that e.g. document.preferredStylesheetSet isn't tested.
And that DocumentType::publicId is only tested in DOMTS level1xml and level2xml, which
we don't run yet (JSUnit problems).

> David, I remember you had a distinction for cases where getString() would
> still have to be used?

The cases we found up to now:
* namespaceURI, prefix, localName, nodeValue (kjs_dom.cpp)
* DocumentType::internalSubset (kjs_dom.cpp)
Those need getString, i.e. they can return Null.

It seems to me that anything that is related to an HTML attribute (things like
body.bgColor, form.name, input.accessKey etc. etc.) can be empty (but not null),
so they should simply use String. So kjs_html.cpp is probably allright now, with String
everywhere.

It's the other files that need to be double-checked, mostly kjs_window, kjs_navigator, 
kjs_events which indeed sounds like a long and tedious job.
(maybe kjs_css too, but it looks a bit like the case of html attributes)...

Best way forward would be to run a code coverage tool, to see what our regression
test suite tests and what it doesn't test...

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).


More information about the Khtml-devel mailing list