Hi, 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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Sent: Thursday, 01 January 2004 23:30 > To: [EMAIL PROTECTED] > 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 > (http://www.omg.org/technology/documents/formal/clinical_obser > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
