[Gambas-devel] for future gambas development

[Rob Kudla]

On Mon August 21 2006 11:01, Benoit Minisini wrote:
> Javascript/HTML generated interface should send events to the
> Gambas application by using XmlHttpRequest, that's ok.
> Now maybe the Gambas application could answer by sending an
> updated DOM model of the page. This way, reloading the entire
> page is avoided.

Yes, there isn't much point of using XmlHttpRequest unless you're 
only going to update part of the page.  Otherwise you could use 
straight CGI and wouldn't need Javascript at all except to 
submit a form on the page upon input.  And it would be soooo 
ugly and slow.

The way XmlHttpRequest works is, you pass it an URL and a 
callback function.  In our case, the URL is the Gambas 
application and the callback function would be something that 
takes the output from the Gambas application (doesn't have to be 
XML, I use pipe-separated values in my particular app because 
just using "split" is a lot faster than JS XML handling) and 
takes the needed actions.  So essentially we would need to 
handle all the gb.form objects' display-related properties in 
that callback function.

> After all, the gambas application generated the current page,
> so maybe it could keep its state, and then could send the
> difference between the old one and the new one to the browser?

That's not a bad approach, but the Javascript on the client side 
might be more complex and therefore slow.

> I don't know how this could be implemented in JavaScript:
> updating the DOM model of the current page from a file
> describing the differences.

It absolutely could, I'm just concerned about performance.

The fastest way to do it (performance wise) would be to send back 
down a small Javascript function that does all the necessary 
work, and then have the callback function eval() that code.  
Then there's no client-side parsing of any kind, and the 
gb.ajax.form (or whatever) component could just generate the 
necessary Javascript in each method and property set/get.  You 
could even move the browser detection code into the Gambas app 
using this approach, maybe adding a property "Browser" to the 
Form object.  Not to support every possible browser, just 
correct showstopper incompatibilities.  But somehow, I have the 
feeling there's a downside to that approach that I'm missing. 

Rob