This project is read-only.

mdo:assign broken in 2.5.0

Feb 1, 2011 at 11:42 PM


I think something is broken now with mdo:assign: for example the following code was running good with pervious version:


<xsl:variable name="ws2">Context.Session[{{$userSession}}]</xsl:variable>
<xsl:execute select="mdo:assign($ws2, '')" />


but now gives me an error (no matter if I set a value which is non empty):

System.Xml.Xsl.XslTransformException: An error occurred during a call to extension function 'assign'. See InnerException for a complete description of the error. ---> System.NullReferenceException: Object reference not set to an instance of an object.

at Findy.XsltDb.ReflectionTools.PF..ctor(Object obj, Type type, String Name)
at Findy.XsltDb.ReflectionTools.SetPropertyValue(Object obj, Type type, String name, Object value)
at Findy.XsltDb.Helper.assign(String name, Object value)
--- End of inner exception stack trace ---
at System.Xml.Xsl.Runtime.XmlExtensionFunction.Invoke(Object extObj, Object[] args)
at System.Xml.Xsl.Runtime.XmlQueryContext.InvokeXsltLateBoundFunction(String name, String namespaceUri, IList`1[] args)
at <xsl:template match="/">(XmlQueryRuntime {urn:schemas-microsoft-com:xslt-debug}runtime)
at Root(XmlQueryRuntime {urn:schemas-microsoft-com:xslt-debug}runtime)
at Execute(XmlQueryRuntime {urn:schemas-microsoft-com:xslt-debug}runtime)
at System.Xml.Xsl.XmlILCommand.Execute(Object defaultDocument, XmlResolver dataSources, XsltArgumentList argumentList, XmlSequenceWriter results)
at System.Xml.Xsl.XmlILCommand.Execute(Object defaultDocument, XmlResolver dataSources, XsltArgumentList argumentList, XmlWriter writer, Boolean closeWriter)
at System.Xml.Xsl.XmlILCommand.Execute(XmlReader contextDocument, XmlResolver dataSources, XsltArgumentList argumentList, XmlWriter results)
at System.Xml.Xsl.XslCompiledTransform.Transform(XmlReader input, XsltArgumentList arguments, XmlWriter results, XmlResolver documentResolver)
at Findy.XsltDb.Transformer.DoTransform(XslCompiledTransform t, XmlReader xr, XsltArgumentList xslArg, StringWriter sw)
at Findy.XsltDb.Transformer.TransformRelease(String xml, String xsl, Helper h, String html, Boolean IsSuper)
at Findy.XsltDb.Transformer.JustTransform(String xsl, String xml, Boolean debug, Boolean IsSuper)
at Findy.XsltDb.Transformer.Transform(String xml, String xsl, Boolean IsSuper)
at ajax.Execute(HttpContext context)
at ajax.ProcessRequest(HttpContext context)


I suspect some other problem with mdo:session within mdo:service, but have to check this better tomorrow.

Feb 2, 2011 at 6:30 AM


I have the following code working

<xsl:execute select="mdo:assign('Context.Session[asd]', 'qwe')" />
<xsl:value-of select="mdo:aspnet('Context.Session[asd]')"/>

So it seems you have troubles with session itself. If session is disabled for your web application you may get this error as Session object is null.

Feb 2, 2011 at 6:59 AM


I missed that you are talking about mdo:service... Yes, this is a bug with ashx. After I've changed mdo:service to ashx handler it has no Session object and maybe other objects of current context... I must tink what to do with this...

  • When using aspx DNN performs "smart" redirect in case of https protocol,
  • When using ashx It has no session and maybe something else.

So I need a deeper view on the problem...

Feb 2, 2011 at 9:05 AM


it is all due to the same bug: I was wrong about mdo:assign, that's working but... it does no more work after an ajax call (mdo:ajax, I was missing this detail).

My assign call is in the module main template, but the mdo:ajax call is now based on the new ahsx handler (ajax.ahsx instead of .aspx), so is no more supporting working on session objects - at least I believe this is the cause.

This can be acceptable for mdo:servces, to which you can always pass session variables in querystring if you need them (thought cannot write new values), but I feel it as a limit with mdo:ajax. What about going back to aspx for the ajax handler? 

The problem with https redirects, if I'm not missing something, only comes out when you enable "SSL Enforced" on your site, not with SSL itself, and can be solved in skin: so there's no absolute need to have ahsx handlers. Am I wrong?


Feb 2, 2011 at 9:08 AM

Mmmm... what about this?

Feb 2, 2011 at 9:20 AM

Yes, this is a solution.

I  changed ws.ashx as follows

public class ws : Findy.XsltDb.Handlers.WsBase, System.Web.SessionState.IRequiresSessionState

and it works fine. A add this interface in next version.

Feb 2, 2011 at 9:24 AM

So urgent fix is adding this interface to handlers in ws.ashx and ajax.ashx under ~/DesktopModules/XsltDb

Feb 2, 2011 at 9:36 AM


glad it works. Yes fix is needed, even if urgency is not high for me - I disabled session writing for the moment in this module, and can wait some days.


Feb 2, 2011 at 8:40 PM

Fixed in 02.00.51

Feb 2, 2011 at 9:07 PM

Seen it (and installed it), thanks :)

Yumm.. what about the new mdo:page-validate? Sounds interesting :-))

Feb 3, 2011 at 6:03 AM

As you remember I removed Page.Validate() that was called each time XsltDb is rendered. Instead, I provided a way to call it manually. mdo:page-validate just calls Page.Validate() or Page.Validate(groupName). 

Feb 3, 2011 at 2:44 PM

Good, I have to get back testing with forms then!

A couple of stupid issues:

  • I am not able to get back the "edit xsltdb" button for a module; I tried both setting XsltDb.EditorEnabled='True' and deleting the setting from db, but nothing happens;
  • mdo:setup does not support mdo:header, like it does not support any mdo extension right? 
Feb 3, 2011 at 4:52 PM

1. XsltDb caches settings. I'm not sure clearing cache via Host/Settings is enough. But you can create a simple module

<xsl:if test="mdo:param('@clear')">
      <xsl:execute select="mdo:clear-xsltdb-portal-settings-cache('')" /> 
<a href="{mdo:jsubmit('@clear',1)}">Clear cache</a>

This module clears cache completely (not only xsltdb portal settings as it named).

2. Yes, mdo:setup does not support mdo:* extensions. I'm thinking about how to friend mdo:setup simplicity and common XsltDb flexibility, but I have no enough time at the moment. Have to work hard...

3. About mdo:header. I see you wrrote a comment to the help page for mdo:header. I don't get notified about such comments... So, please, post here in forum instead of wiki pages. Actually, I just missed key attribute in description. Now description is updated. You can easily avoid duplications.

Feb 3, 2011 at 10:54 PM

1. Thanks, will test this tomorrow.

2. Good if you have to work! :-) Anyway with <markup> sections you can do many things.

3. Very good, I'm converting all of my modules to use this method instead of my functions. Yours is working better ;)


Since we're here.... we miss an important thing now that we can package modules: error logging.

I mean, when a module throws an error you can see it if logged as supervisor (or admin, I suppose). But there are times, for example when you call mdo:services and the fault is there, when you just can't see the error output if not debugging, or using tools to debug ajax calls, or calling the url directly: all things non-developers often can't do. And if we package modules, they will be installed by people that are not programmers, and/or not always able to debug a problem. 

If we get errors logged to DNN eventlog, at least we have the possibility to ask users to give us errors log to analyze problems. And writing to DNN eventlog via EventLogController is trivial - I bet you can add this within 5 minutes. Given your priority is point 2 above, of course! :-D

About logging, I also made a quick test with log4net recently - great library. I have a prototype I'll share asap. Eventlog is better for the above purpose, but could be useful as an extension to xsltdb capabilites.

Hear you soon!