Re: Wizard using CForms doesn't work?

[Sylvain Wallez]

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 }