Random thoughts/wild guesses: Variables in XSLT can be set only once, so if you set the styling with the most preference in a variable, all others will be ignored. Or will this lead to exceptions?
How this should be implemented in the stylesheet is not yet clear to me. Bye, Helma > > the other alternatives (thx to clueful colleagues with > inspiration) are > > > > - 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) > > An explicite styling and additionally fi:datatype as it is > now would be > the most reliable solution IMO. The fi:styling/@type="date" > is the hint > for the calendar popup, while the fi:datatype is the hint how > to style > it (here: date pattern). > > > - apply some @priority to the template (which always sounds > a bit hacky > > to me) > > Maybe not hacky, but very risky as you encroach into the automatic > template priority calculation, not very reliable IMO. > > > I'm actually open to any suggestion here, > > > > The only opinions I might have are: > > - thinking this is beneficial to the upcoming 2.1.5 (others?) > > - considering the closing date on 2.1.5 we should be hinted > at doing > > this in the most safe way (which is a group consensus thing > probably, > > and might even lead to different proposals for now and after 2.1.5) > > +1 "most safe way" > > >> 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 > > +1 That's the "most safe way" for the moment - and the release - IMO. > Let's do the rest after the release. > > Joerg >
