Die folgenden Überlegungen sind als Antwort auf auf Brendan Abbotts Gist über einen modularen Ansatz für Symphony entstanden und stehen bisher nur auf Englisch zur Verfügung:
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
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 (
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:
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
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:
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.
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
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.
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:
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.
Dieser Eintrag wurde zuerst auf Medium veröffentlicht.