Aren't you running into the situation where this will run crazy once there are more styling options or combinations thereof to be considered?
Bye, Helma > -----Original Message----- > From: Marc Portier [mailto:[EMAIL PROTECTED] > Sent: Wednesday, 12 May 2004 15:38 > To: [EMAIL PROTECTED] > Subject: [heads up] [cforms] fi:styling/@type="output" > ignored on widgets with datatype=date. > > > Recently there was a change to let date-widgets (ie widgets > with their > datatype set to 'date') automatically be styled with the > calendar-popup. > > best feature of it being that it automatically takes up the correct > pattern now > > consequence is that styling/@type='date' is no longer supported > > one of the (bad) side-effects was that date-widgets with > selectionlists > broke, for which there was a clever fix from Joerg: http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/forms/samples/resour ces/forms-calendar-styling.xsl?r1=1.5&r2=1.6&diff_format=h today I found a similar effect on the use of styling/@type='output' where the styling is completely ignored since the more specific matcher for the datatype-causes-calendar-styling takes precedence over the other basic-styling matchers (you can check this by e.g adding both of: <ft:widget id="birthdate"/> <ft:widget id="birthdate"> <fi:styling type="output" /> </ft:widget> to the [cforms]/samples/forms/form1_template.xml) after some testing, I'm tempted to extend the fix by Joerg to some <xsl:template match="fi:field[fi:datatype/@type='date'][not(fi:[EMAIL PROTECTED]'output'])][n ot(fi:selection-list)]"> to me this patch seems unharmful (and useful) enough to be added during the current codefreeze other opinions/suggestions? -marc= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
