InfoWorld article -- "Building a Better Browser"

Some good food for thought in this article.

It doesn't mention Mozilla/XUL, but in might as well have, because everything mentioned in the article is completely possible with this platform.

In particular, I am putting some thought into the idea of creating a web-based app that doesn't have to constantly load a whole page (HTML and all), every time some data is changed. Call it "delta-browsing". With a little judicious XUL/Javascript, it should be possible to create a Mozilla library for apps that load a form once, and thereafter only receives the bare minimum of data to update any element on the form. This would be especially important in low-bandwidth apps. As the Gecko rendering engine becomes more and more popular, I expect wireless devices and handhelds to eventually have lightweight Gecko-based browsers. In this case, delta-browsing would become very helpful.

Also, if this library were done right, it would provide a nice clean implementation of the model-view-controller approach.

Stay tuned...

Do you mean something along the lines of Databinding in IE? A template of sorts is created (in HTML, XHTML, or XML), and is tied in with a datasource (such as XML document or db server). This page can be cached, but the content is refreshed from the datasource when requested.

I would be very interested in this. I've been looking for something that will allow real-time editing of database content (rather than pull-push), to allow users to edit their details on slow connections: User opens already cached page, datasource fills in place holders, user edits content in place holders which then instantly updates server info, user closes page auto-saving content. That'd be a lot easier than: user downloads view page. user downloads edit page. user edits text boxes. user submits page. page saves to db. page refreshes to show edited values.

In a sense, yes. Actually, the concept could be used for any element of a web page, not just form elements.

However, it would differ from databinding because it would still be using standard HTTP POST/GET. It would just use it "in the background". I have never used Microsoft databinding, so please correct me if I am wrong, but doesn't it involve running a completely different protocol, such as ODBC, in the background? Such a thing could be a real pain to handle through a firewall.

LOL, dont know - never managed to get it to work! Principle sounds good though. I believe it just uses some type of activex object to connect to the db and run SQL functions automatically... or something along those lines...

This is a very good idea. This is the advantage of what can really only be done with frames at present. The only problem is frames suck You're focusing on reducing bandwidth which is cool because I think that one of the main knocks on browser based applications currently is that they have to reload the same data way too much.

This idea actually fits in well with the slight expansion on n-tier that I'm currently nutting out in my head. I'm sort of trying to capture mvc in the application layer, and my thoughts all relate to the server side. You use a UI component layer (classes and methods) to build your UI. A UI component not only has graphical elements, is populated with data, but passes data back as well (when user submits). Data is passed (to & from the db abstraction) and responses received from within a kind of "controller" script. These components (generated in php initially) would become kind of UI templates, if already loaded (as you mentioned), and then data would be based into them only where required. This would be so much faster than reloading page elements that haven't changed, and combined with some sort of controlled caching you would increase the inefficiency of your system greatly

As I see it, there are three parts to your proposed solution:
1. Client Side Controller, determining when things are downloaded and populated
2. Define UI components server side
3. Way of sending/receiving data

1. Client Side Controller (CSC), determining when things are downloaded and populated
This would be the nitty gritty component. It would download the graphical components, xml data and assemble the page for the user.

2. Define UI components server side
UI compoments would be a combination of traditional HTML/JS and extended with XUL/SMIL. You would probably end up having UI templates, just like we currently have html templates (smarty etc). Each component might have a unique version, so that if the component is updated the CSC will request that it be re-loaded from the server. The CSC will populate the components with the relevant data client side, rather than the current method of downloading already populated components.

3. Way of sending/receiving data
Ok, maybe I'm a bit biased, but the solution to this just shouts out at me. XML.

Neo, if you were going all-X, then the content would be stored in XML, and you would probably use XSLT as a template language to translate to XHTML. I personally prefer php templates for this purpose, and you have to give some careful thought about getting your DB working with XML If you have a system that handles XML, all you need to do is define new Schemas, and you can handle just about any data requirements related to content Then of course you have schemas like xbrl and mathML to handle numerical data, and even SMIL, XUL, XBL to handle an associated UI component