cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Larson <>
Subject RE: Woody definition questions
Date Tue, 06 Jan 2004 18:30:10 GMT
--- wrote:
> Hmm. I think I do, I'm just going to think of an example to check if we mean
> the same thing (and I want it to be a rather complex, real world example).

A clear (this is relative, because I may be the one with the fuzzy head),
complex example would be appreciated.  While the form model GUI example will
eventually be useful (when the save binding is made to work properly), it
is too conceptually recursive (it uses a form to edit a form...) to be a good
explaining or teaching example.

> Ok. First I must say I have to abandon the idea "one template for input and
> display" because both might be totally different in layout. As an example: a
> physiotherapist has to enter data of a test, so I present a form like this:
> subtest 1: ____
> subtest 2: ____
> subtest 3: ____
> you know the routine.
> The only interesting way to review this is presenting all tests as columns
> so the progress can be seen:
>          date1   date2   date3
> subtest1   X       Y       Z
> subtest2   a       b       c
> subtest3   1       2       3
> So there is no way these two forms can be defined in one template without
> making the template overly complex. Besides, I don't want to build a
> pipeline for each form. In fact the only pipelines I want to build are those
> that respond to actions (e.g. "new form", "edit form", "show overview") and
> maybe I can even combine some of them.

With this particular example, I agree you should use separate templates, and
probably just go ahead and make completely separate forms (bindings, models,
and templates).  The requirements vary greatly, such as one needs validation,
while the other does not, and one does not need a repeater, while the other
> > You may want to follow or contribute to the discussion on the 
> > developer list.
> > Class/New, Struct, and Union are all currently being 
> > discussed to improve
> > their designs and find better names for the concepts.  Here 
> > is a searchable
> > live archive:
> Ok. I'll have a look. I don't know if I can contribute. To stay in my
> domain: I feel like the patient who is telling the doctor what to do to cure
> him. :-)

Even in medicine, they are now telling patients to be a lot more
proactive in order to ensure better/more accurate care.  The more
we understand your symptoms (requirements) the better treatments
we can develop.

> > > No, maybe that didn't come across. If you take the drug 
> > administration
> > > example above "item1" could be described as:
> > > <element name="someDrug">
> > > 	<element name="dosis">
> > > 		<value>3mg/3timesPerDay</value>
> > > 	</element>
> > > 	<element name="DateTimeOfAdministration">
> > > 		<value>20040101T120000</value>
> > > 	</element>
> > > </element>
> > > 
> > > The nurse form could show this element as:
> > > <wd:booleanfield id="someDrugID">
> > > 	<wd:label>SomeDrug, 3mg (3 times a day)</wd:label>
> > > </wd:booleanfield>
> > > 
> > > And a separate date field that is copied into the timestamp 
> > part of all
> > > checked off drugs.
> > > 
> > > While the doctors form shows this element as:
> > > 
> > > <wd:widget id="someDrugID-dosis">
> > > 	<wd:label>Dosis of SomeDrug</wd:label>
> > > 	<wd:datatype base="string">
> > > 		<something else that can verify the dosis notation/>
> > > 	</wd:datatype>
> > > </wd:widget>
> > > <wd:widget id="someDrugID-timestamp">
> > > 	<wd:label>Date/time of administration of SomeDrug</wd:label>
> > > 	<wd:datatype base="date/>
> > > </wd:widget>
> > > 
> > > 
> > > BTW would I need a struct or something to keep them 
> > together? It would be
> > > nice to specify only one "id" for both widgets. It is not 
> > an aggregation,
> > > because I don't want everything entered in one <input/> and 
> > it's also not a
> > > repeater, because I want only one of them (at least in this case).
> > What do you mean by "keep them together"?  Which widgets do 
> > you mean when
> > you say "both widgets"?  Since I still do not seem to 
> If you look closely at the element you see 2 sub elements, i.e. 2 values for
> one data-item. If you look at the widgets you see they refer to different
> ids. What I'd like to do is have one widget that refers to "someDrug" but
> display on screen as two input boxes. And I can do a validation that either
> both have to present or none at all.

Starting to understand.  If the "2 values for one data-item" only shows up
once in a form, then I would just go ahead and create two widgets to represent
it.  If the pattern shows up multiple times in the form, then you could define
a class:
<wd:class id="some-id">
  <wd:widget id="first-id".../>
  <wd:widget id="second-id".../>
And then use <wd:new id="some-id"/> everywhere it is needed to insert pairs
of widgets that match this prototype.  For convenience, you would probably
also define a <wb:class/> for the binding and a <wt:class/> for the template
and use them in the same pattern to match up with the widgets in the form
model.  This way, for example, you could reuse the template for displaying
this pair of widgets by simply inserting a <wt:new id="some-template-id"/>
whereevery it is needed.

> > understand, I do not know if this will help, but did you know that
> > you can use multiple bindings to either bind a single back end value
> > to multiple widgets?
> This _I_ don't understand. :-) Could you give an example?

Thinking about this more, I do not think it matches your needs, but I
will explain it anyway.

The binding and the formmodel are *not* forced to be 1-to-1 (one binding
loads and saves one widget).  This is just the norm for most use cases.
If you use case requires it, you could supply one <wb:value.../> binding
that loads a value into one widget, and supply a second <wb:value.../>
binding that loads the same value (from the same source) into a second
  <wb:value id="first-widget" path="some-path"/>
  <wb:value id="second-widget" path="some-path"/>
To prevent a race condition when saving, you could either mark one of the
bindings with 'direction="load"' (so it does not attempt to save), or you
wrap the bindings (and widget definitions) with a union binding (or union
widget, respectively) which would cause only the binding for one union
case to load and save, while not performing the other binding.

> Well, I usually do that too, but this time it didn't work. From another post
> on this list I think the problem lies in the fact that I don't have a
> "required=true" widget. The only validation I need it that at least one
> widget has to be entered, but not one specific one.
> I'll have a look into this.

I did not explain clearly enough.  You do *not* need a widget marked with
required="true" for validation to work.  What I meant to explain was that
if you happen to have any widgets which are already marked required,
*then* you must remember to put all of these required widgets in your
template.  Even one widget that is marked required, but is missing from
the template, will prevent your form from ever validating successfully.

--Tim Larson

Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message