U4-3581 - Make sure advanced v7 prop editors can also be used from xslt

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:

1. In a view/template it's much easier to handle an {{}} element than any exception it may throw
2. The extension should return the root ''element'' of the XML - e.g., by using something like {{value.Select("/*")}} instead of the ''document node''

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 {{}} element directly, and you can select stuff just by simple XPaths instead of having to use {{$data/json/xxx}}.

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 {{}} element is something we wrap (to always have a single root element), it would be nicer to have the "pointer" on that by default, so we dont need to explicitly use it in every XPath expression.

@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 in Tim's example, so the XPath has to use that.

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 {{}} feature proposed in [pull request #588|https://github.com/umbraco/Umbraco-CMS/pull/588].