Modularity of DOM/JS parts

[Yan Seiner]

Paul Giannaros wrote:
> On Tuesday 20 March 2007 12:53, Yan Seiner wrote:
>   
>> Hi Paul:
>>
>> I'm not sure what your ultimate goal is, but I am intrigued.
>>
>> I have an embedded panel that uses konqueror embedded as its user
>> interface.  We've done a lot of tuning, but still, konq+qt is a pretty
>> heavy weight app for a 200 MHz CPU and 32 MB RAM.
>>
>> We don't need most of konq.  We don't need generic web browsing.  What I
>> need is a simple browser that can handle javascript, display tables, and
>> GET and PUT forms.  Qt gives us some benefit since we can support i18n
>> fairly easily.
>>
>> Is this something similar to what you're working on?  Or is your goal to
>> produce a wget on steroids?
>>     
>
> No, unfortunately not the same kind of thing. The end result of this will 
> (hopefully!) be something that can be run on servers without a display -- it 
> doesn't matter what the page looks like, as long as tag soup can be parsed 
> into a meaningful DOM and traversed. It will make web scraping (something 
> that happens in businesses more than I imagined) much easier. 
> If you only need to render simple markup like tables, however, surely it would 
> make sense to either build off something like QTextDocument and use Qt for 
> HTTP transfers and then plug that with a javascript engine like KJS or 
> SpiderMonkey yourself? I suppose if you need form submissions you need a 
> browser that can handle forms :P, but that doesn't seem like an impossible 
> task.
>   
Alas, I am neither a C++ programmer nor a Qt expert....  So the learning 
curve might be more than we can afford....  I may have to look at it, 
though....

Our whole purpose is to build an embedded panel that has essentially the 
same interface from the web as from the local LCD - it's complicated a 
bit by our limited input system - an encoder and arrow buttons - but we 
already have all of the JS and PHP written.

Since the backend is written to support IE, FF, and any other JS capable 
browser, we want to maintain the same codebase for both interfaces as 
much as possible, thus the need for forms submission.  The backend 
shouldn't care where the request came from.

--Yan