disabling widgets

[Jeremy Quinn <je...@media.demon.co.uk>]

Hi All

I have a booleanfield widget, that needs to be disabled under certain 
conditions.

pseudo-code :

	if ( album.scenarios.size() > 0 ) {
		 disable ( album.publishable );
	}

ie. the album.publishable value needs to be in the form, but should not 
be alterable by the user.

Is there a way of doing this in Cocoon Forms ?


thanks for any suggestions

regards Jeremy

RE: disabling widgets

[Antonio Gallardo <ag...@agssa.net>]

Reinhard Poetz dijo:
> From: Antonio Gallardo
>> Based on some observation while no-tech oriented users filled
>> HTML forms. It makes clear to me that they don't liked the
>> round-trip to the server. It was confusing to him! It is
>> clear a non-conventional interface. Also it waste time, no
>> matter how fast the connection (including the server) are.
>> The observation was related to calculated widgets.
>
> I made similar observations too. This means to me that we have to offer
> a clear client-side Javascript interface in order to control the
> widgets.

This is why I think it would be fine to create a XUL interface reference
for CForms. I am sure XUL can help more than HTML. I know the problem with
XUL is that it currently only works in Mozilla and this is not a good idea
in public Internet webapp. But in Intranets webapp we can have control of
the clients too. ;-)

I will do it a try.

Best Regards,

Antonio Gallardo.

Re: disabling widgets

[Sylvain Wallez <sy...@apache.org>]

Antonio Gallardo wrote:

>Reinhard Poetz dijo:
>  
>
>>Sorry, I don't like this client-side approach.
>>We have to find something better because sometimes the 'presentation
>>state' of a widget can depend on the 'application state'. Flowscript as
>>controller should have access to both.
>>    
>>
>
>Hi Reinhard:
>
>How manage a dynamic "show/hide a control" in a page without doing a
>round-trip to the server?
>
>Based on some observation while no-tech oriented users filled HTML forms.
>It makes clear to me that they don't liked the round-trip to the server.
>It was confusing to him! It is clear a non-conventional interface. Also it
>waste time, no matter how fast the connection (including the server) are.
>The observation was related to calculated widgets.
>
>I think this is a similar case, because the show/hide control is just a
>rendering page issue. Of course, you can add add additional parameters to
>reflect the current "application state" and let the page have the right
>behavior. If we suspect that it can be a security concerns, there is a
>gold rule:
>
>"Anything returned from the client must the checked again, when the
>control return to the Flow (serversided)."
>  
>

(jumping in late) I don't think it's *only* a rendering issue.

A colleague of mine recently asked me how to change widgets availability 
in a form depending on the user's role or application state such as when 
a form goes through different people and/or states in a workflow.

The purpose here isn't dynamic interaction within an interaction with a 
single user, but allow to "configure" the form before it is displayed to 
the user.

I came to 3 possible states for a widget:
- enabled: what we have today
- disabled: the widget behaves like an output and it doesn't read its 
value from the request (solves the "Anything returned..." below).
- hidden: the widget doesn't display itself.

A disabled composite widget (e.g. a repeater) doesn't call 
readFromRequest() on its children. Similarily, the woody transformer 
should take into account hidden composite widget references (e.g. 
<wt:repeater-widget> by ignoring their content.

WDYT?

Sylvain (first post from my Mac!!)

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

RE: disabling widgets

[Antonio Gallardo <ag...@agssa.net>]

Reinhard Poetz dijo:
> Sorry, I don't like this client-side approach.
> We have to find something better because sometimes the 'presentation
> state' of a widget can depend on the 'application state'. Flowscript as
> controller should have access to both.

Hi Reinhard:

How manage a dynamic "show/hide a control" in a page without doing a
round-trip to the server?

Based on some observation while no-tech oriented users filled HTML forms.
It makes clear to me that they don't liked the round-trip to the server.
It was confusing to him! It is clear a non-conventional interface. Also it
waste time, no matter how fast the connection (including the server) are.
The observation was related to calculated widgets.

I think this is a similar case, because the show/hide control is just a
rendering page issue. Of course, you can add add additional parameters to
reflect the current "application state" and let the page have the right
behavior. If we suspect that it can be a security concerns, there is a
gold rule:

"Anything returned from the client must the checked again, when the
control return to the Flow (serversided)."

Best Regards,

Antonio Gallardo.

P.S: I like this kind of discussion, because I will learn more! :-)

Re: disabling widgets

[Antonio Gallardo <ag...@agssa.net>]

Jeremy Quinn dijo:
> I have a booleanfield widget, that needs to be disabled under certain
> conditions.
>
> pseudo-code :
>
> 	if ( album.scenarios.size() > 0 ) {
> 		 disable ( album.publishable );
> 	}
>
> ie. the album.publishable value needs to be in the form, but should not
> be alterable by the user.
>
> Is there a way of doing this in Cocoon Forms ?

Hi Jeremy:

In short, no. Also a roundtrip to the server to do this is not the best
idea. I think the problem is similar as when we needed to make some
"calculated widgets". We solved the problem in this way:

1-call a JS function in the OnLoad event of your page to initializate any
state of the controlled widget.
2-Add a onChange event on "album.scenarios" that will check for size and
turn on of off the "album.publishable" control. The JS code can be quite
similar to this code:

function toggleControl(id) {
    var element = document.getElementById(id);
    with (element.style) {
        if (display == "none") {
            display = ""
        } else{
            display = "none"
        }
    }
}

AFAIK, you will need to change the woody.xslt to allow the usage of OnLoad
event in the <body> of your HTML page.

As a example in the template I wrote:

<document menu="true" js="activity/client.js" onload="atStart();"
  ...
  <td>
    <wt:widget id="pcd_quantity">
      <wi:styling size="10" OnChange="calculateTheOtherWidget(this);"/>
    </wt:widget>
  </td>
  ...
</document>

BTW, because using clientside JS is very easy when we have id's on every
widget. I suggested to include id's even when rendering the <wd:output>,
but seems like nobody want it and proposal was forgotten. :-(

Hope this help.

Best Regards,

Antonio Gallardo

Re: disabling widgets

[Antonio Gallardo <ag...@agssa.net>]

Jeremy Quinn dijo:
> Hi All
>
> I have a booleanfield widget, that needs to be disabled under certain
> conditions.
>
> pseudo-code :
>
> 	if ( album.scenarios.size() > 0 ) {
> 		 disable ( album.publishable );
> 	}
>
> ie. the album.publishable value needs to be in the form, but should not
> be alterable by the user.
>
> Is there a way of doing this in Cocoon Forms ?

Another approach (not tested by me, but maybe works) is using the
JXTemplateGenerator. There is a <jx:if> tag that can be use to show/hide
controls in the rendered page.

Best Regards,

Antonio Gallardo