cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: woody questions
Date Thu, 16 Oct 2003 13:33:54 GMT wrote:

> 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 
  <java class="fooListener"/>
    print("value changed to " + event.newValue);

So if you really want this xml-ized language, you can add a new listener 

>    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 Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message