1. Customise the core product
2. Handle multiple languages
3. Compile scripts and styles
4. Abstract data by type
One of the issues when developing a framework is the wide variation in business processes among the clients who’ll use that framework. We have some clients with a single type of funding application, others with more than a dozen. Some have intricate cascading approval processes, others a simple stop/go decision point. From experience, it’s not possible to foresee all the variations when designing the initial framework, so a level of customisation will always be necessary.
We initially developed the framework for organisations offering contestable funding, and called it the ElseApps Funding Framework, but once it was in service it became clear there were many other uses for the core functionality.
Early on we adopted a simple structure that has enabled us to deliver customisations for all types of clients easily and robustly. We have a core product that we always deploy unchanged – every instance of EAF has an identical core. But we have a parallel structure for customisations. And at run time, a customisation always trumps the core: this makes it very simple to implement customisations for any part of the framework, and for any type of file.
Assessment of which file to invoke or serve up is made by our PageManager class, which checks, not only for customised files, but for the existence of a filename with a role extension (an appended hex value from 0 to F) which will take priority.
Taking an approach like this has made it significantly easier to maintain the integrity of the framework itself while still delivering the customisations our clients request.
The next Lesson from EAF: 2. Handle multiple languages.