cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Larson <>
Subject Re: Wizard using CForms doesn't work?
Date Wed, 15 Sep 2004 20:20:24 GMT
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).


> >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.

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?

> > * 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?

--Tim Larson

View raw message