cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Haul <h...@dvs1.informatik.tu-darmstadt.de>
Subject Re: AW: forms in coocon2, is SchemoX dead ?
Date Tue, 17 Jul 2001 13:37:40 GMT
On 16.Jul.2001 -- 09:28 PM, java guru wrote:
> I agree about the xform and xfdl..In future, i guess,
> these concepts would go beyond just form validation
> and handling..

To me it looks like xfdl is not actively maintained by W3C, since the
document is rather old.

> For now, from this discussion, I understand that we
> are all looking for some form of automated/simplified
> form generation/validation and handling..am i right?..

Right.

> And also, there are efforts on going with current
> cocoon reg form validation and other stuff...they seem
> to follow the xform approach from nanotech..but not
> sure if the original author has intent of extending it
> to be full blown form generator/validator/handler or
> not...

Well, I'm not the original author but have supplied some of the
validations. Indeed, I would like to extend this to a more complete
form generator/validator. But I haven't made up my mind, which way to
follow.

To me, XForms looks like the most importand standard on this but I
think it is not advisable to aim for a fully compliant implementation
for C2 because (please correct any errors)

    a) XForms expects XML encoded parameters. I'm not 100% sure on
       this, but I think few to none of the available browsers
       support this. I don't think it would make sense to convert
       request parameters to a XML representation before processing
       them since this would probably be too costly. A Javascript
       solution to post parameters as XML is propably out of the
       question.

    b) XForms allow besides the basic types arbitrary types definable
       in XML Schema. While this might be possible for validation, it
       is expensive but seems only necessary if parameters are XML
       encoded. 

    c) XForms declare forms within the <HEAD/> section of a
       document. XSP don't have such a concept.

    d) XForms' forms can be mixed and nested. This is not possible
       with current XHTML forms.

    e) XForms specify validation as XPath expressions. Makes only
       sense if form data is accessible through XPath.

    f) XForms specify active behaviour: triggers, conditionals
       ... This is probably out of scope.

    g) XForms provide sliders, subpages, lists &c. This is too complex
       for short term availability.

    h) XForms specify subpages. Whiles this could be done it's also
       probably too complex for short term availability.

    i) XForms don't specify error messages.

    j) Since validation is (at least additionally) server based, this
       should keep the already filled in elements.

>From this follows, that a fully compliant implementation should not be
the goal.

To do would be (not necessarily in order of importance)

   1) enhance form validator action to validate more XForms basic
      types. 

   2) provide a taglib that combines necessary features from
      formval.xsl and request.xsl plus some form specification that
      produces valid XForms

   3) provide stylesheets that render HTML-4.0 forms (probably
      separate ones for IE, NS &c), XSL-FO &c.
     
   4) provide javascript routines that do client side checking (as
      well for major platforms)

Suggestions, ideas and helping hands welcome :-)

	Chris.

-- 
C h r i s t i a n       H a u l
haul@informatik.tu-darmstadt.de
    fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>

To unsubscribe, e-mail: <cocoon-users-unsubscribe@xml.apache.org>
For additional commands, e-mail: <cocoon-users-help@xml.apache.org>


Mime
View raw message