Sylvain,
Why me? A lot of people are using Woody and are up to speed on it, now.
I'm digging deeper into Woody/Flowscript, trying to determine if I can adapt it to my needs. This would be a lot easier if everyone working on the Woody stuff would just stop innovating. It is very difficult to stay abreast. :-)
Maybe you could save me some time by answering a few questions:
1. AFAIK the "required" property is part of the widget description, not part of the widget instance. This means that if a widget is required it is required for everybody? How would you handle a form where "required" is dynamic (conditional)? Example: someone checks a boolean to indicate that they are not a U.S. citiizen, so "Visa Number" becomes required. Otherwise it is not required. This sort of thing is pretty common in our forms. (Our forms even have dynamic *validation* rules.)
You're right: the "required" is in the description. To achieve what you want, you can make the widget non-required (hey, that's what it is, after all) and check that it does have a value in a custom validator.
2. In all examples I have seen, validation error messages are expressed as JavaScript alerts. Is this just a presentation detail? Could error messages could be presented as in-line XHTML or in a separate window, or whatever?
Yes, this is a presentation detail. On my dream todo list, I have using the popup window stuff already used in the calendar to have sexier displays.
In future, could we use some sort of markup in the template file to denote where Woody transformer should insert error tags? This was a nice features in XMLForm. IIRC, XMLForm had an <errors> tag and an <error> (singular) tag. You could stick the <errors> tag anywhere you wanted in your template and it would be "filled-in" with the entire collection of <validation-error> elements. A singlular <error> tag within a widget element would cause only <validation-error> elements for that particular widget to be inserted. This supported a wide variety of client-side error presentation schemes.
You can do this using a custom styling XSL, by introducing an "instance-only" pseudo-widget such as "wi:errors". The rendering of this widget would crawl the widget subtree and gather their error messages. IIRC this is approximately how it was done in XMLForm.
3. What about mutiple page forms? Especially non-wizard (navigate from any page to any page, etc.) forms? I recall reading something about handling multipage forms as separate forms tied together by a flowscript controller? However, are there not aspects of a form (validation, business logic) which may span more than one page? For example, how would one write a validation rule that says: { if user checks "reserve married housing" on page one, then their answer to "single or married?" on page 3 must be "married"} ?
Woody only concentrates on a single form. The validation you explain above can be done in the flowscript, by extracting the relevant values from the forms to correlate them when all the needed values have been input.
4. Finally, a vague rumination... I've been looking at the event handling javascript in carselector_form.xml. Did you consider expressing this logic as XML? Imagine you wish the form model to respond to a <wd:on-value-changed> by setting the value of another widget. You could insert an element like <wd:set wiget="foo">value</wd:set> in place of the corresponding javascript code. Whatever is parsing and executing the current "in-line" javascript (I'm completely ignorant about this) could lookup the proper javascript (or, maybe java?) and execute it. You could have "default" tags for "normal" form needs (like calculating a value, setting a value, etc.; the standard XForms events might be a good place to start) and some kind of a mechanism for extending the default tag set. And you could have a "catch-all" element like <wd:extension src="some-javascript.js" /> which would provide the functionality you have now-- being able to use any kind of arbitrary flowscript inside of a <wd:on-value-changed> tag.
I have to finish this stuff, but the intent is for event handlers expression means to be pluggable. As of now, you can write event listeners as Java classes and as JavaScript snippets (see also my GT slides):
<wd:on-value-changed>
<java class="fooListener"/>
<javascript>
print("value changed to " + event.newValue);
</javascript>
</wd:on-value-changed>
So if you really want this xml-ized language, you can add a new listener type.
Of course, the compelling reason for expressing (some) event-handling logic as XML would be to enable automatic transformation by the presentation pipeline into the proper client-side javascript. It should be pretty straightforward to turn <wd:set widget="foo">some-value</wd:set> into onchange="document.forms[0].elments['foo'].value=some-value" , etc. In principle, this should work for all kinds of client side validation, calculation, dynamic display, etc. And different pipelines could produce different javascript (or its equvalent) for different devices.
Just a thought...and maybe a lunatic one.
No, no. That's interesting. But the problem of client-side validation is that you'll have to deal with unparsed string values whereas you have object values client-side, and validation code is thus locale-independant.
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
