roy huang wrote: >http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107792005324520&w=2 >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:http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107774469108519&w=2) > >Yes,content and display should separate ,but if just the content indicate display it >or not?The Cocoon Forms proposal contain <fd:choice> >(http://wiki.cocoondev.org/Wiki.jsp?page=WoodyScratchpad), 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 values. So, I propose the following changes to Cocoon forms: - add a state to widgets (enabled/disabled/hidden). - move to a generator approach. WDYT? Sylvain [1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108072698303323&w=2 [2] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107332516118153&w=2 -- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
