Experimentation and Restraint
Symphony’s development process has always included a healthy amount of experimentation—with new technologies, new design patterns, new approaches to solving old problems… This experimentation takes place alongside, and often informs, the work that leads to Symphony’s public releases. You could say, then, that in a sense Symphony 2.1 has been in development since the 2.0 branch was still in its infancy.
In that time, we’ve experimented with lots of new concepts, some more radical than others. We’ve talked about converting Symphony’s back-end admin interface to XSLT, for example. We’ve considered implementing a schema-less design within a relational database platform. We’ve thought about switching to XPath for data source filtering. We’ve even taken a few shots at redesigning Symphony’s back-end UI.
These experiments—and others—continue to this day, but not every scheme we cook up is ready for primetime, and what’s innovative isn’t always what’s needed. One of the most defining characteristics of Symphony’s development over the years has actually been restraint. Though we’ve had our share of fun, exciting ideas, we’ve tried very hard to stay focused on simply making the system better at what it does. It’s this sentiment that is guiding our work on the next release of Symphony.
Our Vision for Symphony 2.1
Flexibility is almost an obsession for us. Anyone who’s followed Symphony’s development since the early days knows how highly we value flexibility, and it’s a point of great pride for us that Symphony enables you to build exactly what you want and yet only what you want. Our work on version 2.1 will be focused on continuing to push this envelope, making the system even more flexible by abstracting the core and cultivating extensibility.
The field system is being fully abstracted.
Prefer Hashed Upload to the core File Upload field? Like using Text Box instead of the generic Text Area? In 2.1, all fields in the system, including core fields, will be abstracted as extensions—able to be replaced, swapped, extended, and removed as you see fit.
Data source types will be abstracted.
In 2.1, developers will be able to add new or enhanced data source types, and the existing core data source types will be fully manageable as extensions.
The authentication system will be abstracted.
Extensions will be able to provide their own access control support, either in lieu of or alongside Symphony’s own refactored access control layer.
The admin interface’s extensions UI will be overhauled.
As more of the system is abstracted, the UI will be updated to allow smarter and easier management of extensions.
Section/Field schemas and Page configurations will be stored as files.
This is a major change that will have many benefits: it will allow content schemas and pages to be version controlled; it will make possible the sharing of content schemas among the community; and it will finally enable a level interoperability among Symphony projects (i.e. it could become possible for ensembles to be layered onto one another). There will be performance benefits as well. Instantiating from a section/field class is much more efficient than using SQL lookups, and once instantiated these objects can be stored in memory for reuse by other data sources, thus eliminating SQL query overhead for every data source attached to a page.
There are other features coming in Symphony 2.1… The ability to output multiple parameters from a data source, for instance. Or full localization support. And there will even be some small-scale UI and workflow improvements.
Our primary focus, though, is on continuing to tighten up the core so that we’ll have a really solid—and really flexible—foundation for the future.