call for client side processors

> I guess you could implement XSLT based XForms solution on 
> client with only a limited functionality. 
> Hoever, if you want to exploit the full power of XForms's 
> processing model (E.g. bind computations, Xml events, dynamic 
> constructs, etc.), existing html/xhtml browsers cann't be 
> effectively used, unless you extend their functionality 
> programmatically.

Until now I didn't implement any of the features you mentioned. But most
certainly it can be done using the current implementations of DHTML,
Javascript and DOM in IE or perhaps Mozilla.


> There are a few solutions which try to map XForms to xhtml + Jscript,
> considerably increasing size of the document and reducing the 
> execution
> speed. But, as we know, these solutions are only gap-fillers. 
> 

I believe that the server based solutions are the gap fillers, because 100%
client side processors are

 a) much faster because they
  a1) don't need a network roundtrip for every action
  a2) only read data but no html
  a3) may cache static xml data
  a4) don't reparse the whole document all the time

 b) more secure because they a1) ... therefore the guys on
    the server side (and nobody else on the web) can track
    your actions

 c) still working (against local data) when you're offline 

 d) easier to implement because you don't have to use
    HTTP GETs and POSTs

 e) easier to deploy because you don't need a web server
    and/or servlet container


  ** Anybody who likes to join in on my  **
  ** IE6 + JS project is warmly welcome. **



Matthias



> Shailesh Karandikar
> Dendrite Intl.
> 
> Alex,
> 
> all public xforms processors I know about run on the server 
> side. My own
> 100% client side "experiment" for IE6 is far away from beeing 
> releasable. It
> uses dhtml instead of xsl ( ... because it was the "shortest path" ;-)
> 
> greets
> 
> M.
> 
> > does anyone know of an example out there that uses 
> > xforms in xhtml, and styled one the client side with 
> > xsl?
> > 
> > thanks,
> > -alex
> > 
>

Received on Wednesday, 21 August 2002 11:49:09 UTC