I've been doing quite a bit building IPublishedContent objects outside of Umbraco's content tree using an attached document type for Merchello's IProductContent so that we do not need to create a content node for ever product in a stores catalog. The process is also pretty similar to Nested Content.
In Merchello's case, property values are saved as a JSON array and stored in it's own database table that has an association with the Umbraco content type so that we can fetch and generate the properties using the standard pre value editors, etc.
90% of the time this works without issue. However, the MultipleTextString data type stores its values using Environment.NewLine as a delineator.
When serialized to JSON this is turned to \r\n
Merchello, internally corrects this to use the XML values that are currently respected by the property value converter
e.g. <value>First bullet</value><value>Second bullet</value> ...
However, In the Umbraco Core code Shannon has a note to inquire with Stephan about why that bit of code is required.
//SD: I have no idea why this logic is here, I'm pretty sure we've never saved the multiple txt string
// as xml in the database, it's always been new line delimited. Will ask Stephen about this.
// In the meantime, we'll do this xml check, see if it parses and if not just continue with
// splitting by newline
For us, it would be great if that was not removed (or if it is, split also on something like):
// split the value into multiple lines
var lines = value.ToString().Split(new[] { "\r\n" }, StringSplitOptions.None);
I was asking not to remove an alternative to the input value being delineated by Environment.NewLine but really don't care what the alternative is, meaning if, instead of XML, you wanted to change it a JArray, it'd be just fine as long as we knew what the preferred alternative was changing to =)
Ideally, IMO the stored database format would change and there would be no need to have an alternative.
LOL, I have it handled on my end which is why I made the pull as a concept to try to illustrate the issue.
For Umbraco, if you there was a need to convert database saved values before they were sent to the converter (like maybe if you change things up in V8) and you wanted to change what is actually stored (like a JSON array for the Multiple Text String instead of a Environment.Newline deliminated string) this would allow for not having to convert the entire database, by adding a layer that would allow for handling legacy values, and on the next save, the value would be stored in the corrected format.
If extended, this sort of thing may also help in correcting data values for indexes, etc.
In Merchello, we use virtual content pages to represent products, so there is not a direct tie to the cmsPropertyDataValue. Rather we save all property data in JSON array in a separate database table and build up the PublishedProperty using those values. So, if a core property object value were to change, our stored values would be invalid.
No worries here if you just close the PR. Next time I'll post a GIST before doing the PR =)
Keep the XML values in the MultipleTextStringValueConverter?
I've been doing quite a bit building IPublishedContent objects outside of Umbraco's content tree using an attached document type for Merchello's IProductContent so that we do not need to create a content node for ever product in a stores catalog. The process is also pretty similar to Nested Content.
In Merchello's case, property values are saved as a JSON array and stored in it's own database table that has an association with the Umbraco content type so that we can fetch and generate the properties using the standard pre value editors, etc.
90% of the time this works without issue. However, the MultipleTextString data type stores its values using
Environment.NewLineas a delineator.When serialized to JSON this is turned to
\r\nMerchello, internally corrects this to use the XML values that are currently respected by the property value converter
e.g.
<value>First bullet</value><value>Second bullet</value> ...However, In the Umbraco Core code Shannon has a note to inquire with Stephan about why that bit of code is required.
For us, it would be great if that was not removed (or if it is, split also on something like):
Hey rusty,
Have pulled in your PR with the notes, but maybe you can elaborate on the issue and/or create a PR to 'fix' (if there is a fix?)
I'm not sure if you are asking that we simply don't change something or if we do change something.
Sorry for the confusion.
I was asking not to remove an alternative to the input value being delineated by
Environment.NewLinebut really don't care what the alternative is, meaning if, instead of XML, you wanted to change it aJArray, it'd be just fine as long as we knew what the preferred alternative was changing to =)Ideally, IMO the stored database format would change and there would be no need to have an alternative.
I submitted a pull request that illustrates a concept to fix these sorts of things. https://github.com/umbraco/Umbraco-CMS/pull/1252
I think the concept may be helpful if ever refactoring the call to
PublishedPropertyType.ConvertUsingDarkMagic(source)inPropertyValueConverterBase.Hey rusty, I guess is still don't fully comprehend what this is all about even after looking at your PR.
Are you able to provide a simple concrete example of what this is doing and when it is necessary?
LOL, I have it handled on my end which is why I made the pull as a concept to try to illustrate the issue.
For Umbraco, if you there was a need to convert database saved values before they were sent to the converter (like maybe if you change things up in V8) and you wanted to change what is actually stored (like a JSON array for the Multiple Text String instead of a Environment.Newline deliminated string) this would allow for not having to convert the entire database, by adding a layer that would allow for handling legacy values, and on the next save, the value would be stored in the corrected format.
If extended, this sort of thing may also help in correcting data values for indexes, etc.
In Merchello, we use virtual content pages to represent products, so there is not a direct tie to the cmsPropertyDataValue. Rather we save all property data in JSON array in a separate database table and build up the PublishedProperty using those values. So, if a core property object value were to change, our stored values would be invalid.
No worries here if you just close the PR. Next time I'll post a GIST before doing the PR =)
is working on a reply...