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.
Conclusion
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.
Comments
Yay for
:-)
That’s an interesting list of things. Nice!
Ditto
Small to medium woop woop.
Thanks for the update, Craig.
This makes a lot of sense, although I could see the list of extensions becoming much longer. I’m glad to see that this will also come with an enhanced way to manage extensions.
Could you elaborate on the possible types of data sources?
I am very much looking forward to the refactored access control support.
This, to me, is the most exciting feature.
This is just what I’ve been waiting for.
That’s excellent. Also It would be great to see improvements related to Symphony’s structure, that means using
DOMElementinstead ofXMLElementclass. Any possibility?Thanks, Craig!
Well, most of the existing types will be abstracted: Static XML, Dynamic XML, and so on. So you could, for example, extend these to include advanced processing and caching and so on. I could also imagine DS types for grabbing structured non-XML formats, like JSON.
Heh. It’s what we’re all dreaming of, but unfortunately the deadline for 2.1 is too tight and this switch would require rewriting quite a bit of the core. It’ll have to wait until 3.0 I guess.
Like these changes! Get her done boys :-)
Not to mention every extension!
When you guys replace XMLElement, I’m getting a Symphony tattoo.
will upgrading to 2.1 be as painless as upgrading from current 2.0.x versions of symphony?
No. I’m not sure exactly how difficult it will be, but as you can see there are some very significant changes under the hood and I wouldn’t count on being able to easily upgrade.
That sounds great. It seems a major effort is to ‘extensionize’ the system even including the default elements. Will this make Symphony a little harder to manage?
@bc_creations, we’ve gone to the effort of updating the extensions page to account for the increase in extension number for better management.
In terms of management from a development perspective, it will be much easier. The reasons are:
Both core and third-party extensions will utilise the extension API. Everything will live on the same playing field. This means there will only be one way to do something and not one way for the core (that’s more privileged) and another for extensions.
Every Symphony version update must go through a release candidacy cycle, which can range from a week to two months. Any fields, data source types and other externalised components will no longer have to be burdened by the long wait cycle.
All fields will be extensions and thus become optional. i.e. the input field and text area field can be replaced by the text box field that does both. This should simplify the overall complexity of your section editor.
That does sound great. I’m guessing what the system could really use then is a more versatile extensions page. In which you could update/find alternatives for extensions as well.
But I’m pretty sure that’s not something to incorporate easily ;)
What is the possibility that the sections & fields could be defined by rdfs files (either natively or by extension)?
Is there a development plan/timeline we could see anywhere? I’d love to take a look.
Create an account or sign in to comment.