Future ideas
- Please try to add github issue links to your points where they exist
- Remove things that are on a Release x.y page or that got implemented
- See also Feature brainstorming
This would be a generalization of the cmf_embed_blocks filter. (Which is broken when using frontend editing, as then the rendered output is stored instead of the short tag).
The initial use case for this is being able to insert wiki-style links in your document content that contain a reference to the uuid of a Phpcr page. The full URL would be replaced in the content via a twig filter. This concept could be generalized to something like wordpress' short tags (A feature which is present in many CMSes). It would be great if this was generalized so users could tag a service as a cmf.embedded.provider and we would provider a twig filter that looked for a format like foo, { param1: 'value' } that would get the provider with the alias 'foo' that was tagged as a cmf.embedded.provider and call a method on it with the params provided that would be used to replace that tag with the dynamic content. Discussion at https://github.com/symfony-cmf/RoutingBundle/issues/178
- linear workflow: draft, ready, published, archived... (we have a basic publish workflow solution in CoreBundle)
- page preview of drafts with access control
The integration between code / templates and dynamic content is a difficult problem that is not addressed by the cmf so far. See https://github.com/symfony-cmf/symfony-cmf/issues/212 for the discussion.
dtl: As said I hinted in the meeting I think we can fix this through the introduction of a bigger feature i.e. site "contexts" and "resource location". Which would be a major feature and would kill not a few birds with one stone including Multi-site, centralized base-path management Referencing and resources with static identifiers.
Unify the ContentBundle / CreateBundle REST support, so that we can read/write/delete any content based on the actual routing structure.
Furthermore look into providing a generic REST API on top of PHPCR (potentially based on Jackrabbit Oak's REST API). Also look into SyliusResourceBundle, Marmelab PHPCR-API and other related projects.
This would open the road for things like marmelab/admin-ng.
See this PR https://github.com/symfony-cmf/MediaBundle/pull/50
Work on the SonataMediaBundle to integrate it with the CmfMediaBundle for phpcr (rmsint)
Creation of a sitemap in different formats based on cmf routes and its content https://github.com/symfony-cmf/SeoBundle/issues/132.
Finish grouped admin list and implement it for the block and maybe the media bundle (keeping probably the admin separate from the core as mentioned above)
https://github.com/sonata-project/SonataDoctrinePhpcrAdminBundle/pull/141
- linear versioning control in admin backend (the phpcr level is implemented in jackalope-jackrabbit and phpcr-odm supports it)
Make all admin implementations more equal to increase maintainability, move code duplications to the AdminBundle.
Implement ORM support in all bundles.
https://github.com/symfony-cmf/symfony-cmf/wiki/Multi-Domain-Support
Find a solution for tagging. There are several Bundles out there already: https://github.com/symfony-cmf/symfony-cmf/issues/161
In terms of leveraging PHPCR see here: http://stackoverflow.com/questions/14315031/best-way-to-implements-a-tag-based-search-system-by-jcr-like-modeshape
Another cool feature for 1.1 would be to revive the support for http://wiki.iks-project.eu/index.php/Stanbol
We should be able to link doctrine entities, mongo/couch documents or also non-doctrine things with adapters. There have been a bunch of half-finished efforts for this:
- https://github.com/ElectricMaxxx/DoctrineOrmOdmAdapter
- https://github.com/hacfi/ObjectBridgeBundle
- https://github.com/netvlies/DoctrineBridgeBundle
- https://github.com/Atlantic18/DoctrineExtensions/blob/master/lib/Gedmo/References/ReferencesListener.php
I think a one-to-one mapping between node type and document would have huge benefits for the ODM.
- Queries would become more logical (SELECT FROM odm:user AS u LEFT JOIN odm:site AS s).
- We could generate CND schema for each document.
https://github.com/jackalope/jackalope-doctrine-dbal/issues/14
Right now the entire node data cache is cleared on any node write. This could maybe be made smarter.
Furthermore maybe the solution could be made generic to also work with other transports
The component has received a lot of attention and we need to make it standalone from the CMF. To do this some things are needed:
- The component should not require any database layer by default. It should only provide optional integrations with the PHPCR odm and the ORM.
- All documents should be moved to the bundles inwhich they are used
- The way the component works with different database layers should be refactored (see next section)
A useful testing component would be able to be used outside of a Symfony context, for example when testing components which are not coupled with Symfony - for example PHPCR-ODM or Routing.
- This would enable us to move documents et al to components and keep tests where they belong - in the component.
Currently, the component has not the best setup for database-testing:
- The database is only created before running the tests, this means all tests will get the mutated database, depending on what was done before it.
- To make clear which database layer, phpcr odm or orm, is used, the component uses environments. This is not the best thing to do.
Both drawbacks can be fixed by organizing the tests in testsuites, one for phpcr odm and one for orm, and using PHPUnit_Framework_TestListener to create the database on startTestsuite and using startTest to clear the database and load the fixtures (configured in the db helper).
Some tests take up to an hour, that's not good for a test. We should rethink the required packages, to make composer quicker and we should introduce parallelized builds.
There is discussion if this is desirable and how we would best do this. git subtree split was mentioned...
A standard library containing cross-cutting interfaces and traits.
e.g.
/Meta/TitleInterface
/Meta/TitleTrait
/Meta/NameInterface
/Meta/NameTrait
/Meta/LocaleInterface
/Meta/LocaleTrait
/Tree/HorizontalNodeInterface
/Tree/HorizontalNodeTraite
/Tree/VerticalNodeTrait
/Slugifier/SlugifierInterface
/Content/ContentReferenceInterface;
I started something here: https://github.com/dantleech/cmf-standard-lib
The following are some of the current integrations we have in the CMF:
- Sonata Admin (in every adminstrable bundle)
- Doctrine ORM
- Doctrine PHPCR-ODM
- ElFinder
and I am sure that there are some more. We can imagine adding more third-party integrations as people ask for them or PR them.
Having these integrations in the core bundle causes the following problems:
- It forces the developers of the code bundles to take responsiblity for an unbounded number of third party integrations.
- Tests become increasingly complicated and long running.
- We either include all the dependencies or we suggest them - but this defeats the object of dependency management!.
I would suggest that:
- We outsource all the third-party integrations into satellite packages
<path-to-bundle>
Symfony/
Cmf/
Bundle/
MenuBundle/
Doctrine/
Orm/ < -- Bundle root is here
MenuDoctrineOrmProviderBundle.php
MenuProvider.php
Resources/
config/
doctrine-orm/
mapping.xml
We can make sattelite bundle configuration suitably brief by providing a special bundle class:
// /vendor/symfony-cmf/menu-bundle-persistence-doctrine-orm/[...]/MenuBundle/MenuPersistenceDoctrineOrmBundle.php
namespace Symfony\Cmf\Bundle\MenuBundle;
class MenuPersistenceDoctrineOrmBundle extends BundleExtension
{
public function buildContainer(ContainerBuilder $container)
{
$def = new Definition('cmf_menu.persistence.orm_provider');
$def->setClass('Symfony\Cmf\Bundle\MenuBundle\Persistence\Doctrine\Orm\MenuProvider');
$def->addTag('cmf_menu.provider');
$container->setDefinition($def);
}
}Traits will supplement Interfaces to provide boilderplate code which can be imported into user implementations.
An example of what might be done with the MenuNode:
<?php
use Symfony\Cmf\Standard as Std;
use SYmfony\Cmf\Bundle\Menu\LinkTypeInterface;
use SYmfony\Cmf\Bundle\Menu\LinkTypeTrait;
class MenuNode implements
Std\Meta\LocaleInterface,
Std\Publish\TimePeriodInterface,
Std\Publish\PublishableInterface,
Std\Content\ContentReferenceInterface
LinkTypeInterface
{
use Std\Meta\LocaleTrait;
use Std\PublushTimePeriodTrait;
use Std\PublishableTrait;
use Std\ContentTrait;
use LinkTypeTrait;
}dbu says: This would make a lot of sense indeed. Unfortunately, we can't rely on this for our own code. Redhat is still at PHP 5.3 so i guess requiring PHP 5.4 has to wait another year or so. We could announce at 1.2 that 1.3 will start to use traits, wdyt?
(See MediaBundle above)