Apr 6, 2011 at 6:43 PM
Edited Apr 6, 2011 at 6:49 PM
tnx for the wow - don't be to shy to
review us - it helps spread the word ;-)
If you have a data field with xhtml in it, and you emit it from a C1 Function - like a C# Function returning XhtmlDocument or an XSLT function - you need to emit the xhtml "as DOM" and not as a string. If you treat it like a normal string automatic xml string
encoding will occur.
In an XSLT Function you would change <xsl:value-of select="@HtmlDescriptionField" /> to <xsl:value-of select="Parser:ParseWellformedDocumentMarkup(@HtmlDescriptionField)" xmlns:Parser="#MarkupParserExtensions" /> and ensure that
'Function calls' has a call to the Composite.Xslt.Extensions.MarkupParser function.
In a C# scenario returning XhtmlDocument, XElement etc. you would change code like myXelement.Add(
teamMember.HtmlDescriptionField ) to myXelement.Add( XElement.Parse(teamMember.HtmlDescriptionField) ).
In ASP.NET Web Forms and MVC scenarios you just print the value raw as you normally would.
Seems we don't have this on docs.composite.net yet - a pretty obvious use case we should cover... we will fix.
> Where do Visual function code (be it xslt or w/e) go when created? Or is it some form of magic sugar happening in the .dll?
They are handled by their respective "Function Providers" - if you browse the source code, look under Composite.Plugins.Functions.FunctionProviders. XSLT functions compile the XSLT source once and then invoke it with input/function results on render, visual
function is doing some fancy 'dynamic expression tree buildup, compile and invoke' at first runtime etc. (as far as I remember).
> Where can I find the xslt function API reference?
In the Functions perspective, open All Functions, Composite.Xslt.Extensions, and use "Generate Documentation" on the folder. This contain Xslt extensions you can get by including the function call on your XSLT. The individual XSLT extension will then 'document
itself' in your xslt preview once it is included. Also see
> A general high level architectural overview of the pipeline might be nice.
We don't have it documented at the moment - but try adding ?c1mode=perf to a page rendering (require 2.1) and you will see a call tree. This may give you some indication of the page rendering process.