woody questions

[mratliff]

Sylvain,

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.)

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?  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.

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"} ?  

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="" /> 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.  
   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 , 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.

Cheers,
--Michael