We have moved to GitHub Issues
You are viewing the read-only archive of Umbraco's issue tracker. To create new issues, please head over to GitHub Issues.
Make sure to read the blog posts announcing the move for more information.
Created by Tim Geyssens 19 Nov 2013, 08:54:37 Updated by Dan Okkels Brendstrup 11 Dec 2014, 10:52:23
Currently if an advanced prop editor (where value type is JSON) doesn't have the ConvertDbToXml it will store it's data as json in the xml cache and this is then useless when trying to output from xslt...
Suggestion: if the value type == JSON , just use the converter by default to inject into xml cache, people can then override if they don't like the automatic way
But... if we inject XML into the XML cache instead of JSON then the PropertyValueConverters will receive the XML text instead of the JSON value, which is not very efficient? Don't we want the new PropertyValueConverters to parse JSON rather than XML?
Guess we have to choose who we're most friendly with... if we want to be friendly with people writing simple and efficient converters to CLR types, we should use JSON, then ask XSL people to do something such as
<xsl:variable select="umbraco:library.parseJson(value)" /> ?
Ok then we'll add an xslt extension...
That's correct. Will need to just create an xslt extension (until the new cache is available)
I'm perfectly fine with an extension for that - a couple of things to keep in mind:
Can't set to feature planned as that makes it a swimlane on the agile board
+1 @greystate on returning the root element
I feel so dirty adding new methods to 'library' :P
This is completed with unit tests in rev: 0c226d1a2c170e7f3888aae67dd3de85af9e2a79
You can see the tests and their outcome.
Cool, thanks - looks like it's returning the document though (as mentioned earlier) - the problem with that is that it will match the "/" template when using apply-templates (that's what the cool XSLT guys do :-) which isn't the optimal solution. Selecting '''"/*"''' instead of '''"/"''' is way better for this, because then you've got the {{
Anyway, it's great that this is made possible in a familiar way (using an extension).
I'm happy to change whatever you'd like, just let me know! I'm no (longer) an xslt expert so can't remember how best to work with it anymore :-)
@Chriztian So in this example http://www.nibble.be/?p=341 what would change then? It wouldn't have the json element?
@Tim - No changes necessary - copy-of will give you the same result; but it leads you to think that you can do this:
<xsl:variable name="data" select="umbraco.library:JsonToXml($currentPage/matrix)" /> <xsl:value-of select="$data/arrayitem/arrayitem[1]" />
.. and then get "xslt" as the output - but you can't - you have to use:
$data/json/arrayitem/arrayitem[1]
to get that output.
Since the {{
@Shannon: If I submit a pull-request with the changes, we can work it out on GitHub, right?
using item instead of arrayitem is enough.json/item/item[1]
@esunxray: That totally depends on the XML nodes' names - they are called
yup true, don't have a name for my json objects so it's just an array, guess that's what gets generated by default during the conversion
Pull request would be awesome, but has to be within 24 hr with tests passing. Just keep in mind that we need to convert both objects and array
This extension works, but severely limits the usefulness of XPath traversing (since extension methods can't be called in {{match}} statements and in {{key}} definitions and many other places, as well as carrying a potential performance penalty). That problem can be solved the {{
Priority: Normal
Type: Feature (request)
State: Fixed
Assignee: Shannon Deminick
Difficulty: Normal
Category:
Backwards Compatible: True
Fix Submitted:
Affected versions:
Due in version: 7.0.0
Sprint:
Story Points:
Cycle: