Customizing OpenPetra

Things to customize

support different languages (might need different layout as well)
use special names that are wellknown inside your organisation (eg. FAMILY vs HOUSEHOLD)
different layout for different Operating System environments (see problems with TableLayoutPanel on Mono)
add plugins for banks and other specific tasks (there is an interface that needs to be implemented)
add new database fields; this really needs to be thought through; it will probably be easier to add a generic field upstream to OpenPetra.org, and use it specifically in your organisation
customized navigation structure; disable modules, etc; same for screens, hide some fields etc
change behaviour; this could be quite tricky; does it need to be done on the server, on the client?

customize by configuration files, that are loaded each time when OpenPetra starts
- Advantages: easy to configure, to develop and test; quite transparent
- Disadvantages: deployment to each client (though this should work with patch management anyways)

customize by generating code with different parameters and/or yaml files
- Advantages: probably quite fast
- Disadvantages: quite a lot of code; each customized OpenPetra needs to be compiled separately

customize by using reflection: the client could pick up functionality from DLLs
- Advantages: quite easy to install plugins etc
- Disadvantages: perhaps the time for locating plugins could be too long? solution: cache dll mdsums, store extracted methods in config files etc