Re: XML/XSL on the client for dynamic UI

Hi Sean, everyone,

>From: zun@xxxxxxxxxxxxxx
>Date: Tue, 26 Oct 1999 16:50:09 -0400 (EWT)
>
>Hi Olivier, everyone,
>
>On Tue, 26 Oct 1999 oberthier@xxxxxxxxxxxx wrote:
>
>> Maybe to rephrase the idea, the flow of the application would 
>> be something like this:
>> 
>> 1. On the server, the XML data file is prepared from the 
>>    content of several RDBMS table.
>> 2. The user receives in its browser this XML document and a 
>>    way to render it.
>> 3. The user then enters the data he wants into various fields
>>    (each of them having its own validation and event handling,
>>    for instance implemented in JavaScript if we keep the
>>    browser idea). All those changes are automatically 
>>    updating the XML document locally.
>> 4. When finished, the user is submitting the updated XML data
>>    back to the server which will update the database tables
>>    accordingly.
>> 
>> My current interest is mainly on steps 2. and 3., 1. and 4.
>> starting to be easy to address on an application server, or at
>> least people are obviously working on it at the moment (see 
>> the recent XML server debate on this list).
>>
>
>I don't see any problems on doing 2 and 3 with XSLT.  The major 
>roadblock is that none of the major browsers have an up-to-date 
>XSLT implementation yet, but that can be circumvented by using 
>it on the server side.
>
>So for today, you'd have to do something like:
>
>2. Server generates HTML+Javascript from XML data file using 
>   XSLT.
>
>3. User enters data, Javascript posts back to server

With this point 3., you are touching exactly what I would 
like to avoid, which is what I was mentioning in the initial 
thread as the unnecessarily heavy part of binding screen data 
back to XML.

In your scenario, the Javascript on the client needs to gather 
all the data from the Form fields and post them back. This post
should be under an XML form following the original DTD, and this
logic may be heavy to implement in Javascript and most likely
tough to maintain afterwards. This is the first problem.

Moreover the limitation of this model would be encountered 
rapidly when the forms are starting to be more complicated,
especially when some fields are linked to others. E.g. the
content of an input field is supposed to be shown as the
default content of another field. Such cross field 
synchronisation would need to be handled by the Javascript as
well making it rapidly very messy.

It is based on the above remarks that I was bringing up the idea
of having the XML data on the client (and for the location of
this data file right on the client side, I fully agree with Dan's
thread (disco@xxxxxxxxxxxxxxx) and the reasons he is invoking).

Hence the two choices I've been investigated so far because 
they seem to address the various requirements listed before:
How to maintain the XML data on the client and automatically
update its content while the input is done on the form fields?
  -> XML data island, DSO bindings to HTML elements.
  -> XSLT producing locally some HTML, based on an XML data 
     island. Each form field is having an onblur method
     updating the related node in the XML data and then
     applying the XSLT transformation to refresh the whole
     HTML UI.

The first scenario seems to work fine, but is not standard and 
there is no XSL there. The second involving XSLT is causing me 
basic problems with basic UI things such as the handling of 
focus, etc...

>
>The loss here is the transmission of the raw XML data in step 
>2.  But you can rectify that by providing another URL for it on 
>the server.
>

Yes, and it is having the major drawbacks I'm listing above.

>
>I'm not saying step 2 is easy mind you =)  If you want to work 
>on the Javascript code, I'll help with XSLT.  Definitely would 
>be an interesting project.
>

Glad to hear you find it interesting. Anybody else? Is there
some audience for such a project?

Olivier.


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list