Comments scattered below... --- [EMAIL PROTECTED] wrote: > 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:
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. > <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. 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. Documentation for these "union"'s is currently at: http://wiki.cocoondev.org/Wiki.jsp?page=TimLarson It is all in CVS now so the patch mentioned is no longer required. I will be moving these docs into the normal locations soon, unless anyone beats me to it (hint: feel free to move/update the docs if you want it done sooner than I get around to it). Note there is a small bug in the "union" widget which causes other widgets to undergo validation early. I also hope to fix this soon. > 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). You could use the javascript binding, possibly combined with a little code in your flowscript to initially store the login name in a variable. > 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. > 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? Again a "union" may come in handy, or perhaps the "lenient" setting on the binding may do enough for this use case. > 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 believe just the specific widget, but this would be easy enough to test for yourself to be sure. > I hope some of you can answer the questions. All other comments on how to > handle this in Cocoon are welcome too. > > Thanks, Helma HTH, --Tim Larson __________________________________ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
