On 17.Jul.2001 -- 10:07 AM, Berin Loritsch wrote:
> > a) XForms expects XML encoded parameters. I'm not 100% sure on
>
> Which means that for the two standard submission types (url encoded
> and multipart), the XPath expression is used to reconstruct the XML
> document.
So, do you think this is advisable, to reconstruct the XML?
> > c) XForms declare forms within the <HEAD/> section of a
> > document. XSP don't have such a concept.
>
> This is a markup issue. Basically, the instance/schema/binding info
> is stored at the top of the document in an <xform> tag.
As there's no part of an XSP that is an equivalent of the <HEAD/>
part, the question arises where to put it instead. Just anywhere at
the top? Anywhere before the first form element? Or, what the hell,
like before with HTML forms, all form elements nested?
> > d) XForms' forms can be mixed and nested. This is not possible
> > with current XHTML forms.
>
> This is true. There are two potential solutions:
>
> 1) only have one form for the whole document and separate the
> markup and validation at server side.
This is probably the way to go. Although different target URIs for
different forms would be cleaner, this could be achieved by action +
matchers on parameter values instead of URIs. Such matchers already
exist in C2.
> 2) force the user to use XHTML form constraints.
>
> > e) XForms specify validation as XPath expressions. Makes only
> > sense if form data is accessible through XPath.
>
> In an XForms implementation this is a requirement. Validation is
> done via Schema (current spec), as well as Dynamic Constraint Language
> (based in part on ECMAscript).
>
> References are by XPath.
I think this could be postponed to a later evolution of such a
package, can it?
> > f) XForms specify active behaviour: triggers, conditionals
> > ... This is probably out of scope.
>
> This can only be in scope if you have a transformer that creates
> Javascript on the fly. As different browsers have different methods
> of referencing form parts, this is where the BrowserSelector can
> come in handy.
>
> Again, this is not easy.
So, again, this shouldn't be part of an initial offering.
> > h) XForms specify subpages. Whiles this could be done it's also
> > probably too complex for short term availability.
>
> I would implement it as another "page" in the form. In other words, we
> do validation on the information we have, and go to the subpage, etc.
This is a (minor?) breach from C2 philosophy, to split different views
into separate XSPs. OK, this is not really relevant here and therefore
more or less OK. Again, an issue for later revisions.
> > i) XForms don't specify error messages.
>
> This is my biggest beef with it. They have heard this complaint before.
Well, we could extent and embrace ;-) A similar functionality could be
done with the <switch/> contructs in XForms and those triggers. For
usability error messages would be quite important to be available in a
clean and simple way. And as you said, XForms is a moving target, so
perhaps, this is going to happen anyway :-)
> > To do would be (not necessarily in order of importance)
> >
> > 1) enhance form validator action to validate more XForms basic
> > types.
>
> XForms is now completely Schema based. Throw the generated XML through
> Xerces and see what gets kicked out. I would implement the ErrorHandler
> so that all errors can be cached.
Mmmh, another source of errors in C2. Not valid Schema
definitions. And a reason to really reconstruct the XML. Think I'll
need to look a bit closer at XForms :-|
> > 3) provide stylesheets that render HTML-4.0 forms (probably
> > separate ones for IE, NS &c), XSL-FO &c.
>
> I started on this a while ago. The overall style really depends on
> the site. Bottom line is that XForms is a moving target.
Granted. But there need to be an example so that a form package is
usable and as a starting point for every one else to customize. Of
course there're a number of design alternatives in the XForms
spec. e.g. <selectOne/> -> radio buttons, check boxes (?!), drop down
boxes (<select size="1"/>), select boxes (<select/>), ... and such a
stylesheet would probably provide only one or two of these i.e. based
on the number of <item/>s.
> > 4) provide javascript routines that do client side checking (as
> > well for major platforms)
>
> This really would have to be both platform and XForm specific. The
> Javascript would need to be auto-generated.
I think some basic checking could be done independantly, check that a
field only contains numbers and display a pop-up if there's a
violation should be manageable.
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]>
