Helma,
correct observation, and precisely what Joerg hinted on in his commit-message
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)
IIUC, you propose that fi:datatype has no influence on the chosen styling, but gives the format _when_ fi:styling/@type="date" is present, right?
Then a big +1000 !
Having the style driven by both the datatype and styling type will lead to an incredible combinational mess, which we just start to see with this conflict between @type="output" and fi: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.
- apply some @priority to the template (which always sounds a bit hacky to me)
-1 : what are the criteria to define the templates priority ? Also, it doesn't solve complicated combinations.
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)
If we agree that only fi:styling/@type drives the rendering type, then let's do it right now.
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
