cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: Wizard using CForms doesn't work?
Date Wed, 15 Sep 2004 20:56:10 GMT
Tim Larson wrote:

>On Wed, Sep 15, 2004 at 09:24:30PM +0200, Sylvain Wallez wrote:
>  
>
>>Tim Larson wrote:
>>    
>>
>>>On Wed, Sep 15, 2004 at 07:08:20PM +0200, Sylvain Wallez wrote:
>>>      
>>>
>>>>Stephan Coboos wrote:
>>>>        
>>>>
>>That's an additional problem, but even if this is solved, there's still 
>>the problem that form.showForm() doesn't exit is some fields are not 
>>valid (e.g. some who are displayed in a following screen).
>>    
>>
>
>True.
>
>  
>
>>>There are several different solutions:
>>>* Wrap each page in a struct widget and use the new methods I
>>>  recently added (e.g. setProcessRequests()) to control which
>>>  sets of widgets process their request parameters.  You can
>>>  call these methods from your flowsript or from event handlers.
>>>      
>>>
>>Can you elaborate on the use case that led you to add these new methods?
>>    
>>
>
>I am writing a type-aware gui xml editor using cforms, for editing
>sitemaps, xreports, cform models, bindings, and templates, etc.
>The content of the file being edited is stored in a recursive tree
>of widgets, and since this tree is often large it is convenient to
>be able to hide (fold) parts of it and also to display parts as
>compact read-only summaries.  Union's suffice for showing and
>hiding subtrees of widgets, but do not handle the display-read-only
>versus display-editable use case.
>  
>

Okay. Impressive use case :-)

>The only option was to have a mirror set of "output" widgets to
>correspond with the field, repeater, etc. widgets and use a union
>to switch between them, but this creates a *lot* of work to keep
>the output-only mirror set in sync with the editable set, plus
>there is no output-only equivalent of many widget types, such as
>multivaluefield, aggregatefield, repeater...
>
>So I decided to create another option, which has been discussed
>before but never finalized or coded, of allowing every widget to
>have an output-only mode.  You can separately control whether a
>widget processes its own request parameters and whether it allows
>the subtree of children under it to process their request
>parameters.  This separate control might still need some tweaking.
>Also, we might want to introduce some attributes to the model
>schema to set default values for these new settings.  Does this
>explanation help any?
>  
>

Sure it helps! So these new methods are actually a partial 
implementation of the "widget states" we discussed several times. Am I 
right? Could be time to finally implement all of them.

I don't see clearly though why there's a separate setting for a widget 
and its children subtree.

>>>* Wrap your form in a union widget and put the pages in struct
>>>  widgets as the cases of the union.  The unions in the model,
>>>  template, and (if you use one) binding controls which widgets
>>>  are displayed and which widgets process their request params.
>>>      
>>>
>>Mmmh... IMO, the union widget should be strict about the selected case, 
>>and should allow to access widgets other than the selected one.
>>    
>>
>
>Is this different from how the union works now?
>  
>

AFAICS, Union.getChild(id) doesn't check that the requested id equals 
the current value of the case widget. That means that you can get any of 
the possible cases even if it's not the currently selected one.

Sylvain

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


Mime
View raw message