cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: disabling widgets
Date Mon, 05 Apr 2004 11:28:42 GMT
roy huang wrote:

>In this link,Sylvain suggest 3 states for a widget,I think it's a good idea.
>Today I want to hide an action under some condition ,but I just can't if I don't modify
the forms-field-styling.xsl.
>I use a transformer to generate different cocoon form define under different condition,but
the widget is always there(type may be different).So in style xml I can always use widget
like that:
>    <ft:widget id="edit">    
>    </ft:widget>  
>But if I remove the widget from the form define file,display will generate an error about
'Widget with id "***" does not exist in the form container'.I thought an afternoon and believe
I must modify forms-field-styling.xsl to do the job,but I don't like this method.(see also:
>Yes,content and display should separate ,but if just the content indicate display it or
not?The Cocoon Forms proposal contain <fd:choice> (,
I think this proposal is similar to what I am doing now.So if the inline widget doesn't exist
and displaytemplate use it ,it will generate the same error.
>Solution suggestion:
>1.Do not generate error if a widget not exist ,just not render or ignore it.Of course
,this can turn on and off by parameter.

I don't like this, as it makes finding typo errors very difficult. The
view must be strict about widget identifiers.

>2.Sylvain's suggest,3 states for a widget.this state is an attribute of a widget define,we
can modify it by flow or own transformer.

Yes, this state would be an attribute of the widget, that can be
modified by the flow and event handlers, but not by the transformer. The
transformer should be able to react on the widget's state (i.e. ignore
it if it's in hidden state), but, being part of the view, should not
modify the form's state. This is the role of the controller.

Now, as I mentioned already [1], I started using the generator approach
to form templates, using the implementation of "wt:" statements using
JXMacro provided by Chris [2]. And this approach is very powerful, as it
allows complex conditional form layout without requiring the
introduction of yet-another-control-structure-markup in the "wt:" namespace.

Introducing the widget states would allow these conditions to be
computed with the form's own state rather than using some separate flow

So, I propose the following changes to Cocoon forms:
- add a state to widgets (enabled/disabled/hidden).
- move to a generator approach.



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

View raw message