Difference between revisions of "Localizable Views"
m |
(links out) |
||
| Line 10: | Line 10: | ||
== Specific example: XSLT == | == Specific example: XSLT == | ||
| − | If your views are in XSLT, the XSLT 'import' function provides a convenient method to allow over-riding of XSLT for localization. | + | If your views are in [[XSLT]], the XSLT 'import' function provides a convenient method to allow over-riding of XSLT for localization. |
Put your XSLT that is distributed with the application in one directory or directory tree. | Put your XSLT that is distributed with the application in one directory or directory tree. | ||
Revision as of 18:35, 25 February 2009
There needs to be a way for local implementers to customize the 'templates' or 'views' to have, at a minimum, their own branding, without actually editing shared distribution code. Ideally, they should be able to customize as much as possible of the templates/views.
Localized templates/views should probably live in different directories than distributed templates/views, for ease of local source control.
There are a variety of ways to accomplish this, depending on environment.
Specific example: XSLT
If your views are in XSLT, the XSLT 'import' function provides a convenient method to allow over-riding of XSLT for localization.
Put your XSLT that is distributed with the application in one directory or directory tree.
Have another separate directory tree for local XSLT "overrides".
When your application loads an XSLT file, it can first check to see if an XSLT file with the same name/pat exists in the 'local' directory. If so, it can combine the 'distribution' and the 'local' version of that XSLT file can be combined together using XSLT 'import' statement, so that any templates or variables in the 'local' version will override the distribution version.
Application Example: Xerxes
