Difference between revisions of "Localizable Views"
(New page: 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...)
Revision as of 20:35, 2 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. T
here 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