You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by mr...@collegenet.com on 2003/10/15 22:07:43 UTC
woody questions
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
Re: woody questions
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Antonio Gallardo wrote:
>Hi:
>
>This is a nice discussion. Comments below....
>
>
>
>>>>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.
>>>
>>>
>>This seems like mixing concerns. Model (validation) in with controller.
>>
>>
>
>Not at all. The controller must do the validations if we need to build a
>"wizard-like" form. Who else can do that? I think woody is not a good
>candidate for the job since it is just the "view". Who manage multiples
>"views" the answer is the controller.
>
>
Exactly. And especially when the flow is not static, i.e. when the page
appearing when clicking "next" depends on what was input.
>>My "gut feeling" is that validation rules should be in form (model)
>>description markup. But maybe that's because I'm obsessed with client
>>side validation. I need to think about this some more...
>>
>>
>
>I think here are 3 levels of validations:
>
>1. client-side (with javascript client-side)
>Mainly to avoid a round trip to the server. This just saves user's time
>while filling a form and nothing more.The server never can trust in this
>type of validation of data. The user can "hack" the request and send you
>any data inside.
>
Yep.
>2. Woody model (using woody validators)
>You can not trust on the client-side validation. If we just support
>client-side validation then there is a security concern. What if the users
>just "hack the request". This is why woody must validate again what it
>gets from the users.
>
Yep again. First rule of the web application writer: never, never trust
the client. It's so easy to build a request. Never trust the values, and
never trust the parameter names. XMLForm fell in this second trap by
scanning the incoming request parameter names and considering them as
XPath expressions on the data model. Woody on the other hand uses its
server-side form model to define which request parameter to consider.
>3. Database (DDL - Data Definition Languaje)
>Here again altrough Woody (or other form framework) can do his best effort
>validating the user input, the database must also check what it get. i.e:
>You send to the user a combobox or a listbox to choose some values from
>there. Altrought the user again can "hack" to fool woody and the data
>continue to the database. Here is the lastest point when we need to check
>what we get.
>
This is what I call "application-level validation", which correlate form
values with other data out of range from the form. This can be e.g.
checking that an ID actually exists in the database. The event listener
stuff can do this to some extent, as a value-changed listener can call a
application-defined validation code and set a validation error on the
widget.
Note that in the particular case of the listbox, this is something that
can be handled by Woody itself. Currently, selection-lists are just
"hints" for the user, but no control is made that the incoming value is
in this list. A useful feature should be to distinguish open and closed
enumerations, i.e. if the list should be considered only as a help or as
a list of allowed values. We can then render open enumerations as a
combination of input+dropdown (combobox) and closed ones as what we have
today.
>I understand this is too much validation, but under this schema your
>application will be more secure and realiable. Also note the parts can be
>decoupled without problems.
>
Too much validation? I don't think so. It's just the way it should be,
and what we sometimes fail to do simply because the available tools make
it difficult.
>While I am writing, I also tought about the flow validation (as pointed
>above). I dont think flow is a good place to put validation in a database
>application since it must do the work of a controller and nothing more.
>
Well, maybe it's language abuse: by "flow validation", you must
understand "go back to the flow and from there call some
application-specific validation code". The flow should be limited to
glue code. It's a switchboard between the various components of the
applications, and allows them to stay strongly decoupled.
>What it means?
>
>Flow just must "get" the request from the user and decide to whom (View or
>Modell) it will send the request.
>
>That is my point of view. I am currently working under this schema and I
>hope it will work.
>
>I just wanted to share this ideas under this interesting topic. Please
>send your comments :-D
>
I think we all agree on the principles ;-)
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
Re: woody questions
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Hi:
This is a nice discussion. Comments below....
>> > 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.
>
> This seems like mixing concerns. Model (validation) in with controller.
Not at all. The controller must do the validations if we need to build a
"wizard-like" form. Who else can do that? I think woody is not a good
candidate for the job since it is just the "view". Who manage multiples
"views" the answer is the controller.
> My "gut feeling" is that validation rules should be in form (model)
> description markup. But maybe that's because I'm obsessed with client
> side validation. I need to think about this some more...
I think here are 3 levels of validations:
1. client-side (with javascript client-side)
Mainly to avoid a round trip to the server. This just saves user's time
while filling a form and nothing more.The server never can trust in this
type of validation of data. The user can "hack" the request and send you
any data inside.
2. Woody model (using woody validators)
You can not trust on the client-side validation. If we just support
client-side validation then there is a security concern. What if the users
just "hack the request". This is why woody must validate again what it
gets from the users.
3. Database (DDL - Data Definition Languaje)
Here again altrough Woody (or other form framework) can do his best effort
validating the user input, the database must also check what it get. i.e:
You send to the user a combobox or a listbox to choose some values from
there. Altrought the user again can "hack" to fool woody and the data
continue to the database. Here is the lastest point when we need to check
what we get.
I understand this is too much validation, but under this schema your
application will be more secure and realiable. Also note the parts can be
decoupled without problems.
While I am writing, I also tought about the flow validation (as pointed
above). I dont think flow is a good place to put validation in a database
application since it must do the work of a controller and nothing more.
What it means?
Flow just must "get" the request from the user and decide to whom (View or
Modell) it will send the request.
That is my point of view. I am currently working under this schema and I
hope it will work.
I just wanted to share this ideas under this interesting topic. Please
send your comments :-D
Best Regards,
Antonio Gallardo
Re: woody questions
Posted by mr...@collegenet.com.
Sylvain,
Thanks for answering my questions. I'll try to pick on someone else next
time :-)
--Michael
Sylvain Wallez <sy...@anyware-tech.com> 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.
Ghent.
> mratliff@collegenet.com 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
displays.
>
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.
>
OK
> > 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.
This seems like mixing concerns. Model (validation) in with controller.
My "gut feeling" is that validation rules should be in form (model)
description
markup. But maybe that's because I'm obsessed with client side
validation.
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
locale-independant.
>
Good point. Maybe server could pass some kind of a locale object (as DOM
tree-fragment)
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
> 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
>
>
Re: woody questions
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
mratliff@collegenet.com 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
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