When I think about the modularisation of Symphony, I think of it from an enduser’s perspective where the enduser is someone just using the system without hacking it. Maybe this slightly different view can refine the proposed new project structure. For me, a modularised Symphony should be a series of consecutive blocks I can choose to use. These blocks are:
- data management
- output management
- administration
1. Data management
The data block is everything from the core related to data management. In old words, there are fields, sections, entries, data sources and events. But there is no routing (pages) and no templating (XSLT). This block has no GUI but there is an API to manage data input and output (GET, PUT, POST, DELETE and such).
This data block can be used to build an API server without anything else. You’d administer it using a CLI.
If I’d like to use Symphony alongside front-end frameworks like Angular, React or Ember this is all I need.
Rethinking data sources and events
In this context, data sources and events would be advanced to API endpoint definitions. These files would describe
- which API endpoints exist,
- which authentication to use (none, Symphony, Members, oAuth, …)
- which output to return at an endpoint (data source like)
- which input to accept at an endpoint (event like)
- the content flavour (XML, JSON, …)
2. Output management
The output block integrates routing, filtering and templating and is only needed when relying on „traditional“ server-side templating like the XSL we are all used to. Similar to block 1, it doesn’t offer a GUI, all configuration is file-based and stored in the workspace.
Now that data sources and events have transformed into endpoints, you’d no longer attach those to your pages. You’d add API calls to your pages instead:
/symphony/api/sections/entries/?flavor=xml&sort=desc&limit=20&filter=…/symphony/api/sections/comments/?flavor=xml&sort=asc&limit=10
The output block will retrieve this data based on a route and will call a transformer (e. g. XSL, Twig, Handlebars) to create the output. The pages store all this in a configuration file that also defines which template to use.
If I’m a developer, blocks 1 and 2 might be sufficient for me to build any site or app I need
3. Administration
This is what we called the backend up to now. It’s the GUI to access and manage Symphony’s data input and output. It should offer everything you need as a designer to create a website or app and should offer everything you need as an author. Although it might look completely different, the purpose of this block is exactly the same as the one of the current backend.
This block is only needed, if I’d like to use a graphical user interface.
Admin as a workspace
This is made for front-end users and therefore it should be built using technology the Symphony front-end folks are used to:
- XML
- XSLT
- HTML
- CSS
- JavaScript
This will help developing the admin interface continuously because extending and improving the backend works exactly as building a front-end site. There is no need to program.
The backend is just one additional workspace. A front-end app to access the Symphony API. Which means in reverse conclusion that anything that can be done in the backend can also be done in a custom front-end.
Multiple Workspaces
If you think this further, it would be logical to not have one workspace but multiple. This would simplify different use cases:
- different iterations of the same site could live side-by-side
- one install could server different sites
Extensions
The composer.json file is almost significant enough to replace the `extension.meta.xml` file, but it’s likely both could coexist.
As we are talking about a major version release there is no need to be nostalgic: decide in favour of one, go with the common composer.json.
Likely move away from ‘convention’ in favour of ‘configuration’, eg. A new Field isn’t ‘autodiscovered’ by a /fields folder, rather the extension informs Symphony that it has a Field available to register in the service container.
Looking at things from the front-end perspective, I’d favour Symphony’s current opinionated approach of using convention over configuration. It’s one of the great strengths of the system in my eyes. Things just look and work similar across all extensions which helps a lot when you are not a backend developer but have to dive into the world of the core and its extensions.
John O’Nolan, the creator of Ghost, has written about their choice of Ember for the Ghost backend that accentuates the benefits of this approach:
One of the most important reasons that we ultimately chose Ember was precisely because it is so opinionated and, at times, inflexible. Because in a fully open source team, that’s a huge advantage. There is a definitive right or wrong way to do things in our client-side app, and it is exactly the same as every other Ember app. We never need to have any debates or discussions about implementation. The framework puts us on the same page. […] As an Ember developer, when you jump between Ghost, Discourse and your own Ember projects — you are immediately at home. Everything is the same right down to the directory structure. This dramatically lowers the barrier to entry for new developers.
Naming
I’d suggest to not use the plain word symphony for naming components but to keep up using symphony-cms in order to minimise confusion with Symfony.
This entry was first posted on Medium as an reply to Brendan Abbott’s Gist about a modular approach to Symphony.