cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Woody definition questions - additional question
Date Thu, 01 Jan 2004 23:49:32 GMT

After rethinking about this long post and trying to use Woody for what I
think is possible, I wondered how to use Woody when I want a transposed
table, i.e. a "record" is a column rather than a row. Is this a mere matter
of XSL transformation? If so, how do I make a difference between a row-based
repeater and a column-based repeater? Or do I need to add my own attribute
to the widget definition/template and process this in my XSL file?

Bye, Helma

> -----Original Message-----
> From: 
> [] 
> Sent: Thursday, 01 January 2004 23:30
> To:
> Subject: Woody definition questions 
> 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
> (
> vation_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:
> For additional commands, e-mail:

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

View raw message