RFC: uSync roots (aka templating) (aka blueprinting).

[KevinJump]

A thing that has been bubbling around for ages - never really making it to the top of any idea tree.

Templating, or root sites or as I think Umbraco call it Blueprinting.

the idea that you can have a 'master' site somewhere with settings and content etc, and your "child" sites inherit settings/content from the master. when you then change something in this master there is a way to update the children.

uSync implementation ideas:

For uSync there are somethings we can do quickly, and then some more complex bits we would need to work out.

PR: #526 for code progress on this

Known Knowns (Things we know how to do)

• Add a second base folder path to the config (uSync/root)
• Whenever you report or import anything merge the contents of the base path and the existing uSync root.

Updates:

• When someone trys to save a 'base' item, we do the following
  • On 'saving' nofication check for the 'LockBase' setting, if its true, don't let the save happen
  • if LockBase is false, save the new version in uSync/v9 making it the valid version for this site.
• When exporting from the dashboard
  • again check 'LockBase' don't export anything in base if its true
  • if lockbase is false, only export things that are different from the base Versions

Known Unknowns (Things we know we don't know how to do)

when there are matches, which folder wins ?

In the current test implementation the 'root' file wins (the one in uSync/v9), that is if there are two files for the same item (one in base and one in the uSync root) the uSync/v9 folder will be the one imported

Q: It might make sense that this happens the other way around ??

How do we report this ?

At the moment we are not doing anything in terms of reporting what has come from where, things are just imported, prob making it hard to work out what is going on.

the implementation as we have it, doesn't have a "master" and "child" folder it has an array of folders that are merged in order, this in theory would make it super flexible, but the reporting might be hard, ideally we want a nice way to say - importing from 'X' in the UI

what type of reporting do you think you would want (given how there might be 2,3, or 17 merged folders).

Unknown, Unknowns (Things we don't know, we don't know)

uSync doesn't do hosting, or deployment for you - how the master and child sites are related would be an exercise for the implementor.

It might be (and i really do not know) :

• Forks of the main repo for each site,
• GitHub modules for the 'base' folder
• A file copy of the base into the child site as part of deployment ?

we are not implementing this in uSync, but how we do our bits might make this easier or harder, so if there are things we should do to make it better - it would be good to know.

Is this worthwhile ?

Number one question - is does this bring any value that people will use ?

• its quite a breaking change in the core, (new interface methods on handlers, quite a lot of changes from string folder to string[] folders across methods .
• We can mitigate most of these but its also a change in behavior for every export, import and report as they will all know check for these 'base' folders.
• We will need to see how / what effect this has on uSync.Complete i think in this sate its more of an add on to the core, but we have to make sure we don't break anything.

[KevinJump]

Update : Export behavior 90a05ae

So - continuing on - what happens when you try to change an item that is in the base on a child site ?

1). App Setting LockBase will be by default true.

"uSync": {
    "Settings": {
      "LockBase": false
    }
  }

So you get an error when you try to save something that is root.

• but if LockBase is false, then the item is exported into the usync/v9 folder and will now forever be the one that gets reported on/imported for the site.

• When you run an export from the dashboard, usync has to do a number of new things.

  1. check is Lockbase is true,
  2. check is the item you are exporting exists in the base folder
  3. if it does exist compare it to what you just exported
  4. if the export is different than the base (and the base isn't locked) export it to usync/v9

[KevinJump]

For doctypes it might be nice to have property level locking, (so not just the doctype has changed, it now comes from the uSync/9 folder.

this would be harder, because as it stands the properties are all stored in the single doctype file.

• we could split properties of doctypes out into 'sub' files.
• we could then merge these subfiles back into the main doctype file pre-import.
  • we would have to cope with things like renames and deletes (similar as to how its done now)
  • there might be a performance hit (more files to read) - so likely only a doctype feature ??

questions (things we have to resolve) :

• what are the possible side effects of moving the properties out of the doctype file (e.g is there a dependency anywhere?)
• tabs might become a thing that can become disjointed
• what would be a reliable way to get all the child items based on filenames/paths

[KevinJump]

delivered in v13.1