Hi,
> The "union" does not help distinguish. You would use a normal widget
> binding (probably the javascript binding) to distinguish what you are
> dealing with and to load a value representing the decision into an
> "output" widget. "union" bindings, widgets, or templates could then
> react to this value (by referencing the widget in the union's "case"
> attribute) to control which of the unions' sub-bindings are performed,
> which sub-widgets are present, and/or which templates are used,
> respectively. Is this any clearer?
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).
> > Maybe I should abandon the idea that I can
> > use one template for both input and display, because (as
> stated above) I
> > don't want to display qualifiers when the user can input data.
>
> With the technique described above, you would not have to abandon this
> idea. If you find the current interface or implementation to ackward
> or limiting then let us know if you have any suggestions on
> what you need
> or how to fix/improve Woody to support you needs.
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.
> 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: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&r=1&w=2
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. :-)
> > 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.
> 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?
> Have you made any progress on validation since we talked
> last? Did you
Not yet. I had to do completely different things.
> try the debugging technique of starting with the simplest form you can
> get to work correctly (e.g. trim down one of the samples) and
> then adding
> what your real form includes just a little at a time until it
> stops working?
> I narrow down and solve a lot of my problems this way.
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.
Thanks and bye, Helma
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
