Products

Solutions

Resources

Partners

Community

Blog

About

QA

Ideas Test

New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeDNN Open Source...DNN Open Source...Module ForumsModule ForumsXMLXMLXML v04.03.03 Breaking change -Execution of scripts was prohibited...XML v04.03.03 Breaking change -Execution of scripts was prohibited...
Previous
 
Next
New Post
4/14/2007 11:07 PM
 

Stefan,

Had not read anything about the issue you pointed out.  The argument against using scripting inside xsl stylesheets seems sound enough.  I'm wondering how we go about using XSLT extension objects, though.  Is this usage similar to the 'static' parameters we are passing from the dropdown list of choices present in the module?  If so, then, it would we would need some way to add to those items in a custom manner.  A sort of code hook that allows Host SuperUsers to provide a custom list of extensions that can be utilized.  For example, many of my tasks involve selecting items for display of xml data by pubDate, and ExpireDate, or a custom element.  I don't need in-line scripting exactly, but do need a way to pass the 'filter' parameters to the xsl.  The current list of 'static' params doesn't provide me the flexibility of customization, or at least not in that manner that I can see.  Though, you know about that part more than me.  I'm just getting familiar with the module since you improved it.

Performance issues would be a concern with in-line scripting moreso than the security issues, so I understand the reluctance to provide it as standard.  I've no problem with that decision, just didn't know about the issue, so good call, and I certainly agree with it.

Just need some way to be able to pass a custom value parameter, that may have to be computed at runtime to be used in the xsl. Any ideas on that type of usage?  If that type of usage is available, now, could you provide an example?  Further, can XSLT extension objects be used currently?  What about an example for us?

Thanks for tending to the issue and giving some very good info about the problems.  I have not encountered the issue on my intranet, but the test site is not yet heavily used, so it's nice to know about it before we went live with that approach.  Thanks again.

 
New Post
5/24/2007 9:30 PM
 

In the past year I have worked a lot with AspDotNetStorefront which relies very heavily on the use of XSLT and XSLT extensions.  When I first started working with it I found that the extensions provided with the product were insufficient.  I added the ability to define additional extension assemblies in the web.config file.  It is fairly easy to implement this pattern and it allows you to define as many extension assemblies as you need.  In this case I would recommend not making this a web.config setting but instead using custom module settings.  To make it work, you essentially need to gather 2 pieces of data for the extension:  The extension class and the namespace to associate with the extension.  Here is an example of one web.config entry for the DotNetNuke Marketplace:

<add name="DotNetNuke Extensions" type="DotNetNukeExtensions.DnnExtensions, DotNetNukeExtensions" namespace="urn:dnn" />

Again, keep in mind that the web.config storage is not important, just that we have an assembly qualified type name and an associated namespace.  Now that we have a typename and namespace we can use

obj = Activator.CreateInstance(objType);
m_TransformArgumentList.AddExtensionObject(ext.Attributes["namespace"], obj);

to add the extension object (note: obviously there is more code associated with these two lines and it is a grossly simplified example).

The reason I prefer extension objects over scripts is that the compiled classes allow you full access to the entire DotNetNuke framework.  It also means that I can use other extension classes like those defined in the EXSLT.net project. 

In my XSLT files it is a simple matter to define my stylesheet to reference the namespace:

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:aspdnsf="urn:aspdnsf" xmlns:dnn="urn:dnn" exclude-result-prefixes="aspdnsf">

Then in my stylesheet I am free to call my custom extension methods at will:

< xsl:variable name="Images" select="dnn:GetImageUrls($ProductID, 'medium')" />

If I return an XpathNodeIterator from my extension method then I can further process the method results using XSLT.   Typically I use this technique when I want to get some XML that I can further manipulate with my XSLT. 

I have found that extensions allow you to do things with XSLT that would just be too difficult to do with pure XSLT, or to access data in a format that can be easily used in the XSLT.


Joe Brinkman
DNN Corp.
 
New Post
5/24/2007 11:41 PM
 

Joe, thank you. This is definitely the way to go. I am going to enhance XML module this way, and if you look at its road map the integration of the EXSLT was already added that way. I am currently investigating some ways to integrate custom extensions, think of plugins like the visualizers in reports.

Extensions have one downside as they require fulltrust to work.

 
Previous
 
Next
HomeHomeDNN Open Source...DNN Open Source...Module ForumsModule ForumsXMLXMLXML v04.03.03 Breaking change -Execution of scripts was prohibited...XML v04.03.03 Breaking change -Execution of scripts was prohibited...


These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out