Customizing OpenPetra

How other projects are making customization possible

• OpenERP:
  • http://open-net.ch/fre/Progiciel-OpenERP/Admin-guide-OpenERP/Customizing-OpenERP-objects
  • it seems the table is derived and the new field added
• Extending Adempiere: http://en.wikiversity.org/wiki/Extending_ADempiere
  • use general getter and setter from PO for custom columns
• Compiere
  • http://www.jorgjanke.com/2007/08/add-column.html

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?
• different workflows etc

General possibilities

• 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