Modularity of DOM/JS parts

[David Faure]

On Sunday 18 March 2007, Paul Giannaros wrote:
> Hi,
> 
> I've been working on a project to facilitate web navigation/scraping using 
> a "real" browsing engine to handle (X)HTML/JavaScript/cookies. I began using 
> KHTMLPart with Xvfb (so that it works on X-less servers -- a requirement), 
> but that solution is proving to be increasingly finicky and unextensible. A 
> major problem is how closely it's tied to the graphical side: there are 
> constantly message boxes asking about cookies, remembering passwords, kwallet 
> asking things, etc.
> Since then I've been looking at different engines to get this to work 
> the 'proper' way -- by seperating out the DOM/JS stuff from the graphical 
> side -- and KHTML looks like the nicest.
> 
> How tied are the graphical and non graphical bits of KHTML? I'd need to use 
> the HTML parsing and DOM stuff, tie it with KJS, and probably handle cookies 
> myself. The (eventual) goal would be to make it work with QCoreApplication.

All the things you mention are in fact handled by separate programs:
kcookiejar for the cookies, kpasswdserver for http passwords, and kwallet
for form contents (and kpasswdserver also uses kwallet).
So it should be quite easy to replace the calls to those things, or the implementation
of those things, to avoid the GUI interaction.
The form saving is probably the only one that has the messagebox inside khtml's
code - but you can hack it out easily.

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