Dynamically activating/disabling/hiding and requiring fields

[Simone Gianni <s....@thebug.it>]

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

Re: Dynamically activating/disabling/hiding and requiring fields

[Daniele Madama <d....@pronetics.it>]

> Ciao Daniele,
> I've implemented it, but it should be cleaned up, commented, and adapted
> to the cocoon source tree. It was just a proposal, I'll wait after the
> code freeze to propose it again.
>
> Which one of the possible solutions do you like?

All!

Conditionally-required and conditionally-state are common use cases, now I
use flowscript in the event-handler, but the xml-declaration is more clean
and not api-aware, so it result more easy for non-developer users.

Bye,
Daniele


-- 
Daniele Madama (http://www.danysoft.org)

Pro-netics S.r.l. (http://www.pronetics.it)

Re: Dynamically activating/disabling/hiding and requiring fields

[Simone Gianni <s....@thebug.it>]

Ciao Daniele,
I've implemented it, but it should be cleaned up, commented, and adapted 
to the cocoon source tree. It was just a proposal, I'll wait after the 
code freeze to propose it again.

Which one of the possible solutions do you like?

Simone

Daniele Madama wrote:

>Ciao Simone,
>I suppose that there's no time to add this nice features into the imminent
>2.1.9, but I think that this way of setting widget's state is very usefull
>(I need it now ;) ).
>Do you think to commit it after the release?
>
>TIA,
>
>  
>
-- 
Simone Gianni

Re: Dynamically activating/disabling/hiding and requiring fields

[Daniele Madama <d....@pronetics.it>]

Ciao Simone,
I suppose that there's no time to add this nice features into the imminent
2.1.9, but I think that this way of setting widget's state is very usefull
(I need it now ;) ).
Do you think to commit it after the release?

TIA,

-- 
Daniele Madama (http://www.danysoft.org)

Pro-netics S.r.l. (http://www.pronetics.it)