Skip to content
This repository has been archived by the owner on Sep 16, 2021. It is now read-only.

Manifests for the PHPCR ODM document tree

dantleech edited this page Mar 26, 2013 · 3 revisions

The basic idea is to find out if we can apply something like the concept of puppet manifests to the PHPCR-ODM document tree.

This is inspired by my work on the RoutingAutoBundle. Whilst working on that I realized that alot of the logic doesnt just apply to routing, it applies equally to PHPCR paths. So why limit ourselves to the automatic creation of Routes when we can automatically manage anything?

So some of the things this should achieve:

  • Enable automatic creation of child documents.

    • When we perist a "site", any concrete element which declares it as a parent should be created.
    • These documents can be templated in the configuration.
    • The initial documents would be trigerred by the persistance of the root document "/" (if possible)
  • Enable automatic creation of arbitary related documents.

    • When we persist an "article" a corresponding "route" should be created
      • Multiple documents can be created and they can reference each other. So we can create chains of documents (e.g. a complicated URL schema).
      • i.e. this could replace RoutingAutoBundle.
    • When we persist a "site" we automatically create a user document.
  • Enable automatic positioning of documents.

    • Save a document and its parent can be set automatically.
  • Enable the entire PHPCR document tree to be syncronized with the current configuration via a command.

  • Allow prototype documents to "extend" existing documents.

    • By "extend" I mean copy the properties of. So we could declare that an Article should automatically be placed in "Site B" (when it is created) which is a clone of the article defined in "Site A".

I would also like this to:

  • Allow these "manifests" to be created within the database itself, for example:
    • Users / admins could for example create a site template, which could subsequently be used in a signup process to create the actual site.
    • Users could then update the manifest and push the changes out to all or specified sites.
    • Such manitifests could be exported / imported / shared.

Example manifest

This is just ideas - at the moment it is inconsistent and it doesn't work. But I think you can appreciate the general idea.

##############
# Base folders

site_folder:
    type: document
    name: Cms\Bundle\Document\Folder
        provider: specified
        name: sites
    parent: ~

prototype_folder:
    type: document
    name: Cms\Bundle\Document\Folder
        provider: specified
        name: prototypes
    parent: ~
    
###############
# Site document
# -------------
#
# When this document is persisted by DM we search for any non-prototype
# documents that have declared this as their parent, then created them - 
# so we would create "/sites/site.com/articles", "sites/site.com/medias"
# and "/sites/site.com/routes"

site_context_document:
    type: document_prototype
    class: My\Bundle\Document\Site
    name: 
        provider: 
            name: service
            id: site_manager
            method: getSiteName
    parent: site_folder

articles_folder:
    type: document
    class: Cms\Bundle\Document\Folder
    name:
        provider: 
            name: specified
            name: articles
    parent: site_document

medias_folder:
    type: document
    class: Cms\Bundle\Document\Folder
    name:
        provider: specified
        name: medias
    parent: site_document

routes_folder:
    type: document
    class: Cms\Bundle\Document\Folder
    name:
        provider: specified
        name: routes
    parent: site_document

#######################
# Routing configuration
#

blog_route:
    type: document_prototype
    class: Symfony\Cmf\Bundle\RoutingExtraBundle\Document\Route
    parent: routes_folder

post_route_date:
    class: Symfony\Cmf\Bundle\RoutingExtraBundle\Document\Route
    name:
        provider: method_datetime
        method: getDate
        format: Y-m-d
    parent: blog_route

post_route:
    class: Symfony\Cmf\Bundle\RoutingExtraBundle\Document\Route
    properties:
        routeContent:
            provider: self
    parent: post_route_date

#######################################################################################
# Auto documents - these resources listen to persist and update events on their targets
# and will fire create / or updates on their respective prototypes and make them concrete.
#
# When multiple "auto documents" reference the same target, these auto documents can declare
# each-other as dependencies, they will be executed in their dependency order.

post_route_date:
    type: auto_document
    attach_to: post_document

post_route_auto_doc:
    type: auto_document
    attach_to: post_document
    prototype: post_route_definition
    name:
        provider: method
        name: getTitle

post_route_date_auto_doc:
    type: auto_document
    attach_to: post_document
    prototype: post_route_definition
    name:
        provider: method
        name: getTitle

So this would create a structure like:

/
  /sites (concrete)
      /site-x.com (abstract)
          /blogs (concrete)
              /blog-x (abstract)
                  /posts (concrete)
                      /post-x (abstract)
          /routes (concrete)
              /blog-title (automatic from Blog)
                  /2012-12-12/ (automatic from Post)
                      /post-x-title (automatic from Post)
          /medias (concrete)

So when a "site" is persisted it will assume the role of "site-x.com", the concrete children will be created automatically, when a blog is persisted it will assume the role of "blog-x" etc.

Also the automatic documents will be created or updated in accordance with their targets.

Clone this wiki locally