Return-Path: 
 <users-return-60530-apmail-cocoon-users-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-users-archive@www.apache.org
Received: (qmail 32945 invoked from network); 2 Jan 2004 23:29:40 -0000
Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12)
  by minotaur-2.apache.org with SMTP; 2 Jan 2004 23:29:40 -0000
Received: (qmail 82033 invoked by uid 500); 2 Jan 2004 23:29:18 -0000
Delivered-To: apmail-cocoon-users-archive@cocoon.apache.org
Received: (qmail 82012 invoked by uid 500); 2 Jan 2004 23:29:17 -0000
Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:users-help@cocoon.apache.org>
list-unsubscribe: <mailto:users-unsubscribe@cocoon.apache.org>
list-post: <mailto:users@cocoon.apache.org>
Reply-To: users@cocoon.apache.org
Delivered-To: mailing list users@cocoon.apache.org
Received: (qmail 81995 invoked from network); 2 Jan 2004 23:29:17 -0000
Received: from unknown (HELO um0004.unimaas.nl) (137.120.1.4)
  by daedalus.apache.org with SMTP; 2 Jan 2004 23:29:17 -0000
Received: from mail001.unimaas.nl (mail001.unimaas.nl [137.120.1.31])
	by um0004.unimaas.nl (Postfix) with ESMTP id ED5B851478
	for <users@cocoon.apache.org>; Sat,  3 Jan 2004 00:29:23 +0100 (CET)
Received: by mail001.unimaas.nl with Internet Mail Service (5.5.2657.72)
	id <YYNQDCQ1>; Sat, 3 Jan 2004 00:29:23 +0100
Message-ID: <E37F8F79E39C0943A8E2846F1C4EA9F207A4ABAA@mail003.unimaas.nl>
From: H.vanderLinden@MI.unimaas.nl
To: users@cocoon.apache.org
Subject: RE: Woody definition questions 
Date: Sat, 3 Jan 2004 00:29:22 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

Hi Tim and Upayavira,

Thanks for commenting. 

> Look at the new "Form Model GUI" woody sample form in CVS to see how
> to deal with nested (or recursive) data with varying nesting depth.
> Note that the sample form's save binding is not completed/correct yet.

I'll have a more thorough look again, to find out what you mean. My first
impression was that it was a mere showcase for the various widgets. 

Maybe I'm mixing screen representation issues with data model issues or
maybe I'm still thinking too much in the same way I wrote my current
version. Ok, let me go a bit more into the details. Hopefully you can
comment (tell me where I go wrong in my thinking and/or give ideas how to
solve it with Woody).

Currently I have an elements.xml file that describes all qualifiers I use
and all elements (consider an element a key/value pair). All qualifiers and
elements have a name and a datatype and, if relevant, a format (e.g. a date)
with which they are stored in the database. Although the qualifiers are
specified only once, each element that is stored contains all qualifiers
with their current value. 
A set of elements are combined into a form, that currently represents a
paper-based form. A form is defined in a formXXX.xml file, where all the
qualifiers and elements that occur in that form are described. Each element
has a label and a display type. I distinguish between display (simple HTML)
and input (an HTML form). A form instance is also stored for audit trail. It
holds its own set of qualifiers as well as references to the specific ID of
the element.

When displaying an instance of such a form qualifiers are represented
differently from the elements and the qualifiers of the elements are
displayed as well. When I need to add/modify a form the qualifiers that need
user input are only displayed at the top and will be copied to the elements
by code.

A form, in my current version, doubles as a view, so an element can appear
in multiple forms and it could be displayed differently.

Example: when a drug is administered this could be entered on a form that
has a list of all the medications of a patient and the nurse enters a
timestamp and a checks off that particular drug. So this is a list of
checkboxes and a date field. A similar form for the doctor allows entry of
date and dosis. In both cases the same information is stored/retrieved from
the database, but displayed/entered in a different way.

> Would the (server-side) javascript binding help with distinguishing
> or handling the qualifiers?  If you can somehow get a widget to hold
> a value that indicates that a qualifier is present, then a "union"
> widget could use that value to allow different widgets to be present,
> if that is what you need.  A "union" binding would also be required
> to allow the data to be bound to the different widets, and a "union"
> template would be needed to display the output differently for the
> different cases.

I understand what a union is, but I don't see how it can help to distinguish
between qualifiers and elements. 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.
I was just hoping that with Woody I could rid myself of the tedious DOM
manipulation I'm doing now to figure out which element is changed or added
or deleted and to get all the qualifiers copied to the respective elements.
I was also hoping that with Woody I could add qualifiers to a general
definition file and have it properly handled without modifying the code
(whether it is javascript or java or whatever).

> You could use the javascript binding, possibly combined with a
> little code in your flowscript to initially store the login name
> in a variable.

Ok. Clear.

> > 3. if I use the same names in the template widgets in all 
> forms, can I build
> > only one binding file for all elements? Example:
> > 
> > elements.xml defines item1, item2, item3, item4
> > elementsBind.xml defines widget1=item1, widget2=item2, widget3=item3
> > widget4=item4
> > Form1.xml defines widget1, widget3
> > Form2.xml defines widget1, widget2, widget4
> > Etc.
> > 
> > Widget1 could be something different in form1 and in form2.
> 
> I do not quite understand your example, but let me give it a
> try anyway.  If the layout of widgets is the same in these
> different forms, then yes, your sitemap could reference the
> same binding definition file for use with all of these forms.

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

> Again a "union" may come in handy, or perhaps the "lenient"
> setting on the binding may do enough for this use case.

Hmm, I think "lenient" rings a bell.

> I believe just the specific widget, but this would be easy
> enough to test for yourself to be sure.

Right now I can't get my form to validate anything, so there is not much to
test. :-)

Thanks and bye, Helma

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