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