cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: disabling widgets
Date Fri, 27 Feb 2004 22:14:07 GMT
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.


Sylvain (first post from my Mac!!)

Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message