With Umbraco 7 being angular, it has opened up a lot of possibilities that were previously not possible or at least very difficult in v6. One such pattern that a few packages are making use of (Archtype, Vorto and my next package) are using nested values.
Using angular, it's very easy to reuse property editors and grab their values which is ultimately what makes these packages possible, however it appears there is an inherant issue with these packages that I think is worth getting some HQ discussion on (as I see this becoming a staple technique, so would be good to get it right, rather than a hacky fix).
For a little background, checkout the Archtype issue here:
TL;DR because some property editors may have some back end processing during save/loading to/from the database, these converters don't get called on nested values, so important steps in maintaining the validity of these properties data are being missed resulting in corrupt data values.
It would be good to figure out what would be the best way to handle this kind of situation so that we can ensure values are persisted correctly, and we have a standard way of doing this for existing and new packages.
Some time ago I have put together a PDF trying to summarize all the existing, legacy or new or whatever, transformations that can take place on a property value. You can find it here: Content Property Values For Dummies. I use it as a reference whenever I get lost.
It shows that there is a difference between the Editor value (what's used by Angular) and the Database value (what's stored in the database) and, also, the Xml value (what's stored in the XML cache and will be processed by IPropertyValueEditor).
The difference between Database and Xml is because of legacy editors (lists with publishing values) that store identifiers in the database, but store the corresponding prevalues in the xml cache. It is a corner case that should be handled differently, and that we would like to remove in the future. So in almost every case, and certainly in the future, Database should == Xml. Otherwise things become quite complicated and I don't want to go into it here.
The difference between Editor and Datbase is... the subject of the discussion here I suppose. By default the only logic in there is clr-to-json conversion, but some editors add extra processing. The rich text editor filters macros, the file upload editor takes care of files... and as far as I see it at the moment, these operations have to take place at some point. I don't think we can get rid of that step.
Might be wrong, but thinking we should provide a nice, easy & documented way to give access to these conversions. I thought I'd be able to put together some code here, but that's not possible at the moment. Too many internals. So, yes... need to do something about it.
From an (advanced) user point of view, what would be the proper API? Would something that takes a DataTypeDefinition and a value, and returns a string, be the right level of abstraction?
Yea, I guess legacy stuff can get left behind, so I don't think that's important ATM.
Regarding the proposed API, yea, I think that would sound about right.
Would that mean, if you are doing one of these nested property editors that you'd have to create a IValueEditor C# class and implement the ConvertEditorToDb/ConvertDbToEditor and within these methods, loop over your nested values and call these newly exposed methods for each value? So then when the value goes into the DB, it's got the DB formatted strings, and when it comes out, it'll get the XML formatted value? (Xml formatted and property editor view ultimately being the same?)
Handling nested data in Umbraco 7 packages
With Umbraco 7 being angular, it has opened up a lot of possibilities that were previously not possible or at least very difficult in v6. One such pattern that a few packages are making use of (Archtype, Vorto and my next package) are using nested values.
Using angular, it's very easy to reuse property editors and grab their values which is ultimately what makes these packages possible, however it appears there is an inherant issue with these packages that I think is worth getting some HQ discussion on (as I see this becoming a staple technique, so would be good to get it right, rather than a hacky fix).
For a little background, checkout the Archtype issue here:
https://github.com/imulus/Archetype/issues/103#issuecomment-40919742
TL;DR because some property editors may have some back end processing during save/loading to/from the database, these converters don't get called on nested values, so important steps in maintaining the validity of these properties data are being missed resulting in corrupt data values.
It would be good to figure out what would be the best way to handle this kind of situation so that we can ensure values are persisted correctly, and we have a standard way of doing this for existing and new packages.
Matt
Some time ago I have put together a PDF trying to summarize all the existing, legacy or new or whatever, transformations that can take place on a property value. You can find it here: Content Property Values For Dummies. I use it as a reference whenever I get lost.
It shows that there is a difference between the Editor value (what's used by Angular) and the Database value (what's stored in the database) and, also, the Xml value (what's stored in the XML cache and will be processed by IPropertyValueEditor).
The difference between Database and Xml is because of legacy editors (lists with publishing values) that store identifiers in the database, but store the corresponding prevalues in the xml cache. It is a corner case that should be handled differently, and that we would like to remove in the future. So in almost every case, and certainly in the future, Database should == Xml. Otherwise things become quite complicated and I don't want to go into it here.
The difference between Editor and Datbase is... the subject of the discussion here I suppose. By default the only logic in there is clr-to-json conversion, but some editors add extra processing. The rich text editor filters macros, the file upload editor takes care of files... and as far as I see it at the moment, these operations have to take place at some point. I don't think we can get rid of that step.
Might be wrong, but thinking we should provide a nice, easy & documented way to give access to these conversions. I thought I'd be able to put together some code here, but that's not possible at the moment. Too many internals. So, yes... need to do something about it.
From an (advanced) user point of view, what would be the proper API? Would something that takes a DataTypeDefinition and a value, and returns a string, be the right level of abstraction?
Hey Stephen,
Thanks for the reply.
Yea, I guess legacy stuff can get left behind, so I don't think that's important ATM.
Regarding the proposed API, yea, I think that would sound about right.
Would that mean, if you are doing one of these nested property editors that you'd have to create a IValueEditor C# class and implement the ConvertEditorToDb/ConvertDbToEditor and within these methods, loop over your nested values and call these newly exposed methods for each value? So then when the value goes into the DB, it's got the DB formatted strings, and when it comes out, it'll get the XML formatted value? (Xml formatted and property editor view ultimately being the same?)
Matt
is working on a reply...