VB or C# within xslt (xslt only used for the call) bad practice?
Hi!
Is it considered bad practice to do all xslt-work with c# or vb (with node factory), only calling the c#/vb-function from xslt?
It does speed up my coding alot, also complex xlst's are not easy to read. And I found it easy to stumble upon some performance issues coding in xslt when you are not completely used to that language.
One might say that this inline vb/c# could do fine until the routine gets so well designed it's worth making into a .dll, but in a .dll one looses the flexibility.
App_Code classes can't be exposed to XSLT yet. You have to build an assembly and add it to xsltExtensions.config to get it exposed to XSLT, plus your class and the methods you want exposed to XSLT must both be declared as public static.
4.1 will introduce App_Code XSLT extensions with a simple attribute [XsltExtension] to add to your class which will then make it's public static methods accessible to XSLT.
P.S. @Jonas, you can execute that code in XSLT without a single line of VB.
Script inside XSLT is considered bad practice by Microsoft as every time an XSLT file with <msxml:script> is called, it's compiled into the Windows temp directory. On every request. Without per-application or per-user caching. Try that on a high-volume site = run out of disk space and watch your server crash and burn. See here for full brief - and I quote, "XSLT scripting should be enabled only if you require script support and you are working in a fully trusted environment."
Many of the xlt's out there do use <msxsl:script>, like Xslt-search, the strong recommendation would be moving the script-code to XSLT extensions at the moment then, right? And when we have 4.1 we can also use app_code for such.
Petr, ok, that would have been perfect if one could see the App_Code-folder in the UI, with editable files. Anyone did that already? I do think I've seen it been discussed somewhere, but I cannot find it now.
I did write an App_Code editor (as an extension of the User Control editor - as a favour to Doug), but never publicly released it - as it was not production safe. i.e. any typos would cause a compiler exception and render your entire Umbraco install un-usable!!! It scared the crap outta me - so no way was I releasing it!
Anyway, the good news is that after a chat with Benjamin, he came up with a solution, (to pre-compile/test the code before saving) ... so I have passed the source-code over to him... and he is working his magic on it! Very exciting I know! :-D
In the meantime, you could use <script runat=server> tags in User Controls ... and edit them with my editor package?
But wait, editing app_code-files live would kill the app_pool
and giving users that are online at the moment a hard time, wouldn't it? A pre-compile/test, cool, but also - a big red warning about the recompile to be awaited at save. Peerhaaaps not such a good idea afterall... A bit like adjusting the motor while driving (with passengers).
And about the temp-files, "By disabling the debug mode in the web.config (which you should do for any production site) you'll ensure that XslCompiledTransform() doesn't create temporary files... at least in the majority of cases." (Douglas Robar http://blog.percipientstudios.com/2009/9/21/advanced-xslt-with-net-namespaces.aspx)
So the inline net-code in XSLT-files should not be considered bad design imho. (Don't know about those kittens Niels mentioned though... :-)
I've had good luck with inline .net code in xslt files -- usually for a few very simple functions that are easier in C# than in xslt and not worthy of an entire xslt extension. The exception being XSLTsearch, which uses rather a lot of them for both code clarity and performance. It can work well.
But as I've learned, the idea of inline .net in script blocks isn't quite as flawless as I'd once thought. For lots of reasons (temp files, macro cache-ability, security issues, macro performance) I will be moving all my script blocks to the app_code folder in the future (umbraco 4.1 and later). The benefit of using app_code is that the code is still easy to edit without requiring any visual studio activity at all, and the macros are faster and more cache-able. Oh, and they'll run in a medium trust environment and won't populate your system's temp folder with temporary files. Sure, you bounce the application pool, but that also happens when you upload a new dll or touch the web.config file (things that should happen rarely on a live site).
The process of moving from a script block to app_code (in umbraco 4.1) is almost entirely one of copy-paste, with a couple lines shoved above them. That's really all there is to it. So "upgrading" an existing xslt with a script block to use app_code instead is simple. I've got two blog posts in the wings to explain and demonstrate. And XSLTsearch 2.9 and onward will use this approach as well.
Ok, I get it. Case closed. Thanks for enlighten me. I did run some tests with debug=false and quite some traffic that did not convince me about the bad habits of inline .net-code, but, having code in app_code+medium trust+cache-ability will make me move to app_code or xsltextensions. Plus, following the good example of xsltsearch.
One question here, about xsltsearch, why are you choosing app_code instead of xsltextensions? Is it for devs to have the ease of tweaking it?
VB or C# within xslt (xslt only used for the call) bad practice?
Hi!
Is it considered bad practice to do all xslt-work with c# or vb (with node factory), only calling the c#/vb-function from xslt?
It does speed up my coding alot, also complex xlst's are not easy to read. And I found it easy to stumble upon some performance issues coding in xslt when you are not completely used to that language.
A site-map could easily be created this :http://our.umbraco.org/wiki/reference/xslt/snippets/xslt-snippet-for-vb-coders/list-all-subpages-below-current,-vb-in-xslt: for example.
One might say that this inline vb/c# could do fine until the routine gets so well designed it's worth making into a .dll, but in a .dll one looses the flexibility.
Kind regards / Jonas Eriksson
It's horrible practice - and for each of these XSLTs saved, a kitten dies somewhere in the world ;-)
You should consider using app_code classes instead if you'd like to keep the deployment flexibility.
What I like is to be able to edit the code as easy as the xslt's.
App_Code classes can't be exposed to XSLT yet. You have to build an assembly and add it to xsltExtensions.config to get it exposed to XSLT, plus your class and the methods you want exposed to XSLT must both be declared as public static.
4.1 will introduce App_Code XSLT extensions with a simple attribute [XsltExtension] to add to your class which will then make it's public static methods accessible to XSLT.
Best,
Benjamin
P.S. @Jonas, you can execute that code in XSLT without a single line of VB.
Script inside XSLT is considered bad practice by Microsoft as every time an XSLT file with <msxml:script> is called, it's compiled into the Windows temp directory. On every request. Without per-application or per-user caching. Try that on a high-volume site = run out of disk space and watch your server crash and burn. See here for full brief - and I quote, "XSLT scripting should be enabled only if you require script support and you are working in a fully trusted environment."
Best,
Benjamin
Ok, thanks Benjamin, I was not aware of that.
Many of the xlt's out there do use <msxsl:script>, like Xslt-search, the strong recommendation would be moving the script-code to XSLT extensions at the moment then, right? And when we have 4.1 we can also use app_code for such.
When I need c# I call it directly from template. Not using macro or sometling like this. Simply add script with runat=server and put my code here.
Petr
Petr, ok, that would have been perfect if one could see the App_Code-folder in the UI, with editable files. Anyone did that already? I do think I've seen it been discussed somewhere, but I cannot find it now.
Hi Jonas,
I did write an App_Code editor (as an extension of the User Control editor - as a favour to Doug), but never publicly released it - as it was not production safe. i.e. any typos would cause a compiler exception and render your entire Umbraco install un-usable!!! It scared the crap outta me - so no way was I releasing it!
Anyway, the good news is that after a chat with Benjamin, he came up with a solution, (to pre-compile/test the code before saving) ... so I have passed the source-code over to him... and he is working his magic on it! Very exciting I know! :-D
In the meantime, you could use <script runat=server> tags in User Controls ... and edit them with my editor package?
Cheers, Lee.
Lee, fantastic!
But wait, editing app_code-files live would kill the app_pool and giving users that are online at the moment a hard time, wouldn't it? A pre-compile/test, cool, but also - a big red warning about the recompile to be awaited at save. Peerhaaaps not such a good idea afterall... A bit like adjusting the motor while driving (with passengers).
When I working on c# code I put it directly into template and edit it there. If code is ok, then it can be moved...
back on this again.
about the http://msdn.microsoft.com/en-us/library/system.xml.xsl.xslcompiledtransform.aspx the advice to not use inline scripting is for security reasons that applies like for all .net-code. Of course one should be careful who has access to xslt-editing.
And about the temp-files, "By disabling the debug mode in the web.config (which you should do for any production site) you'll ensure that XslCompiledTransform() doesn't create temporary files... at least in the majority of cases." (Douglas Robar http://blog.percipientstudios.com/2009/9/21/advanced-xslt-with-net-namespaces.aspx)
So the inline net-code in XSLT-files should not be considered bad design imho. (Don't know about those kittens Niels mentioned though... :-)
regards
Jonas
I've had good luck with inline .net code in xslt files -- usually for a few very simple functions that are easier in C# than in xslt and not worthy of an entire xslt extension. The exception being XSLTsearch, which uses rather a lot of them for both code clarity and performance. It can work well.
But as I've learned, the idea of inline .net in script blocks isn't quite as flawless as I'd once thought. For lots of reasons (temp files, macro cache-ability, security issues, macro performance) I will be moving all my script blocks to the app_code folder in the future (umbraco 4.1 and later). The benefit of using app_code is that the code is still easy to edit without requiring any visual studio activity at all, and the macros are faster and more cache-able. Oh, and they'll run in a medium trust environment and won't populate your system's temp folder with temporary files. Sure, you bounce the application pool, but that also happens when you upload a new dll or touch the web.config file (things that should happen rarely on a live site).
The process of moving from a script block to app_code (in umbraco 4.1) is almost entirely one of copy-paste, with a couple lines shoved above them. That's really all there is to it. So "upgrading" an existing xslt with a script block to use app_code instead is simple. I've got two blog posts in the wings to explain and demonstrate. And XSLTsearch 2.9 and onward will use this approach as well.
Hope that clarifies things at least a little.
cheers,
doug.
Doug, thanks,
Ok, I get it. Case closed. Thanks for enlighten me. I did run some tests with debug=false and quite some traffic that did not convince me about the bad habits of inline .net-code, but, having code in app_code+medium trust+cache-ability will make me move to app_code or xsltextensions. Plus, following the good example of xsltsearch.
One question here, about xsltsearch, why are you choosing app_code instead of xsltextensions? Is it for devs to have the ease of tweaking it?
Looking forward to those blog posts.
Regards,
Jonas
is working on a reply...