- PHP backend: I know PHP is only a scripting language, but I want to sell this app to end-users who will self-host, and I don't want to make it too hard for them. PHP is cross-platform, ubiquitous, fast and dead-easy to deploy. It lacks strong typing, full-featured OOP and code compilation, but it meets my needs for this project.
- Database independence: I'm happy with MySQL, but end-users might prefer SQL Server or something else.
- Smart schema and data deployment: From experience, deploying schema upgrades and data updates safely and with minimal user involvement can be problematic. I particularly wanted a framework that could auto-detect pending schema changes and apply them, regardless of the age of the installed schema.
- Simple persistence: Persistence frameworks tend to be code and metadata-heavy. I wanted to write SQL to retrieve object data and have the framework handle the rest, with optional hooks for validation and business rules available as needed. Most importantly, I wanted the persistence framework to play nice over RPC with JSON serialization.
- Tight Dojo integration: There are many AJAX toolkits, but Dojo seems to be the most robust and mature when you're looking to move most of your view/controller code to the client-side. Its widget library, modular code, data handling and custom builds make it much more suitable for serious front-end development than jQuery etc., which are great for pretty effects and discrete code snippets, but not much more. Ideally, I wanted a server-side persistence framework with Dojo integration built-in.
Too much to ask? Yes, apparently.
None of the web application frameworks I found ticked enough boxes; most were too heavy on the server-side and too weak on the client side. Symfony2 was the best I could find.
So, I'm writing my own framework. More as I proceed.
Have you thought of a nosql option instead of sql? see http://goo.gl/gPnL9 for a php friendly option - no need for an orm then, and the schema changes as your objects change.
ReplyDeleteWhat the solution you're looking at deploying on your framework?
Thanks for that, Sam.
ReplyDeleteYes, I did look at a couple of nosql options (albeit fairly briefly). In a future post I'll look at why I decided to stick with backend schema management and an ORM (of sorts) on top, but in short I was wary of managing performance bottlenecks down the track (I'm pretty careful about SQL index management) and wanted to be able to bury complex data structures behind simple objects. nosql options require underlying structures to be as simple as the objects themselves, which limits storage efficiency.