You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
We are trying to create a reusability/baseline style suite of RCL's that include uSync definition files so that they can be installed into a site and imported to give a starting point. However the idea is things are "modular" so what you have depends on which RCL's you install and their dependencies. The problem is uSync doesn't read the definition files from the RCL's.
Describe the solution you'd like
There are two possible ideas that could work as solutions:
Having investigated how the uSync source code works, it would great it the SyncFileService was updated to use the file system provider instead of interacting with System.IO directly. System IO, as I understand it, accesses the file system directly, where as if it were to use a files system provider it would pickup the RCL locations. Additionally if the SyncFileService had the file system "provider" injected in then different file systems (blob storage for example) could be used to store the uSync files.
The second idea (that is not fully formed at this time as only manifested while writing the above) is that if the current SyncFileService was made abstract or it's methods overrideable and had an interface on it, then it could easily be overridden/partially overridden so someone could create a custom version for only parts of the service - in the example above the only methods that need to be overriden would be GetFiles and possible OpenRead as they would need to consider both System.IO and a custom provider - writing would then fall back to System.IO as normal.
Describe alternatives you've considered
Considered using item templates but can't have dependencies on other templates (i.e. installing 1 template installs additional ones automatically), considered content by code - but this is too much of a break from standard Umbraco behaviour, have also considered custom migrations that write the file to disk during start up but there is a risk of incorrect overrides.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
We are trying to create a reusability/baseline style suite of RCL's that include uSync definition files so that they can be installed into a site and imported to give a starting point. However the idea is things are "modular" so what you have depends on which RCL's you install and their dependencies. The problem is uSync doesn't read the definition files from the RCL's.
Describe the solution you'd like
There are two possible ideas that could work as solutions:
Having investigated how the uSync source code works, it would great it the SyncFileService was updated to use the file system provider instead of interacting with System.IO directly. System IO, as I understand it, accesses the file system directly, where as if it were to use a files system provider it would pickup the RCL locations. Additionally if the SyncFileService had the file system "provider" injected in then different file systems (blob storage for example) could be used to store the uSync files.
The second idea (that is not fully formed at this time as only manifested while writing the above) is that if the current SyncFileService was made abstract or it's methods overrideable and had an interface on it, then it could easily be overridden/partially overridden so someone could create a custom version for only parts of the service - in the example above the only methods that need to be overriden would be GetFiles and possible OpenRead as they would need to consider both System.IO and a custom provider - writing would then fall back to System.IO as normal.
Describe alternatives you've considered
Considered using item templates but can't have dependencies on other templates (i.e. installing 1 template installs additional ones automatically), considered content by code - but this is too much of a break from standard Umbraco behaviour, have also considered custom migrations that write the file to disk during start up but there is a risk of incorrect overrides.
The text was updated successfully, but these errors were encountered: