The everyday developer will clone the workspace to create their project. This repository accepts Issues, Wiki and Pull Requests.
All resources in here are custom to the specific project, all the dependencies will be resolved into /vendor. There are a few boilerplate files such conductor and index.php.
Favour convention approach, commands, datasources, events and sections are autodiscovered where possible, however some configuration may be required for the service container (if the items have dependencies). Needs fleshing out.
It will include:
- workspace/ (may even be flattened?)
-- commands/
-- data-sources/
-- events/
-- sections/
-- views/
- manifest/ (optional?)
-- tmp/
-- cache/
-- logs/
-- config (needs better environment support. consider YAML/XML/.env alternatives)
- public/ (exposed as the 'root' for Apache/nginx, very similar to Laravel)
-- .htaccess
-- index.php
- conductor (CLI)
- server.php
- composer.json
This is the rollup of all components that makes up a version of Symphony (eg. 2.6.7). This repository will accepts issues and pull requests. There may need to be some sort of orchestration component here, or moved up into symphony/workspace that ties all of this together in terms dependency injection, registering services etc.
- build/
-- misc. scripts for distributing symphony etc.
- src/
-- components/
--- templating/
---- src/
---- tests/
---- composer.json
--- etc.
- tests/ (Orchestration tests PHPUnit/Behat)
- specs/ (PHPSpec tests)
Component repositories are read only, and have issues and pull requests disabled. Issues are managed via symphony/symphony-cms with labels for each component. The project structure here is largely up to the developer, but as a 'core' component our best practice could be:
- src/ (source code)
- resources/ (documentation, assets etc.)
- tests/ (PHPUnit/Behat)
- specs/ (PHPSpec)
- composer.json
All extensions would ideally be installed as composer dependencies. The composer.json file is almost significant enough
to replace the extension.meta.xml file, but it's likely both could coexist.
conductor extension add symphonycms/members (utilise symphonyextensions.com to retrieve files)
composer require symphonycms/members (requires extension have composer.json and be listed on packagist.org)
Extensions should mirror the component structure, but it'd be rather flexible (as long as there's an autoloader, things are a-ok)
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. Needs fleshing out...
Something that is regularly raised is why isn't Symphony built on Symphony? It's a fair point, and some of the issues that exist today might of been avoided if this was the case. For example, the delegate system is fantastic, but often Extensions are able to do things the 'core' cannot!
I think Admin should be developed as if it was based on symphony/workspace, but it's pulled into that project as symphony/admin.
This opens up an opportunity where the UI is 'optional' and could be custom built or interchanged depending on the project requirements.
The Admin is largely a visual representation for the objects in symphony/workspace (DS/Events) etc. In theory, all that
could be removed to just leave a UI for Authors to manage and create content.
Sounds a lot like the “ideal architecture” I had in mind for quite a while now. Even started building something similar on my own, but didn’t get very far so far.