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
[EMAIL PROTECTED]
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: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>
