we are building a new website, which will reuse an existing symfony-software used by another website. I’m moving reusable components into a plugin (“app-plugin”), in order to avoid duplicating code and data. The plugin will be configured as svn-external in the websites’ svn repositories.
The existing symfony instance contains overridden doctrine classes (models, forms, form-filters) which are originally defined in other plugins (e.g. sfDoctrineGuardPlugin). The overridden classes can be reused by both symfony-instances, therefore I’m going to move them to the “app-plugin”. But this causes problems:
If someone, for instance, runs symfony doctrine:build-forms, the moved files will be re-created by the task inside lib/form/doctrine and will contain empty class-definitions. The reason is very clear to me: How was symfony supposed to know that the “app-plugin” is already defining those form-classes? The only way would be to autoload all classes before executing the task and checking whether classes are already available.
A workaround would be to exclude those classes in the app-plugin’s config/autoload.yml. But is there a better way?
Edit
I’m using the term “app-plugin” to avoid confusion between normal plugin (e.g. sfGuard) and our plugin which contains shared components.
Before:
After:
There seems to be no better way than excluding the original model in the app-plugin’s config/autoload.yml. Even if you can derive model-classes as shown in the images above you’ll get in trouble as soon as you run the build-forms task. I looked through the form-generator’s source code which reveals that this isn’t possible. Therefore, the only solutions are: avoiding the build-forms task, rewriting the form-generator or, as already stated, using autoload.yml.