Re: XML/XSL on the client for dynamic UI

["Lou Colon" <lcolon@xxxxxxxxxxxx>]

I've measured a total of about 1 second (on the server) to a) read the XML
doc and parse it, b) read the XSL doc and parse it, c) transform the XML to
generate the HTML output. Every page is unique and thus the output or the
XML input cannot be cached.  Sometimes, the XSL can be cached as it may
contain common rules for many of the pages. This can reduce the total time
by about 40%, still requiring over 500ms for each page based on the same
rules.
-lou

----- Original Message -----
From: Tim Taylor <ttaylor@xxxxxxxxxx>
To: <xsl-list@xxxxxxxxxxxxxxxx>
Sent: Wednesday, October 27, 1999 11:28 AM
Subject: Re: XML/XSL on the client for dynamic UI


> Is every page dynamic with every request?  I've found that with Cocoon,
> once a page is cached, it frequently finishes processing in under 50ms.
>
> Lou Colon wrote:
> >
> > It has been my experience that XSLT (tested with various transformers)
can
> > be a bottleneck on a high-volume web/app server.  The combination of XML
and
> > XSL to generate HTML on a server can take about 1 second.  This makes it
> > difficult to handle millions of page requests daily. Thus, it would be
ideal
> > to let the client do the transformations, rather than the server. This
> > distributes the required processing much better.
> >  -lou
> >
> > ----- Original Message -----
> > From: <zun@xxxxxxxxxxxxxx>
> > To: <xsl-list@xxxxxxxxxxxxxxxx>
> > Sent: Tuesday, October 26, 1999 4:50 PM
> > Subject: Re: XML/XSL on the client for dynamic UI
> >
> > > 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
> > >
> > > 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.
> > >
> > > 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.
> > >
> > > . . . Sean.
> > >
> > >
> > >
> > >
> > >  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
> >
> >  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
>
> --
> Tim Taylor
>
>
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


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