Bruno Dumon wrote:


<fd:datatype base="integer" >
<fd:convertor type="plain" variant="integer" />

the variant attribute here has no purpose, the plain convertor does not
need any further configuration. The variant attribute is specific to the
formatting convertor. Again, does no harm if it is there (but can
confuse).
I suspected it didn't, but those snippets I posted came from the end of a whole lot of testing, trying all the variations I could think of.


Is this expected, or is it a bug? What is the recommended
implementation for this?

This is expected behaviour. The type of the objects in the selection
list should match the datatype of the widget. The only reason you got so
far is that the plain integer convertor doesn't try to cast the object
to an Integer (nor does the flow jxpath selection list implementation
check the type of the objects in the list). So yes, you need to use the
java types.
Ahh, thanks for that answer. It clears things up for me.

Perhaps I might suggest a change to the forms documentation to explain that cocoon forms expect java variables, not javascript ones. I suspect it is common to use flowscript and forms together, and unless you are aware that you need to be vigilant to avoid it, putting javascript variables into the form data could easily occur with unexpected results. The fact that they "mostly" work just makes it more confusing when they don't.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]