CompositeRepositry has been removed from the Puli 1.0 release.

It would be good to implement it here and also make a PR on Puli.

when visiting this repo first page, the link to docs points to http://symfony.com/doc/master/cmf/bundles/resource/index.html - which returns a 404 on Symfony's website.

might wanna check it out :)

We could support the Doctrine ORM by using "sharding" based on table fields to provide a hierarchy.

By providing a list of SQL field specifications we should be able to emulate a
hierarchy.

cmf_repository:
    repositories:
        invoices_by_date:
            # e.g. /2016/06/SYMCMF-01
            type: doctrine_orm_sharded
            class: AppBundle\Entity\Invoice
            name: {{ clientRef }}-{{ invoiceNo }} # property access

            # in SQL
            shards:
                - "DATE(date)"
                - "MONTH(date)"
        invoices_by_client:
            # e.g. /SYMCMF/00001
            type: doctrine_orm_sharded
            class: AppBundle\Entity\Invoice
            name: {{ invoiceNo }}

            # in SQL
            shards:
                - "clientRef"

        default:
            # mount in a composite e.g.
            #
            #   articles/
            #      ...
            #   invoices/
            #     date/
            #       2016/
            #         06/
            #           SYMCMF-0001
            #     client/
            #       SYMCMF/
            #         0001
            #  
            ty: composite
            mount:
                - 
                    repository: invoices_by_date
                    mountpoint: "/invoices/bydate"
                -
                    repository: invoices_by_client
                    mountpoint: "/invoices/byclient"
                -
                    repository: articles # f.e.
                    mountpoint: "/articles"

Its obviously atm not an issue .. but feels iffy to have a namespace named after a reserved word

We could use objects for the Descriptors and access them by their class name:

$description->addDescriptor(new HtmlLinksDiscriptor([
    HtmlLinksDescriptor::EDIT => '/path/to/edit/1',
    HtmlLinksDescriptor::REMOVE => '/path/to/remove/1',
    // ...
]);

$description->addDescriptor(new ChildClassesDescriptor([
     FooClass::class,
     BarClass::class
]);


$linkUrl = $description->getDescriptor(HtmlLinksDescriptor::class)->getEditUrl();

if ($description->hasDescriptor(ChildClassesDescriptor::class)) {
    $childClasses = $description->getDescriptor(ChildClassesDescriptor::class)->getChildClasses();
}

It can then be assumed that if the client is requesting the descriptor by class name, that they know what to do with it (i.e. it can have its own public API).

Unfortunately this is very verbose in Twig:

<h1>Hello</h1>
<a href="{{ description.hasDescriptor('Name\Space\Descriptor\HtmlLinksDescriptor') ? description.descriptor('Name\Space\Descriptor\HtmlLinksDescriptor').editLink }}">Edit</a>

This approach solves the current ambiguity problem posed by having a simple key/value store, but increases the verbosity, especially in Twig and when consumed through the REST service.

The Sonata Enhancer can live in the as-yet-not-existing CmfSonataAdminBundle.

The Sylius Enhancer should live in an equivilent place.

These are integration enhancers, and should be part of an integration package which has all of the relevant dependencies.

sylius/resource-bundle should go into require section of composer.json or the SyliusEnhancer has to be enabled when available only

symfony-cmf/resource-bundle exists, but symfony-cmf/resource seems not to exist.

/cc @lsmith77

broken link for ResourceBundle documentation

Need to see how I can get this or rest bundle working, because I'm getting _cmf_resource not found error

Allow retrieval of default registry, or if no default set, the first registry in the event that ->getRegistry() is called with an empty value.

Alternatively always throw an exception and put the responsiblity for resolving registries on the consumer.

The ResourceRestBundle currently has the concept of "enhancers" which add
fields such as the URL to edit or create the underlying resource payload.

I would like to push this back a level: this information is useful more
gernerally, for example when building an admin interface that doesn't need REST
and where you need the edit/view/create/delete URLs.

Puli already has the concept of Metadata but it is metadata from the
resource, we want metadata which is "over" the resource - i.e. the URLs of the
admin system.

So I am proposing something like:

class SonataMetadata implements HtmlAdminMetadataInterface
{
   /**
    * Return the edit URL for the resources payload.
    *
    * @return string|null
    */
   public function getHtmlEditUrl();

   /**
    * Return the remove URL for the resources payload.

    * @return string|null
    */
   public function getHtmlRemoveUrl();

   /**
    * Return the add URL for the resources payload using this item as a parent.

    * @return string|null
    */
   public function getHtmlAddChildUrl();
}

or:

class SyliusMetadata implements AdminMetadataInterface
{
    public function __construct(Router $router)
    {
        // ... 
    }

    public function supports()
    {
        return [
            AdminMetadata::HTML_EDIT,
            AdminMetadata::HTML_REMOVE,
            AdminMetadata::HTML_ADD_CHILD,
            AdminMetadata::REST_CREATE,
            AdminMetadata::REST_REMOVE,
        ];
    }

    public function get($name)
    {
         switch ($name) {
             case AdminMetadata::HTML_EDIT:
                  return $this->router->generate(' ... ');
                  break;
        }

        throw ..
    }
}

Where we would have a factory system using drivers similar to the current SonataEnhancer in the ResourceRestBundle.

Very much open to other ideas.

/cc @wouterj @dbu @lsmith77

I think it makes sense for Resource's to be mutable.

This would facilitate, for example, modifications to be made from a Tree view (using elfinder / jstree, whatever).

This is what the Apache Sling ResourceProvider does.

CMS resources are orderable, in addition to the EditableRepository methods we need to be able to change the order of resources.

I currently suggest adding this to the CmfEditableRepository interface being added in #17.

public function reorder($sourcePath, $destPath, $before = false);

or

public function orderBefore($sorucePath, $destPath);
public function orderAfter($sourcePath, $destPath);

I am currently writing a CRUD which accepts the resource repository and path as request parameters.

/{repository}/{path}/edit

A form is then obtained from the ether for the (CmfResource) payload. When the form is submitted the resource payload needs to be updated.

I am currently doing this throguh a separate "agent" system (currently only concerned with save, as finding is taken care of by this component).

• Adding a save/savePayload method for a ResourceRepository would be quite trivial at this layer

I am just wondering if it is a good idea or if it would be a can of worms for some reason.

I wonder to what extent we could support WebDAV, for example via

https://github.com/fruux/sabre-dav

Ultimately this would allow people to mount the repository tree locally as a filesystem.

If we support [get|set]Body then we could support remote authoring / template design.

For example if Twig templates could be stored in the ORM, PHPCR-ODM or even on the filesystem (!). A document/entity would only need to implement a MutableBody interface and a designer could modify remote templates in a local editor.

All of the current desciption enhancers act upon the Payload - i.e. they don't really care about the resource.

This is not to say that enhancers can't act on the resource itself (e.g. actual files) but just that currently none of the do.

We can extract the Description stuff into a separate component that acts upon objects of any type, not just PuliResource instances.

CmfResource instances can still be supported - we just make a PuliResource enhancer which is a "proxy" to the descrition for the payload and other Puli resources (e.g. FileResource) can still be handled.

The current "description" system can be very easily generalized to act on objects instead of Puli resources.

I have created a description component and bundle, and also an enhancer for doctrine phpcr odm.

So I would suggest using this. The only difference is that the enhancers are not registered by the bundle and should be registered by the user.

(also note that all of the above is, as with this component, under development).

Both name and alias are being used to refer to the name of a configured repository instance. We should choose one - I suggest name.