xsl:include failing in IE and Chrome

Topics: Developer Forum
Aug 18, 2009 at 8:02 PM

We are using this SharePoint AJAX Toolkit and I am trying to simplify some of my web parts which use portions of XSL that is identical.  So, I figured I would use the <xsl:include> or <xsl:import> statement.

What I have found is that the client-side xsl transformer for IE7, IE8 and Chrome3 don't seem to handle this.  Firefox has no problem.

I originally thought I saw (through Fiddler) that the request for the XSL was denied with a 401 and that the browser xsl transformer was not going through the NTLM handshake process as it was for everything else.  However, I haven't seen any requests at all for my included file within Fiddler when using IE lately so now I am second guessing myself.

Does anyone else have success or horrer stories with xsl:include or xsl:import?

I am currently hard-coding my xsl:include URL to keep things simple, but realize that I may want to make that depending on the SharePoint URL.

Aug 18, 2009 at 10:14 PM

Hey Kliemohn

I'm glad you're using the toolkit succesfully! :) As a limitation of the browser technology, which forces you to use a lowest common denominator approach, I would advise you to NOT use <xsl:include> or <xsl:import> in  the client. These aren't supported in all of the standard client runtime XML libraries. At least, we were not able to get them to work in all the browsers. :)

What we do instead is process these in a server side handler if needed. Call a handler that processes the includes and combines them into one xslt output. My advise: keep the XSLT as simple as possible. :) And try not to create an XSLT per webpart, but instead define views on data schemas. For example, lists of users can be defined as a data schema, and you may have several views defined on that class of data (simple, expanded, etc.).

There's some additional js methods on the XmlComponent such as OnClientLoad that you can pass from the web part property to the javascript. Let me know if you need any pointers, and be sure to use the latest source code!

Aug 19, 2009 at 1:44 PM

Hi Daniel,

Thanks for the pointers and for providing the framework.  It is working quite well for us.

I think we'll just use the copy/paste approach for now.  We already have multiple XmlControls per web part which is helping vastly with keeping our XSLT and the rest of our logic simple.  This is just one case where I didn't want to break it up further but had a good bit of XSL that was common between two XmlControls (which happen to be in separate web parts).

I like your idea for a server side handler, but that is overkill for us now.  It pains me to use the copy/paste approach, but the pragmatic side of me knows that there are times when this is appropriate.


Kirk Liemohn