datafox is a project we are working on for impactconsulting. impactconsulting serve the NGO community, helping them manage their processes better. datafox manages contact, meeting, proposals, project, donations and more. It has been designed to be completely modular and configurable from an installer front-end. the site itself is a one-page site, meaning all content is dynamically loaded and stored in the browser memory. this provides a lightning fast experience since there are no page reloads, as well as being very dynamic. For example, the history of previously opened records and searches is displayed in a list, and the user can instantly switch between them.
I think I’ve pushed the dojo data apis as far as it ever expected to go. Each form is dynamically constructed from dojo widgets based on a json configuration file. The json file is created indirectly from an installer part of the website, which means every field in every form can be reorganised and optionally removed. Sounds great in theory and it’s fine when you have a fairly structured piece of data. But when there are any number of configurable modules, each with configurable links to other modules, it starts to get complex. I was originally trying to abstract the database layer so that the dojo side would deal with a simplified version of the database, but that introduced more problems that it was worth, so now the dojo side has a mirror of a subset of the database (depending on what’s been loaded already). I’ve changed my mind about this architecture so many times I’m not sure what I think anymore. It does work though and is fantastically versatile. Of course the problem with this approach is handling the specific niceties that inevitably occur in specific modules. Holding up so far.
