SVNStructure
From AigaionWiki
Contents |
Structure
Note that this structure is not yet completely implemented in SVN! The extensions and internationalisation directories are there, but the aigaion2 top level directory, and the separate web content directory, are not yet added, because this also has some implications for internal configuration of Aigaion (where to find icons and style sheets etc)
The whole SVN repository:
top/
The material that is actually needed for installing and running an instance of Aigaion:
/aigaion2/
/index.php (will be generated by install script)
/attachments/ (can be moved out of the webroot)
/webcontent/ (must remain somewhere in the webroot)
/aigaionengine/ (can be moved out of the webroot)
/codeigniter/ (can be moved out of the webroot)
/install/ (the install scripts)
The directory with all material needed for the translation process:
/internationalisation/
/_README.txt
/messages.pot (template of all messages of the SVN version)
/de/ (German translations of SVN version)
/nl/
/etc/
/Aigaion2.1.2/ (Translations of Aigaion release 2.1.2)
Development files: examples for login integration, examples for embedding, etc
/extensions/
/plugintegration/
/embeddingexamples/
/logintegrationexamples/
Requirements
(Or: why this structure?)
The Aigaion code will remain in one single SVN. It should be possible for a user to simply take the SVN as it is, place it in the webroot and have Aigaion function like that. In that situation, updating Aigaion should remain a matter of one single SVN call.
[PDM] Agreed - but what is the motivation for the aigaion2 subdirectory?
[DR] to have one top level directory under which all content resides that makes up a 'normal' default installation of Aigaion (i.e. all other top level directories can be thrown away without consequences).
[PDM] OK, so most users will only need to download and update aigaion2
[DR] True
[PDM] perhaps aigaion2, development and internationalisation should then each be a separate SVN repository?
[DR] Possibly. But that is not extremely important. Also, I do not think sourceforge allows us more than one repository.
Engine vs web content
The *engine* should be separated from *web content* (icons, css files, javascript) to allow placing the engine code outside of the webroot.
[DR] NB: this may lead to open_basedir warnings. If we do this, add an entry to the FAQ about this!.
Different bibliographies on the same server should presumably use the same javascript, but might need different (default and custom) themes. If one bibliography belongs to a project and has themes specifically styled for that project, it makes little sense to make these themes available to the other bibliographies. One solution (A) would be to make the theme-dir configurable; another (B) to add a setting in index.php to restrict which themes are available ('empty means all themes in the theme-dir can be used').
[DR] I prefer solution B
[PDM] I'd rather minimise the need for admins to edit those index.php files. Each bib on the same server will presumably still need its own directory to contain its index.php file; so why not look for a themes sub-directory there, containing any project-specific themes? The shared themes could stay together with the rest of the shared web content. This might avoid the need for settings altogether.
[DR] that is a good idea. In fact, such an index.php setting would always get a default value (for fallback if the admin did not adapt index.php); this default value could be just what you suggest. Just like with the supported_languages setting: if you don't specify it, you simply get the default set of languages.
Translation process
The process of translating Aigaion versions into new languages should occur outside of the core Aigaion directories. Only the coordinator for a language is supposed to place (completed) translation files into aigaionengine/language/locale/...
Therefore, the translation processes are coordinated in a top level directory called 'internationalisation'. The finished compiled files for specific languages are placed in the Aigaion engine directories.
Integration examples
Development files, embedding examples, example plugins, etc, should be collected in a separate top level folder, as these are essentially irrelevant to normal, default operation of Aigaion
...
...