Dario Mannu - Logo

XML UI

This is a software architecture essentially based on the integration of traditional development languages, methods, frameworks, with an XML, XHTML or HTML based user interface.

The purpose of this architecture is having the most standard and powerful user interface platform like HTML and its extensions (XHTML, Flash, JavaScript), in programs which still behave in a stable and usual way. This can be thought of like a client-server programming model, in which the client and the server are mostly on the same machine

How does it work

Basically the key is the extensive use of embedding.

  • In Windows we embed a WebBrowser control (IE) or the Mozilla ActiveX into the main window of an application, or we use some variants.
  • In Linux we can almost safely use Wine, since ActiveX works fine, as well as the InternetExplorer.Application object, and the Flash plugin, but constant checking is always required, since not all the Windows API's have yet been ported into Wine.
  • I don't know almost anything about Macintosh, therefore I can't say anything about it for now.

The last time I checked out Mozilla's development status, I saw some steps in Mozilla's automatic control by some interfaces, like telnet, Greasemonkey, JSSH but I wasn't able to actually control the DOM whith the last one. I didn't develop for Mozilla since that.

Our need depends on the actual architecture we use. I worked on the following ones, in the last years:

  • Browser embedded in an application, host for many ActiveX controls.
    This is a way I used in a very protected environment, in which we didn't want any user to access the operating system's controls directly. The main application is the only window shown at full screen on the desktop, and the only widget contained by it is the web browser control.
    The browser shows up an HTML page with all the best graphics we can draw. It contains the usual XHMTL+CSS elements, plus ActiveX (XPCOM) controls for special purposes, and JavaScript animations for special effects. Some of these objects could be Handwriting recognition aware text boxes for Tablet PC's, or other video playback components which do their own job, and are controlled by methods exposed to JavaScript. I Think Juke box software or some kind of public terminals could be developed this way with cheap effort and interesting results.
    The main application window has no significant role, and almost all the business logic is done by JavaScript and embedded components.
  • Browser embedded in an application, hosting the UI only, and talking to the container.
    This way is the main application which contains the low level code. The web browser only shows web controls and calls the main application's methods.
    Since the main window is able to intercept the browser's main events, it could be a good "war-browser" for some website hacking purposes: The main window can inject code into the sites hosted by the browser component and hijack it's behaviour.
    I'd also suggest this for small applications, as the upwards communication from the browser to the main application could be not more than tricky.
  • Independent browser windows called from within the application or script, and partially controlled by it

    This is the fastest way to create a web site hack, since in Windows requires a JScript or VBScript script run by WSH, no compilation. Here's a VBScript sample: 
    var browser = new ActiveXObject("InternetExplorer.Application")
browser.visible = true
browser.navigate2("http://www.darius.co.hu/")
while(browser.busy)
	WScript.sleep(20)
browser.document.getElementsById("p")[0].innerHTML 
         = "dynamically injected text"
browser.document.forms[0].submit()

Stability and performance

I first used this architecture on Tablet PC's with 1000Mhz CPU. First I tried to make a normal web application through IIS - HTTP - Web Browser, but I was very annoyed by the long page loading delay. Now we have much faster CPU's, so this isn't necessary anymore. Even complex page rendering with embedded components is fast enough on 2GHz processors.
If You have a slow environment for any reason, the Windows solution needs to cut off IIS and set the correct permissions in Internet Explorer, for the local security zone. The main application could be the best place to set the correct registry values and let the embedded browser run without security warnings.
I wanted my software to be stable as well, but many movie playback ActiveX controls plus other ones in HTML pages some times led to nice crashes. The solution was separating working services's processes from the UI, so that after a UI crash, that could be restarted and reconnected to the still working services - let's say video recording components, network operations, and so on.
Using JavaScript can also be easy to recover an HTML page from a crash: it's enough to capture any UI event (mouse, keyboard, stylus), and record a journal somewhere. This way, after a UI crash we can restart it with the very last pressed key restored, and even stylus strokes on Tablets.