Localizable Views

Revision as of 18:09, 28 April 2009 by Wickr (Talk | contribs) (Protected "Localizable Views" [edit=autoconfirmed:move=autoconfirmed])

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Revision as of 18:09, 28 April 2009 by Wickr (Talk | contribs) (Protected "Localizable Views" [edit=autoconfirmed:move=autoconfirmed])

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)


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