[RT] XForms, scripting and client side dynamism

[Stefano Mazzocchi <st...@apache.org>]

Here we go,

as promised, a bunch of random thoughts live from my refreshed brain
cells. I will mostly cover things that are not directly Cocoon-related
but that you should be aware of, expecially since Cocoon will have to
move in that direction probably sooner than later.

Some already expressed the need for better XML-web-app capabilities.
things include

 - turbine integration
 - direct XML editing
 - database integration (castor, ozone, XMLDB, Oracle, etc...)
 - XML upload and other B2B practices

We all know that Cocoon is great at "getting something to you", much so
great in "getting something from you". This asymmetry is driven by need,
since much more things come from the server than from you. The problem
is that even if data is less in term of volume, the importance of this
submitted data is very relevant.

Don't get me wrong, it is possible to create complete web applications
using XSP and HTML forms. No particular problems there, it's the old JSP
model.

The question is: can we do something better? It is reasonable to think
at a form submission as an XML file post? would it be feasible to
rethink the web as "XML in, XML out and a bunch of filtering"?

For the part "XML out and a bunch of filtering" we all agree there will
be no problems. For the "XML in" part, we are not there yet. But Cocoon
could play a major role here.

Let's see how.

Donald wrote a way to integrate regular forms with server side XML
content, encoding xpaths into form names. While very clever, I think
this is a dangerous hack for a couple of reasons:

 - security: altering the xpath on the html source could create security
problems
 - cross-site portability: the XML schema must be known from the outside
to be able to create the xpaths, something that normally is hidden and
would not allow one form to post on another site. Ok, this is still true
for regular forms, but those names do not have any particular meaning
rather than for the form upload, unlike xpaths.

So I looked around to see if there are any better solutions, and I found
the W3C XForms WD (look at www.w3.org/TR/). While I believe a lot of
work is still required for them to come up with something useful and
coherent with the rest of the XML model, their ideas match my
requirements:

 1) structure
 2) XML post
 3) security

without sacrificing old form encoding.

Here is an example that uses XForms with XHTML

<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML-XForms 1.0//EN"
"http://www.w3.org/TR/xhtml-forms1/DTD/xhtml-xforms1.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>Purchase Order</title>             
<xform xmlns="http://www.w3.org/2000/xforms"
       action="http://host/path/to/resource"
       method="postXML"
       id="ship-info">
  <model>
    <group name="purchaseOrder">
      <group name="shipTo">
        <string name="name"/>
        <string name="street"/>
        <string name="city"/>
        <string name="state"/>
        <string name="zip">
          <mask>ddddd</mask>
        </string>
      </group>
    </group>
  </model>
  <instance>
    <purchaseOrder>
      <shipTo>
        <name>Alice Smith</name>
        <street>123 Maple Street</street>
        <city>Mill Valley</city>
        <state>CA</state>
        <zip>90952</zip>
      </shipTo>
    </purchaseOrder>
  </instance>
</xform>
</head>
<body>
  <h1>Shipping Information</h1>
  <form name="ship-info">
    Name: <input name="purchaseOrder.shipTo.name"/><br/>
    Street: <input name="purchaseOrder.shipTo.street"/><br/>
    City: <input name="purchaseOrder.shipTo.city"/><br/>
    State: <input name="purchaseOrder.shipTo.state"/><br/>
    Zip: <input name="purchaseOrder.shipTo.zip"/><br/>
    <button onclick="submit('ship-info')">Submit</button>
  </form>
</body>

While the example (and current WD) is clearly XHTML centric, one of
their requirements is complete integration with other medias such as FO
and SVG.

But what happens when we hit the submit button? This is not defined yet,
but I presume that the created XML fragment will be sent as the submit
action handling resource as an XML payload, following the XForm model
(which, IMO, should be an XSchema fragment, but it could be easily-XSLT
tranformed into one), validated on client side, then sent, then
revalidated on server side (for security), then passed to the resource.

Now, should Cocoon be aware of this?

Not necessary.

This kind of forms can work with every http POST handling routines, if
they are able to distringuish between POST and POSTXML actions. So, for
servlets you could do

 void doPostXML(request, response);

while for Cocoon we could have

 PostXMLGenerator extends Generator

or something like that. No biggy, it's just a different way of
submitting information via HTTP.

The important part is, like everything else on the XML world, acceptance
and availability on client side: since most of this XForm handling
should be performed on client side and I'm _very_ skeptical that
browsers will adopt this sooner than a couple of years, we need to do
something.

So I looked around and I found a reference to www.mozquito.org, which is
an interesting concept, even if very ugly in many design details. (I
suggest you to take a serious look at it). Basically it's a tranformer
that is able to transform extended XHTML into DHTML (dynamic HTML).
Basically, it "compiles" the extended XHTML page into a javascript
source file that is able to generate the right page on the browser
screen. It's "almost" like client side compilation.

Why? well, the idea is to let the browser do all this "Xforms" magic
using javascript logic.

My question is: would it be feasible to create client-side logicsheets?
Stuff that transforms <xform> tags into "<form> plus a bunch of
ECMAScript"? how hard would that be? how portable? how big?

I know almost nothing about client side scripting (even if I'm going to
fill up this knowledge gap pretty soon), but I believe that Cocoon
should try to move more into to the client side to enhance the "web
experience".

Dynamic HTML is very cool. The creation of DHTML taglibs would be a way
to let people write nice pages without worrying about "which browser is
which" and fill their scripts with "if(ie4)" ifdefs. I'm not talking
about fancy "flash-like" DHTML, but stuff like "click here to modify"
type of things, or WML-like decks for slideshows, or onMouseOver()
events. All those fancy things that you normally consider crap because
of incompatibilities and cost of ownership.

Ok, I think it's enough for now.

I would like to hear comments from those scripting gurus of you, as well
as those of you who have more experience than me on data upload using
forms.

Hope my vacation was productive for everybody :)

Yes, people, I did have fun :)

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------

Re: [RT] XForms, scripting and client side dynamism

["Kevin A. Burton" <bu...@relativity.yi.org>]

Stefano Mazzocchi wrote:
> So I looked around and I found a reference to www.mozquito.org, which is
> an interesting concept, even if very ugly in many design details. (I
> suggest you to take a serious look at it). Basically it's a tranformer
> that is able to transform extended XHTML into DHTML (dynamic HTML).
> Basically, it "compiles" the extended XHTML page into a javascript
> source file that is able to generate the right page on the browser
> screen. It's "almost" like client side compilation.

Yup.  This is needed.  This has sort of been talked about for Servlet
1.3.  The whole technology set really lends itself to XML (data typing,
validation, etc) and it needs to happen.  (and has needed to happen for
a while.)
 
> Dynamic HTML is very cool. The creation of DHTML taglibs would be a way
> to let people write nice pages without worrying about "which browser is
> which" and fill their scripts with "if(ie4)" ifdefs. I'm not talking
> about fancy "flash-like" DHTML, but stuff like "click here to modify"
> type of things, or WML-like decks for slideshows, or onMouseOver()
> events. All those fancy things that you normally consider crap because
> of incompatibilities and cost of ownership.

I agree.  DHTML had (still has with Mozilla) but is client specific at
best.  A decent stylesheet could make data input much better.

-- 
Kevin A Burton (burton@apache.org)
http://relativity.yi.org
Message to SUN:  "Please Open Source Java!"
"For evil to win is for good men to do nothing."