cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Gianni <s.gia...@thebug.it>
Subject Dynamically activating/disabling/hiding and requiring fields
Date Fri, 17 Mar 2006 18:11:09 GMT
Hi all,
in cocoon forms is actually not so easy to implement dynamic change of 
widget state. It happens quite often to have a customer ask for things 
like "Phone number is required if they ask to be contacted by us, they 
don't provide an email address and they are from Italy, while email is 
required while phone number must be disabled if they are from outside 
from Italy", and other similar requirements. This can be implemented 
with value-changed-listeners, but this involves java/javascript 
knowledge and it's not trivial anyway, or with unions up to some level 
of complexity.

For a project i'm working on, we realized a quite simple and pluggable 
component (it's a form phase handler actually) which is configured with 
an xml syntax :

<when test='And(contactme, country != "it")'>
  <required>email</required>
  <disabled>phone, cellphone</disabled>
  <optional>fax</optional>
</when>

I find this system quite useful, and with patches from bugs COCOON-1781 
and COCOON-1685 it could be easily configured from inside the form 
definition. Also, conditions (like the when) and actions (like required, 
disabled etc..) can be implemented and plugged in as avalon components.

I'd like to contribute it, but there could be other solutions more 
integrated in cocoon forms :
- Make the required attribute of a field an Expression instead of a 
simple boolean, and also add the disabled attribute to make a field 
disable itself when the expression evaluates true. Pros are that we 
would not introduce another grammar and put the code inside every single 
field. Cons are that would produce code duplication (the same rule 
applied to many fields), it requires changing the cocoon form code, and 
would not be pluggable anymore (we currently developed other actions, 
like setNull, copyValue, and some others that would not be applicable to 
this model).
- Write some value changed listeners to make this common operation. It 
would not require forms code modification, but apart from this it would 
have the same cons and pros of the previous solution.

WDYT?

Simone

-- 
Simone Gianni

Mime
View raw message