|symfony container [message #79784]
||Fri, 12 June 2009 18:35
Registered: December 2007
I have a bunch of bash scripts to deal with our symfony projects (we have about 10 projects) but I'm not too happy with the scripts being tailored to our custom directory structure, apache version, plesk version and all that.|
So I had in mind a rough concept for a generic symfony container:
The actual container would be the directory containing multiple domains/symfony projects (which most of us already have in /var/www/ or whatever web root you have), along with some configuration mechanisms.
It could have its own web application for managing the container itself and its projects. So in essence this makes it sort of a meta project.
In the container directory there would be a "symfony" file with new CLI tasks:
container:clear (clear all caches)
container:build (rebuild all models)
container:deploy (deploy all sites)
container:permissions (run fix-perms on all projects)
container:enable/disable (disable all projects)
Ideally these tasks would also understand plesk-related stuff like subdomains and vhost.conf annoyances, and of course also handle systems other than plesk.
The container would also provide a way to add a new project using the new project customization ( http://www.symfony-project.org/blog/2009/06/10/new-in-symfon y-1-3-project-creation-customization)
. Since all our symfony projects link to a central CMS symfony project, they all share mostly the same configuration options in settings.yml/app.yml etc.
Such global settings could be configurable via the container web application so you don't have to repeat yourself.
A global schema file could be used to alter a selected part of database in all projects. For example, if you write some kind of blog widget and you don't feel like creating a blog plugin, you could define the blog tables in the global schema and they would be automatically created in every database on the next container:build call.
container:disable would be a useful server-side task; if you update your global schema and rebuild all models, you want to disable all projects for this short time of upgrade.
Finally, the container would optionally have a central plugin directory so you don't have to install a plugin n times for n projects.
This concept might be interesting to users who already settled on symfony for most of their web development work. The whole idea would probably only work if all of your projects are on the same symfony version and work with latest plugin versions, but maybe it could be smart enough to track the differences between projects (eg. you still have some old 1.0 project).