cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira>
Subject Re: Woody definition questions - additional question
Date Fri, 02 Jan 2004 10:00:16 GMT
I believe Tim Larson committed a change to the woody-page-styling.xsl 
for just that recently. To quote:

tim         2003/12/31 13:45:20

  Modified:    src/blocks/woody/samples/resources woody-page-styling.xsl
  Got tired of hand-coding tables, so
  expanded group layout count to four:
    columns - columns with label left and input right
    column  - column with label above and input below (new)
    rows    - rows with label above and input below (new)
    row     - row with label left and input right (new)

Regards, Upayavira wrote:

>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-----
>>Sent: Thursday, 01 January 2004 23:30
>>Subject: Woody definition questions 
>>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
>>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>
>>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
>>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 
>>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 
>>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.
>>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 
>>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
>>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
>>Form1.xml defines widget1, widget3
>>Form2.xml defines widget1, widget2, widget4
>>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:

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

View raw message