We need to make keeping project specific branches of Oyster that pull changes easier (possible even) via git's submodule. This should involve the following directory structure changes:
shared to _oyster
new _shared
Module/library loading and styles + xslcompiler will need to be modified to pull anything prefixed with _ in the top level directory. This gives us the flexibility of vendor prefixed packages and makes it more version control friendly with self contained modules/libraries/styles.
The style and XSL compiler changes will need to be a bit more thought out because there is only the one /styles/ that is web accessible which is currently the site specific style directory. The current plan of attack is extending the XSL compiler to deploy static resources such as JS/CSS from modules into either the site directory's styles.
Changes to loading config.pl will be required in lib/oyster/config/heavy.pm, both the cgi and fcgi launchers. Changes to loading modules should be confined to lib/module.pm but we will need to track the module's path for the XSL compiler. Most scripts will probably need to be updated for both of these.
We need to make keeping project specific branches of Oyster that pull changes easier (possible even) via git's submodule. This should involve the following directory structure changes:
Module/library loading and styles + xslcompiler will need to be modified to pull anything prefixed with _ in the top level directory. This gives us the flexibility of vendor prefixed packages and makes it more version control friendly with self contained modules/libraries/styles.
The style and XSL compiler changes will need to be a bit more thought out because there is only the one /styles/ that is web accessible which is currently the site specific style directory. The current plan of attack is extending the XSL compiler to deploy static resources such as JS/CSS from modules into either the site directory's styles.
Changes to loading config.pl will be required in lib/oyster/config/heavy.pm, both the cgi and fcgi launchers. Changes to loading modules should be confined to lib/module.pm but we will need to track the module's path for the XSL compiler. Most scripts will probably need to be updated for both of these.