Cascading Fallback
From DLXS Documentation
Besmit (Talk | contribs)
(New page: ==Description== With fallback, if a file is required (e.g., XML, XSL, CSS, etc.), the system will look through all the fallback layers, starting with the most specific (e.g., the collectio...)
Newer edit →
Revision as of 13:49, 23 March 2011
Contents |
Description
With fallback, if a file is required (e.g., XML, XSL, CSS, etc.), the system will look through all the fallback layers, starting with the most specific (e.g., the collection) and ending with the least specific (generally, t/text and lib/). Once the file is found, it is used and the search terminates.
E.g., if looking for textclass.css, say a collection is the following fallback layers:
- /c/collid/ (no textclass.css)
- /g/groupid/textclass.css
- /a/anotherlayer1/textclass.css
- /a/anotherlayer2/ (no textclass.css)
- /t/text/textclass.css
Fallback will first search /c/collid/, which does not have the desired file. However, the next layer (g/groupid) has the file. This file is used, and the search stops.
The purpose of cascading fallback is to include all matching files in each fallback layer. So for the above example, /g/groupid/textclass.css, /a/anotherlayer1/textclass.css, and /t/text/textclass.css are all used. But they will be included in such a way that files from higher layers have higher precedence.
Note that this behavior can be accomplished in normal fallback by used import statements in CSS (or XSL, XML). However, with many levels, these import statements need to be updated, and there is a duplication of filesystem logic (the file exists on the filesystem AND you have to import it) that does not occur with cascading fallback. This prevents a range of potentially subtle bugs that become more likely when you use more fallback layers.
