cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Danny Bols" <db...@osirion.be>
Subject RE: Woody - Determining the value for a widget
Date Fri, 21 Nov 2003 19:29:02 GMT
> From: Bruno Dumon [mailto:bruno@outerthought.org]
> Sent: vrijdag 21 november 2003 16:48
>
> On Thu, 2003-11-20 at 11:38, Danny Bols wrote:
> > If one wants to create a more dynamic user interface based on one single
> > woody form in which we give the user more control over the
> interaction it
> > would IMHO be bad design to put all the inivisble widgets on
> the request and
> > waste valuable processing time.
>
> The crucial part here is "based on one single woody form". Using
> multiple forms solves this, but your use case of hiding "detailed" stuff
> seems a good one (though even that could be solved by using two
> different forms, or putting the fields in a hidden div).
Operating in an environment with business critical data the crucial part is
indeed using only ONE form instance. In our case the "critical" business
data is loaded once into the form with the first request. During user(woody)
interaction we can not afford to take unwanted risks of synchronizing
multiple forms and templates and creating redundant data. A commit gives the
user the gurantee that the form data is written back in one single
transaction to avoid inconsistencies in the data store.

We don't use the technique of hidden fields or a hidden div because this
would lead to unnecessary processing (and risks of damaging critical data).
We simply put only those fields in a template which needs to be editable in
that step of the interaction.



> > Here are a few cases in which more dynamic user interfaces based on one
> > woody form are needed:
> > - switching between a "simple" and an "advanced" mode
> > - in case of a repeater switching between a "single row" and
> "multiple row"
> > mode
> > - a wizard-based interaction in which the user is guided step-by-step
> > through the different parts of a form
> >
> > We are using this kind of interaction by using different
> templates on the
> > same form which are tied together in flow script.
> >
> > See also my comments below.
> >
> > > -----Original Message-----
> > > From: news [mailto:news@sea.gmane.org]On Behalf Of Sylvain Wallez
> > > Sent: donderdag 20 november 2003 10:04
> > > To: users@cocoon.apache.org
> > > Subject: Re: Woody - Determining the value for a widget
> > >
> > >
> > > Danny Bols wrote:
> > >
> > > >Hello,
> > > >
> > > >it seems that if a field widget doesn't have a corresponding
> > > value in the request it's original value gets overidden with the
> > > null-value.
> > > >
> > > >Is this the way it should work or is it a slip of the pen in the
> > > Field.readFromRequest(formContext) method?
> > > >
> > > >
> > >
> > > The question is whether we should consider a missing request parameter
> > > (value == null) the same as an empty value (value = ""). Currently,
> > > they're considered to be equivalent and the field is
> therefore nullified.
> >
> > You are right, there is a big difference between a parameter
> which is not
> > available on the request and a parameter which has an empty
> value. So a +1
> > for processing them differently and for not overriding widgets
> with unwanted
> > null values.
>
> It's more complicated then this. While this may work for the default
> renditions of the field widget (though I'm not sure the HTML spec
> requires empty fields to be submitted), it is for example impossible to
> do this for checkboxes. As suggested on the -dev ML a while ago, this
> could be solved by adding hidden id + ".present" fields to the form
> (though I don't like that very much from the HTTP-interface
> perspective).
>
> This would also allow to detect if a composite widget is not present,
> i.e. if a repeater is not present at all, none of its child widgets
> would need to be further processed.
>
> Anyway, I'm -1 for any solution that would only work for certain types
> of widgets.

I agree with you. But the clue is NOT to use hidden fields! Why should we do
that? Since we have woody there is a form object which stores and cares
about al the form data. Just put only those fields in the template which
have to be editable during that particular step of the process. This is
about using the strengths of a FORM instance an not having to rely on a HTML
spec which was not really designed for this kind of interaction.
The basic principle is: ONE form object MULTIPLE templates/views.



> > > Now this is debatable, furthermore considering that I envisioned to
> > > distinguish these two cases to raise an exception when a null-valued
> > > required field is not present on the request (see
> > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24180).
> >
> > The case discussed in here is about giving a form-designer a
> test tool for
> > static (=simple?) forms (template wt: is equal to design wd:). I hope we
> > will not block the way for more dynamic templates / interaction.
> >
> > What do you think?
>
> I've got some more thinking to do on all this, but unfortunately my time
> to spend on this is quite limitted. But don't hesitate to share any
> further ideas on this.

Great to hear your comments! Petty of your time to spent though :-(
I am willing to share a bit of my valuable time on this when needed.

--
Danny


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message