cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mratl...@collegenet.com
Subject woody questions
Date Wed, 15 Oct 2003 20:07:43 GMT
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="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. 
   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.

Cheers,
--Michael

Mime
View raw message