cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From H.vanderLin...@MI.unimaas.nl
Subject Woody definition questions
Date Thu, 01 Jan 2004 22:29:37 GMT
Hi,

I'm rewriting my current web application into a Cocoon version and I'm
trying to use Woody for data handling.
I see much similarities between what I defined and what's possible using
Woody. Before I invest a lot of time in Woody, I'd like to have some
questions answered.

Background: my application is using an OMG HDTF COAS server
(http://www.omg.org/technology/documents/formal/clinical_observation_access_
service.htm)

to retrieve/store data. The COAS specification only defines a structure, not
content. This structure can be nested, so XML is an ideal way of describing
it. In short, a structure can look like this:

<ObsData code="[name]">
	<ObsQualifiers>
		<ObsData code="[qualifiername]">
			<Value>someValue</Value>
		</ObsData>
		<ObsData code="[qualifiername]">
			<Value>someOtherValue</Value>
		</ObsData>
	</ObsQualifiers>
	<ObsData code="[subPart]">
		<Value>someValue</Value>
	</ObsData>
</ObsData>

In text: an ObsData structure contains an ObsQualifier section which holds 1
or more ObsData structures as well as either a Value or one or more ObsData
structures. A Value has a datatype attached. So a Value could look like:

<Value><TimeStamp>20040101T000000</TimeStamp><Value> or
<Value><CodedConcept><CodeSchema>LOINC</CodeSchema><Code>1346</Code></CodedC
oncept></Value>

Now, I realize I can transfer a Value to some datatype in Woody and do my
own validation for "datatypes" that Woody doesn't "natively" support. I can
also create aggregated widgets for all ObsData structures that hold one or
more ObsData structures.
I can't come up with a valid representation of the qualifiers though. They
should be handled differently than the actual data, e.g. one of the
qualifiers is "ResponsibleObserver", which should hold the name/code of the
person who made the actual observation/measurement etc. (in contrast to
"Author", the person actually entering the data). I want a user to enter
this only once and then copy it for all the actual ObsDataStructures. I want
to distinguish the qualifiers from the regular ObsData in a generic way, so
I can add qualifiers to the definition file without recoding any other part
of the application.

Let me explain what I currently have and how I intend to convert this to
Woody. Maybe some of you can give their opinion on this.

Currently                               -->  Woody
elements.xml =
Definition of elements and qualifiers   -->  elementsDef.xml (wd:widgets),
qualifiers????
and their datatype in the COAS server

formDef.xml =
Definition of a form/view that holds
the description of all elements and
qualifiers for a particular form 
(i.e. a subset of elements.xml          -->  formtemplate (wt:widgets),
qualifiers????

display.xsl	= XSL to transform formDef  -->  formtemplate with output
type widgets + XSL?
into an HTML page for reviewing

input.xsl = XSL to transform formDef    -->  formtemplate with input type
widgets + XSL?
into an HTML page with <FORM>

To be specific: I have 1 elements.xml, 11 (and counting) formDef.xml, 1
display.xsl and 1 input.xsl and a bunch of Java classes that create a
DOM-instance of formDef, manipulate it to copy the set of qualifiers into
the respective element, fill it with values from the COAS server and pass it
onto a JSP that applies the appropriate XSL file to put it on screen.


Questions:
1. how can I distinguish between qualifiers and datawidgets? I prefer
something other than manipulation of the name (I'd rather add an attribute
"qualifier" than prefix of suffix the name with e.g. "-qual-"). I also want
to display these qualifiers differently than the general elements.

2. some qualifiers are filled automatically, e.g. "Author" is automatically
filled with the user's login name. How do I do that with Woody? Is there a
way to define the "source" for autofilled items (e.g. "Author" is of type
"autofill" source="username", not modifiable by the user, but should be
stored).

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.


4. I think I've seen this question before, but I can't find it, so: can I
merge my elementsBind.xml with a data-XML that does not contain all items?
E.g. above files + element_data.xml holds only item3. When I use it with
form1.xml I want it to display the value of item3 and allow the addition of
item1. Is this possible?

5. Something in the Woody documentation is not clear: it is possible to add
'on-update set attribute changed=true' to a widget. Does this apply to only
that particular widget or does it apply to the entire set of widget on that
form? I.e. is the attribute added to the widget or to the form?

I hope some of you can answer the questions. All other comments on how to
handle this in Cocoon are welcome too.

Thanks, Helma

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


Mime
View raw message