- re-introduce fi:styling/type='date' to explicitely call the template, but now ignoring any possible formatting pattern (since we know it from the widget's datatype)
fi:styling/@type chooses the styling, which can then use some additional information such as fi:datatype to fine tune the widget's representation.
I remember that it was me who asked for simple datatype driven styling of date fields - and Bruno added the datatype feature in that way. Otherwise you always have to add styling/@type="date" to the template.
I understand this need, and that's why I'd like to allow <fi:styling> beside <fi:label> in a <fd:field>. Combined with widget repositories, this will allow definitions like this :
Yes, that's it!
I guess the datatype has no influence on fi:styling?
I depends: type="date" is obviously related to a date datatype.
To solve the current problem, we can consider than date styling is a "sub-styling" of the regular <fi:field> styling (that normally produces an <input>) implemented in forms-calendar-styling.xsl by means of something like :
<xsl:template match="fi:field[not(fi:styling/@type)]"> <xsl:choose> <xsl:when test="fi:[EMAIL PROTECTED]'date']"> ... calendar popup ... </xsl:when> <xsl:otherwise> <xsl:apply-imports/> </xsl:otherwise> </xsl:choose> </xsl:template>
OOP inheritance applied to XSLT!
I often already did it that way when refactoring the stylesheets.
How does it sound ?
Good! Add it before 2.1.5? I can do it in the evening.
Joerg
