[Gambas-devel] for future gambas development

Benoit Minisini gambas at ...1...
Mon Aug 21 17:01:24 CEST 2006


On Monday 21 August 2006 00:29, Rob Kudla wrote:
> On Sun August 20 2006 06:49, Benoit Minisini wrote:
> > Then the big problem is how to define the interface *and* the
> > code in Gambas, and see it in the browser with this toolkit. I
> > see no solution at the moment.
>
> I have some ideas about this, and if no one has started their own
> project by the time I'm done with this huge consulting gig (mid
> to late fall) I am going to do it myself.
>
> Basically, what you said is accurate.... the interface elements
> in the browser would just send XmlHttpRequests back to the
> server to trigger the Gambas event code.  This would include
> timer objects, which would just be implemented in Javascript but
> work the same as the interface elements.
>
> As for how to generate events on the server that affect the
> interface, that's a problem with all Ajax toolkits, not just a
> Gambas-based one.  It'll have to be an option that the developer
> can set, but ultimately I'm afraid it's going to come down to
> polling.
>
> > In other words, the event loop must be completely managed by
> > the browser.
>
> That's the way with any client/server application.... the client
> manages the event loop.  But that's not so different than what
> we have now, where Qt or Gtk manages the event loop and waits
> for input from the UI.  Instead of getting X events we'll be
> getting network events.
>
> > Maybe by taking their code, and modifying it deeply? It is an
> > huge job...
>
> I don't think we should try to tack on someone else's toolkit.
> Most of the magic here is going to be done by generating
> Javascript and sending it to the browser along with HTML or XML
> and CSS files representing the interface (which I am already
> doing with Gambas forms right now in an existing (huge) Ajax
> project, but using Perl as my CGI language and doing far more
> processing on the Javascript side) and I think for the sake of
> performance and maintainability we should maintain the ability
> to tune our view and controller code.
>
> > Another point: their toolkit is rather slow on my Firefox, but
> > I think we cannot do anything about that. Thanks to AJAX, now
> > we will need an AthlonX2 to browse the web :-)
>
> I've run into this too, and it's pretty frustrating.  I imagine
> the next browser arms race is going to be "who can make
> Javascript and async communications the fastest".
>
> Rob
>

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.

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?

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.

-- 
Benoit Minisini





More information about the Devel mailing list