cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <tcu...@dff.st>
Subject Re: [RT] forms
Date Thu, 19 Jul 2001 13:08:37 GMT
I have had a look on the updated XForm specification.
And here are some more RT:

Unfortunately there is only little information on subpages
in the spec. But this is what I understood from spec a
multipage form could look like:

<xform:pages>
  <xform:subpage name="name">
    <xform:xform id="orderForm">
      <xform:instance>
        <order>
          <firstname/>
          <lastname/>
          <email/>
          <city/>
          <country/>
        </order>
      </xform:instance>
      <xform:textbox ref="order/firstname">
        <caption>Firstname</caption>
      </xform:textbox>
      <xform:textbox ref="order/lastname">
        <caption>Lastname</caption>
      </xform:textbox>
      <xform:textbox ref="order/email" validate="???">
        <caption>Email</caption>
      </xform:textbox>
    </xform:xform>
  </xform:subpage>
  <xform:subpage name="address">
    <xform:xform id="orderForm">
      <xform:textbox ref="order/city">
        <caption>City</caption>
      </xform:textbox>
      <xform:selectOne ref="order/country">
        <caption>Country</caption>
        <choices>
          <item value="DE">Germany</item>
          <item value="US">USA</item>
          <item value="UK">United Kingdom</item>
        </choices>
      </xform:selectOne>
    </xform:xform>
  </xform:subpage>
  <xform:subpage name="overview">
    <xform:xform id="orderForm">
      <xform:output ref="order/firstname"/>
      <xform:output ref="order/lastname"/>
      <xform:output ref="order/city"/>
      <xform:output ref="order/country"/>
    </xform:xform>
  </xform:subpage>
  <xform:subpage name="thanks">
    <p>Thanks, we accepted your order</p>
  </xform:subpage>
</xform:pages>

So how could we tackle things now. I think it is quite
natural on such approach to have a DOMObject that will
hold the instance data of the xform. The most simplyfied
definition of such an interface would probably be:

interface DOMObject extends XMLFragment, XMLConsumer, XMLProducer {
  public void setValue( String XPath );
  public String getValue( String XPath );
}

When a subpage is chosen to be viewed an intance of
an DOMObject referring to the xform id needs to be
looked up. If there is none, one needs to be created
and registered. (Just like the Components in the ComponentManager)
Creation means also passing the SAX events from the
xform:instance data to the DOMObject. Now the DOMObject
holds the expected XForm structure.

Now we have an XFormAction that will do:
* Population of values into the DOMObjects
* Validation of the populated values in the DOMObjects
* Selection of the subpage based on the validation results

Then I would propose a XFormTransformer that will
extract the selected subpage fragment and add the
value to the xform elements. Here is an example of
what should come out of the transformer:

<xform:pages>
  <xform:subpage name="name">
    <xform:xform id="orderForm">
      <xform:instance>
        <order>
          <firstname/>
          <lastname/>
          <email/>
          <city/>
          <country/>
        </order>
      </xform:instance>
      <xform:textbox ref="order/firstname">
        <caption>Firstname</caption>
        <value>Torsten</value>
      </xform:textbox>
      <xform:textbox ref="order/lastname">
        <caption>Lastname</caption>
        <value>Curdt</value>
      </xform:textbox>
      <xform:textbox ref="order/email" validate="???">
        <caption>Email</caption>
        <value>dsff</value>
      </xform:textbox>
    </xform:xform>
  </xform:subpage>
<xform:/pages>

Or maybe to the instance data structure:

<xform:pages>
  <xform:subpage name="name">
    <xform:xform id="orderForm">
      <xform:instance>
        <order>
          <firstname>Torsten</firstname>
          <lastname>Curdt</lastname>
          <email>dfds</email>
          <city/>
          <country/>
        </order>
      </xform:instance>
      <xform:textbox ref="order/firstname">
        <caption>Firstname</caption>
      </xform:textbox>
      <xform:textbox ref="order/lastname">
        <caption>Lastname</caption>
      </xform:textbox>
      <xform:textbox ref="order/email" validate="???">
        <caption>Email</caption>
      </xform:textbox>
    </xform:xform>
  </xform:subpage>
<xform:/pages>

This would probably make the XSLT stylesheet a lot more
complicated but would be even more consistent.

A Transformer will have different consderable advantages:
* the form does not usually have to be an XSP page
* at least the describtor XML can be cached then
* the form can be filled from esql or other taglibs easily
* taglib would mean to but multiple (sub)pages into
  one XSP page - I'm always afraid of the 64k limitation
  of XSP pages

--

This presented concept leaves even room for the business
object mapping that I want. A "class" attribute could be
added easily to the xform:instance tag that will specify
the actual class to use. The business objects only have
to implement DOMObject or be an intance of an AbstractDOMObject.

Still there are some issues left.
* error reporting
  The validator could set an errorcode attribute in
  the DOMObject. But somewhere there must happen
  a translation into a full message. Maybe we could
  reuse the i18n transformer for this? So what comes
  out is something like:

  <xform:textbox ref="/order/firstname">
    <error><i18n:translate>firstnameERR001</i18n:translate></error>
  </xform:textbox>

  So the correct error messages only have to be
  specified in the dictionary. voila!

* DBMS comboboxes
  (just peeked into your answer on the list ;)
  Of course this shouln't be an issue because
  of DBMS caching of queries - but unfortunately it is.
  In real world it turns out that still the DBMS part
  is the slow one. Especially because usually form pages
  cannot be cached. We had a couple of case where
  there where up to 100 items. And multiple comboboxes
  per page!
  DBMS changes aren't a problem for the applications
  we wrote so far. If so - well then use esql to
  fill the combobox... But I would consider this
  need as unusual.

* output definition
  I think what is not quite clear (at least for me)
  from the XForms spec is what "output" means
  on selections aka choices. Is it the value
  or the text? Both is needed! So how do you specify
  what you want on output. This also another
  pro for the DBMS comboboxes. The only way
  to get text from the value or the value from
  the text would be another query - not good!

* subpage navigation
  A subpage is only a part of a xform. So submit
  would not be the right term to goto the next
  subpage. I haven't any spec for that. I would
  propose somthing like:

  <xform:popup name="subpagename"/> or
  <xform:goto name="subpagename"/>

* datatypes
  How can we integrate datatypes?

* binding
  How can we integrate binding?

Again, comments please :)
--
Torsten


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message