cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: woody questions
Date Fri, 17 Oct 2003 05:50:52 GMT

Thanks for answering my questions.  I'll try to pick on someone else next 
time :-)


Sylvain Wallez <> wrote on 10/16/2003 
06:33:54 AM:

> Why me? A lot of people are using Woody and are up to speed on it, now.


> wrote:
> > 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.

Got it.

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

Cool, I may get to this first.

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

This seems like mixing concerns.  Model (validation) in with controller.
My "gut feeling" is that validation rules should be in form (model) 
markup.  But maybe that's because I'm obsessed with client side 
I need to think about this some more...

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

Uh, didn't quite get that.  But I'll look at your examples again and
see if I can figure out what you're talking about.

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

Good point.  Maybe server could pass some kind of a locale object (as DOM 
to browser with the page.  Then one would need to cast the date strings 
into an extended
javascript Date object which would support locale-independent validation. 
Same idea for 
quantities like currency.  Hmmm, but this would quickly get out of 
control-- too many
location dependent validation rules.  OK, back to the drawing board...

> Sylvain
> -- 
> Sylvain Wallez                                  Anyware Technologies
> { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
> Orixo, the opensource XML business alliance  -

View raw message