Cart
[Home] [By Thread] [By Date] [Recent Entries]
We can customize a stylesheet with global parameters, we can have XML config files to be loaded as part of a transformation, so when exactly is it that the onion-skin overriding stylesheet is attractive for customization and maintenance? Use case: We have often projects that transform XML valid against a certain complex schema into an XML valid against another potentially complex schema Often such schemata are extensible one way or another with customisations (compare it to XHTML1.1 eg.) The "customer" often is a big company with many departments or many customers are served with the same stylesheets So, the mapping is not always 100% clear and the source schema can be used in different flavors by the different departments or the result expectations differ: custom extensions overrule the generic mapping; optional attributes in the result may or may not be required,... I always aim for a generic base set of stylesheets allowing one stylesheet where all the customisations are brought together Customisations can be changed by department/customer I myself can safely maintain and update the generic set I usually have a main driver XSLT, and xsl:import most of the stylesheets in there, if I then xsl:include the customisation, the customisation will always win I think, already mentioned, DOCBOOK stylesheets are a good example of how it all could work Is the onion-skin mostly something we can use as a last resort if some unforeseen maintenance or customization need suddenly pops up, or is it often the most attractive approach to maintenance and customization from the beginning? Definitely not a last resort. Most of my stylesheets are designed from the start for extensibility and customisation. Bearing customisation in mind from the start, generally leads to stylesheets that are easier to extend and maintain Consider an optional attribute in the result schema that should get the value of an extension element (department namespace specific) from the source. I don't want the extension namespace to clutter my generic stylesheet. I then make a call for a named template where the attribute should go I put an empty named template definition in the same stylesheet so in general no attribute gets created In the customisation stylesheet, I put the same named template definition optionally, but with a specific mapping according to the departments wishes (it will win over the other definition) Consider I need to do that after I have rolled out to a number of departments/customers... The new (empty named template) and its caller have no effect on the code base (given naming is chosen carefully) So I can safely roll out a new version with this new customisation handle added I have stylesheets out there that have this technique on many different layers customisations for regional offices, then departments inside each regional office, or the specific XML editor used across different departments, or the same CMS shared between regional offices All works a charm to maintain I can guess these different layers would be the cause for the name "onion" And yes, small templates (and functions) are the key to make this happen I was by the way not surprised to see that this topic has raised so much traffic on this list... and some confusion as well. Having had to coach teams of experienced XSLT programmers in the past, architecting XSLT this way has often lead to discussion or misunderstanding, so I realised pretty soon that this is a dark area for a number of (even experienced) XSLT programmers.
|
