W3C home > Mailing lists > Public > www-forms@w3.org > June 2000

Re: XForms-processor as applet

From: <schulze@dresden-informatik.de>
Date: Wed, 14 Jun 2000 15:24:01 +0200
Message-ID: <c=DE%a=_%p=Dresden_Informat%l=MAGNUM-000614132401Z-401@magnum.dresden-informatik.de>
To: <www-forms@w3.org>
hi all,

yes, the "perfect rendering engine" very much depends on a developer's 
personal view + experience and also on the type of media used for 
output and perhaps some other things. 
That's why there's so much need for customization and I think placing
the XForms renderer over the browser's html4 renderer is a good way
to achieve this. 

Of course, XForms 1.0 is only the specification for such documents
but the manner of rendering XForms for different media should be 
discussed asap, because using a browser can't be the only way.
If we'd put it into java and base it on xsl, it would give us the power
to render the html at server- AND clientside and we could create
postscript for printing forms directly (without OLEing a browser). 

One mayor drawback of this approach is that XForms would have
to rely on jscript / javascript and hook up it's eventhandlers (like
mozquito does). 

Josef: I've checked out mozquito some weeks ago. Very inspiring!
Are you planning further improvements?

I hope that we'll see a XForms DTD or XML schema at the end and 
then everyone can create xsl styles to address his special needs
and output media.

But for me, the most important thing is that forms over xml-data
can be rendered automaticly, based on meta information about 
those data. Thus, I could write some java, that extracts jdbc-metadata
from a database and converts it into xml schema. Another servlet
querys the database and delivers the records as xml. Both files
are then forwarded to the forms renderer (either server- or clientside),
which renders them for output (the "perfect rendering engine"). 
  => the user could switch between single-record, table- and printview
       without requesting the page from the server

Guess that's a long way to go 8-)

Es Gruessli, Matthias

> It would be highly beneficial to have a perfect rendering engine
> (independent of a browser) that will felicitate coexisting of
> pre-printed paper forms and client-printed paper forms (printed from
> within the browser etc). I feel it should be possible to print a form
> from within a browser that looks exactly the same as its paper based
> counterpart and a plugin based approach is better in this regard.

Agreed a perfect rendering engine would be a Good Thing, I feel
technology should be used appropriately.  On paper, I might say "please
circle the answer that best applies", while on a web form I might use a
checkbutton or pull-down list, and on a fax-back form a tickbox.

Like most of us on this list I'm working on a forms generator, and my
view on this is that there could be an extra button marked "Print" to
print out either a pre-prepared paper form, or something suitable
generated on the fly from the XML. The question then becomes, whether
XForms is required AT ALL, or whether we go straight for
HTML4+Javascript generation from a yet higher level metadata standard.

Neil Walker
Neil Walker                     tel:   +44 (0) 1223 330379
MRC Biostatistics Unit          fax:   +44 (0) 1223 330388
Cambridge, UK                   email: neil.walker§mrc-bsu.cam.ac.uk
                                web:   http://www.mrc-bsu.cam.ac.uk 
Received on Wednesday, 14 June 2000 09:22:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:03 UTC