Namespaces and other improvements to XSLT templates

Sten Hougaard

Posted on 12/10/2011 09:11:25

Hi,

Custom code and othere extentions to XSLT through namespaces
I would love it if the XSLT support in DW could be taken more serious. For instance by adding some kind of Namespace based extention to it. Say you want to add your own C# code to the XSLT. Today you can add inline C# code, but there is no cashing and resusing it is hard.

If I got the option to add a DLL to the BIN folder and I then through some .NET magic (Read: I do not know how, but it should be possibel :-)) could include my .NET classes to the XSLT - that would make many things easier in XSLT. For instance I could have a namespace "Bleau" which had a method: "replace(String source, String search, String replace, Object options)" - then I could do a replace like this:

<xsl:value-of select="Bleau:replace(description, 'a', 'b')" />

Some general utilities offered by a DW namespace.
Dynamicweb could then offer some shared function allowing common tasks to be available to frontend developers who use XSLT. That would make DW stronger and probertly make XSLT templates a more popular path. Imagine this:

<xsl:value-of select="DW:translate(search, 'Søg', global)" />
<xsl:value-of select="DW:addStylesheet('/files/templates/design/dw/css/myModuleRelated.css')" />

Caching of compiled XSLT templates.
Adding cashing of the compiled XSLT template would increase the performance.

I know that in DW8 you will address XSLT templates, but perhaps you should try telling about your plans so that people can comment and perhaps give some feed back.

/Sten Hougaard

Replies

Nuno Aguiar

Posted on 12/10/2011 11:06:34

Hi Sten,

I partly agree with you, but that is raising a concern. Until now one of the features of the software is the division of frontend from backend developement and with that some good security issues. Wouldn't this open a door to hacking situations?

I understand it would only go as far as someone actually knows the namespaces and what they do and how they break, but still, we have had some SQL attempts over the years that we know of and probably other different attempts that simply did not get registred.

However, getting a peek on what's to come is always a wish :P

Nuno

Sten Hougaard

Posted on 12/10/2011 13:21:01

Hi Nuno,
The code in the namespace can only be executed from with the XSLT transformation. Other CMS systems like Umbraco and Sitecore has been using namespaces for years. I am frontend developer and cannot rule out security issues, however if it exists - why have Umbraco and Sitecore CMS been using it for years and continues to do so?

The same applies to the division of frontend and backend. I see no problem with this, as it should be backend developers working with Dynamicweb partners who create new .NET DLL (classes/namespaces). They would do so to support the frontend developer, just as when they add extra data to the XML (by request of a frontend developer). It is also to optimize the XSLT development process. Why should it be so difficult and "complex" to get something in XSLT templates which in HTML templates is a piece of cake? (for instance: ).

If Dynamicweb is serious about XSLT and wants to make people choose the XSLT template path they need to focus and listen. Remember also that it is a great plus for Dynamicweb if they use a common methode like XSLT instead of something Dynamicweb specific like HTML tags. Working as a frontend developer you need to consider where you invest your time. If a system is very unique and any time put into becoming a super user cannot be reused anywhere else, it is sort of wasted time.

/Sten

Nuno Aguiar

Posted on 13/10/2011 11:20:49

Hi Sten,

Thanks for the input. I think you mentioned some real important issues and put things under perspective. I would love to hear about Dynamicweb's point of view also. Let's see it someone has something to say about that.

Best Regards,
Nuno

Developer forum

Namespaces and other improvements to XSLT templates

Replies