Issues with 1.0
This page is intended to highlight percieved problems in 1.0 which should be fixed in the next major version.
All CMF bundles provide integration, where applicable, with Sonata Admin and the PHPCR-ODM. Some bundles such as Create provide integrations with Create.js. The MediaBundle provides integrations with elFinder.
Most of these bundles only support a single way of doing things (with the exception of RoutingBundle and the ORM). However, in the future we are likely to expand the CMF to globally support, for example, the Doctrine ORM and maybe even other Admin systems.
The problem here is that the bundles will continue to mushroom and explode as more implementations are bolted on, the test dependencies grow larger, the namespacing becomes ridiculous and versioning several concurrent third-party dependencies becomes a nightmare.
This problem is futher expounded by the TreeUiBundle which I have been working on, which proposes to support both the PHPCR-ODM and Doctrine ORM whilst also supporting various frontends, e.g. fancyTree.js and elFinder.js.
Each of these backends and frontends need time to develop and test and each have various package dependencies.
To me the only thing that makes sense is to have several packages, if we switch back to a simpler example, the MenuBundle:
- symfony-cmf/menu-bundle
- symfony-cmf/menu-bundle-persistence-doctrine-orm
- symfony-cmf/menu-bundle-persistence-doctrine-phpcr-odm
In the case of the TreeUiBundle:
- symfony-cmf/tree-ui-bundle
- symfony-cmf/tree-ui-bundle-persistence-doctrine-phpcr-odm
- symfony-cmf/tree-ui-bundle-persistence-doctrine-orm
- symfony-cmf/tree-ui-bundle-tree-fancytree
- symfony-cmf/tree-ui-bundle-tree-elfinder
- symfony-cmf/tree-ui-bundle-tree-somecustomthing
- symfiny-cmf/tree-ui-bundle-admin-sonata
Having such a package structure would enable, for example, concentrated efforts on stable PHPCR-ODM and Fancytree support whilst allowing tentative decoupled development of other implementations.
The core bundle, tree-ui-bundle, would contain the core logic and the "satalite" packages only what is specific to them.
One of the problems with this approach is the "requirement" that each package be self-sufficient for testing. The core bundle would need to include "dummy" (or at the least minimum) implementations, in this case, dummy implementations of the persistence and tree components.
Another would be the requirement of the core bundle to "know" about the other packages, this should happen at run-time and IMO we should not code if class_exists - one posibility here would be to make each of the satalite packages bundles - but with the overhead stripped down to a single CmfFooBundle file - enabling them to register DI tags and so enabling their products to be picked up by the core bundles compiler pass.
What I propose here is more work, but ultimately I think the benefits outweigh the costs and will allow the concentrated development of highly developed "stable" core packages which can then be mixed with less stable and more vulnerable satalite packages. Having this level of decoupling might also encourage develops to use the core packages who might otherwise be bothered by the risk of opinionated code which comes with built-in dependencies.