Folder versioning and publishing - easysoa/EasySOA GitHub Wiki

This page discuss about the impact of publishing logic on the Content model with regards to the Folder versioning.

Context

The initial requirements comes from the fact that EasySOA model is represented as a content tree that can be versioned.

For that point, a new Nuxeo addon was created : https://github.com/tiry/nuxeo-tree-snapshot

But as defined in the submitted Test case we need more that simple folder versioning, we also need a way to have several parallel trees (design, impl, deploy) referencing each other.

This raises issues about how the content must be stored.

Proxy vs Multi-Filling

The submitted test case does not really define requirements about versioning : there is indeed no version in the test. As a summary, the test case would like to have :

a folder that is part of 2 separated trees
the ability to add a children in one tree or an other and have a consistent view on getChildren list

What this test wants is basically multi-filling and not "Proxies".

Multi-Filling

Multi-Filling would allow the same object to have several paths. This would allow to make the test case run.

However, having this model would break a lot of existing stuffs inside Nuxeo :

the security system is placeful : we need to have separated ACLs for separated paths
localconfig allows to bind arbitrary config to a path : how would we manage that with multi-filling
the default UI exepect that given a context document, the navigation tree and the breadcrumb can be computed : this is not true with multi-filling

Proxy model

Why this model

The proxy model allows to "emulate" some of the feature of multi-filling while keeping the model consistent.

Several proxies can point to the same document but :

each proxy can have it's own ACL
each proxy has it's own path and then it's own localconfig descriptor
the proxy context is enough to build the UI

Current limitations

When talking about Folder the proxy system implementation has some limits.

A proxy on a Folder is a Folder too, but the list of children is different. Because the parent/children relationship is managed inside the hierarchy table and because proxy and target document have separated UUID, the list of children of the folder is not the same as the list of children of the proxy.

Let's say I have :

FolderA
  |
  ---Item B
  |
  ---Item C

Then if I create X a live proxy pointing to FolderA I will have

ProxyFolderX ----link----> FolderA
  |                          |
                             ---Item B
                             |
                             ---Item C

But ProxyFolderX has no children for now. And of course I can add new children to ProxyFolderX that will have nothing to do with the Children of FolderA

ProxyFolderX ----link----> FolderA
  |                          |
  ---Item Y                  ---Item B
  |                          |
  ---Item Z                  ---Item C

Possible approach

Content View

Inside the default UI, the folder contents is actually not computed via getChildren.

The folder contents listing is generated via a ContentView that is built on top of a Query.

The default query is :

SELECT * FROM Document WHERE ecm:parentId = #{currentDocument.id} ...

We could make this a little bit more clever so that when applied on a proxy folder we do something like :

SELECT * FROM Document WHERE ecm:parentId = #{currentDocument.sourceId} ...

This would work in the sense that lising ProxyFolderX will give us the expected result :

ProxyFolderX 
  |
  ---Item B
  |
  ---Item C

However, if item B is a folder too and I click on it then I will actually navigate to Item B in the context of FolderA :

this will only work for one level of nesting
navigation will be "broken"

Tree Publishing

An other option, will be to do a recursive publication.

This means we consider that when creating ProxyFolderX, we actually publish FolderA and all it's children

Root1                      Root2
 |                          |
 ProxyFolderX ----link----> FolderA
  |                          |
  ---ProxyOnB ----link---->  ---Item B
  |                          |
  ---ProxyOnC ----link---->  ---Item C

To achieve that we need :

recursive publishing (can be added to publisher service)
listeners to maintains consistency
to prevent direct children creation on ProxyFolderX and any of it's proxy children

This system will be consistent with security and navigation, but the listener work is really a mess.

Low level Management inside VCS

We could think about a low level getChildren method that does all the job :

do the actual getChildren indirection
adapt the path of the returned DocumentModels

This can not be transparent for the UI, at least the URL codec must be changed, but this may be a path to investigate ...