[Gambas-devel] for future gambas development

[Benoit Minisini]

On Monday 21 August 2006 18:16, Rob Kudla wrote:
> 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
>

Is there a way in JavaScript to update a DOM node from its id and a XML 
string, without having to evaluate any JavaScript code?

I don't know enough JavaScript to answer that question...

Something that could be like 'document[IdFromGambas].Html = HtmlFromGambas'. 
Eveything would be parse by the browser then.

-- 
Benoit Minisini