Manifests for the PHPCR ODM document tree
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.
- When we persist an "article" a corresponding "route" should be created
-
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.
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.