The grid adds a script tag to the HTML output which has the URL to the xslt file.  Other than that, the grid has no control over how or where that file comes from.  What browser are you using to view the files?  Is it possible that you have changed your browser settings to remove all temporary internet files (the browser cache)?  Also, if you click on the refresh button for a page, all cached content will be downloaded again.  Is it possible that your method for testing is involving forcing the browser to re-download the content? 

I am using IE. And no i dont have the IE set to delete all the content.

What confuses me big deal, is that i have set the cache and all. And the only file that is not being  cached is the ig_WebGrid.xslt, the rest of the files are being cached, images and .js and other.

I really dont know what is going on with this. Our pages use Infragistics heavily, and therefore this specific file produces an important overhead, if it would be requested just once each time the page is requested... But is being requested 8 times, in the page I am working on right now, because there are 8 Infragistics controls on the page. And this is each time the page is being requested.

I will keep researching on this, and i hope i can find where i am mistaken.

Thanks for your answers!

Regards.-

Dyzann,

I always enjoy a new challenge.. I decided to try and reproduce this myself and I ran into something interesting.  As you already noted - the request header has "pragma no-cache".  I had assumed this was a response header when I first read your post.  So, I dug some more, and found that we're dynamically loading the XSLT file - it's not being imported through a tag.  There's nothing wrong with this, but Microsoft mentions in the documentation that this pattern is used for "dynamic content".  Dynamic is another word for "we better not cache this". 

My guess right now is that the implementation of the Microsoft XMLDom.load method sets this request header to prevent headaches for those who are serving up dynamic XSLT files.  Again, this is just an assumption becasuse I was able to find very little documentation on how this works. 

As a workaround, I decided to try using the loadXML method instead, and manually requesting the XSLT file with an XMLHTTPRequest.  The result is extremely promising, since Fiddler now doesn't even show a request for the file happening!  The following code replaces a method in ig_webgrid_dom.js

function igtbl_XSLTProcessor(xsltURL)
{
      if(!xsltURL)
              return null;
       if(ig_csom.IsIE)
       {
              var xslt=ig_createActiveXFromProgIDs(["MSXML2.FreeThreadedDOMDocument","Microsoft.FreeThreadedXMLDOM"]);
              xslt.async=false;
              var http = new ActiveXObject("Msxml2.XMLHTTP.3.0");
              http.open("GET", xsltURL, false);
              http.send();
              xslt.loadXML(http.responseText);
              var xslTemplate=new ActiveXObject("MSXML2.XSLTemplate");
              xslTemplate.stylesheet=xslt;
              this.Processor=xslTemplate.createProcessor();
       }
       else
       {
              var xmlResp=new DOMParser();
              var xmlHttp=new XMLHttpRequest();
              xmlHttp.open("GET",xsltURL,false);
              xmlHttp.send(null);
              this.Processor=new XSLTProcessor();
              this.Processor.importStylesheet(xmlResp.parseFromString(xmlHttp.responseText,"text/xml"));
       }
}

Amazing! Thank you very much!

I changed the code you indicated me, and now the cache is working fine (I verified this with fiddler).

That problem was driving me crazy! I should go church and pray for you! You saved my life!

Regards.-

Glad I could help!

Hello Rumen,

Yes, actually we ended up implementing one of the options you mention.

What we did was create a script with the following content, that is included at the end in every page:

function igtbl_XSLTProcessor(xsltURL)
{
      if(!xsltURL)
              return null;
       if(ig_csom.IsIE)
       {
              var xslt=ig_createActiveXFromProgIDs(["MSXML2.FreeThreadedDOMDocument","Microsoft.FreeThreadedXMLDOM"]);
              xslt.async=false;
              var http = new ActiveXObject("Msxml2.XMLHTTP.3.0");
              http.open("GET", xsltURL, false);
              http.send();
              xslt.loadXML(http.responseText);
              var xslTemplate=new ActiveXObject("MSXML2.XSLTemplate");
              xslTemplate.stylesheet=xslt;
              this.Processor=xslTemplate.createProcessor();
       }
       else
       {
              var xmlResp=new DOMParser();
              var xmlHttp=new XMLHttpRequest();
              xmlHttp.open("GET",xsltURL,false);
              xmlHttp.send(null);
              this.Processor=new XSLTProcessor();
              this.Processor.importStylesheet(xmlResp.parseFromString(xmlHttp.responseText,"text/xml"));
       }
}
igtbl_XSLTProcessor.prototype.addParameter=function(name,value)
{
      if(!this.Processor) return null;
      if(ig_csom.IsIE)
            return this.Processor.addParameter(name,value);
      else
            return this.Processor.setParameter(null,name,value);
};
igtbl_XSLTProcessor.prototype.transform=function()
{
      if(!this.input)
            return false;
      if(ig_csom.IsIE)
      {
            this.Processor.input=this.input;
            this.Processor.transform();
            this.output=this.Processor.output;
      }
      else
            return this.outputDocument=this.Processor.transformToDocument(this.input);
      return true;
};

The results are just as before, caching works, so the XSLT is only downloaded once.

Thanks for your response!

Hello Dzyann,

Javascript is a prototype language, so even though the original script comes from embedded resources, if you create a function with the same name (from what I see in Tony's fix) and place it after the original declaration, it will override (replace) the original one. So one of the things to try is to place Tony's javascript fix at the very bottom of your page and see if it works for you.

The second option you have is to switch from using internal assembly resources to external ones, with the fix applied. This should not be that difficult, setting JavaScriptFileName and Path should be enough.

The third option is to contact Developer Support directly, but even if this is entered in our queue, it will get some time before it gets fixed / tested and released in a HotFix.

Hi Tony,

First of all, let me tell you, your previous fix worked like a charm, so thanks again.
However, now we are having the same issue in another application that doesn't have the javascript files deployed along with the site, but rather lets the ultrawebgrid use its embedded resources, so we can't apply your fix by changing the JS directly.

Any ideas on how to get around this?