Hi Guys,
A quick question.
I am working on application left to me my previous employees. This application is a web application that is often installed by third parties on their own web servers and the application makes use of Infragistics controls.
The problem I have is this:
In many places the Javascript file names have been hardcoded into the application, which used to work nicely, however as the controls change the files required the hardcoded file paths become a real problem. For instance I have a datepicker with the following:
'Me.JavaScriptFileName = "MyIgScripts/ig_webdropdown.js"
'Me.JavaScriptFileNameCommon = "MyIgScripts/ig_csom.js"
'Me.CalendarJavaScriptFileName = "MyIgScripts/ig_calendar.js"
When upgraded to the latest version of infragistics the ig_csom.js is no longer required, however because the paths are hardcoded as shown it still looks for these files.
The reason this has been done is so the project can be redistributed with no requirement to have infragistics control scripts installed in the default directory. Basically we have to put these scripts in a subfolder off the main application path, so that the install can be easily x-copied etc.
What I was wondering is if you have any advice on how I should handle this scenario, I'd imagine it's quite common. Our experience of working with infragistics is that controls are constantly changed and their javascript files etc. changed, so the approach above is not future proof or sensible in this environment.
Any suggestions gratefully received.
Thanks,
Andy
Hi,
I am using Infragistic 10.3
Can you please give me a sample code to use external javascript folder instead of embedded javascript which comes from dlls.
Hello Andy,
By default, our current release (8.2) uses embedded resources in the DLL (via the WebResource.axd handler - you can see that if you check out the HTML source) for javascript files and styles (one default theme). If you need to have files externally, you can have so by using the JavaScriptXXX and StyleSetXXX properties for each control (or you can set that globally for all controls in web.config)
You can find more details about that here:
http://devcenter.infragistics.com/Support/KnowledgeBaseArticle.aspx?ArticleID=6158
Hi Vince,
We are using v7.2 Netadvantage for .NET 2.0.
The project is upgraded from a previous version initialy v5.xxx for .NET 1.1 I think. Unfortunately I don't have time to research this just yet. Does the current version make use of embedded assemblies. I must admit a quick scan of the html and it didn't seem to have any links to javascript files.
If this is the case, I assume I could simply distribute the relevant dll's in the bin folder of our application and not worry about re-distributing the .js files atall??
Andy,
What CLR version of NetAdvantage for .NET are you using? You might not even need to copy the JavaScript files in the first place.
If you're using a "CLR 1.x" version of NetAdvantage for .NET, then the JavaScript files are needed. However, you don't necessarily need to set the "JavaScriptFileName" properties of each control on every page; instead, you can control the path that our ASP.NET controls look for the JavaScript files by adding a few entries to your web.config file. See the following article from our online Knowledge Base for more information:HOWTO: Use web.config file to assign the JavaScript and Image directory locations
This same article also shows how to specify locations for image files, WebSchedule forms, and stylesheets. To be certain that the controls go to the right place for the JavaScript files, once you've updated your web.config file, I suggest removing these hard-coded file paths from your website.
If you're using a "CLR 2.0" or "CLR 3.5" version of NetAdvantage for .NET, then you may not need to include the JavaScript files. They're included as embedded resources in the assemblies that use the files. That way, when you update the assemblies, you're automatically updating the JavaScript files as well. However, this approach requires that the server provide access to ".axd" files, which is how ASP.NET gets at embedded web resources; some servers disable this access. If you can't enable this access, then you'll need to deploy the JavaScript files in the same way as for CLR 1.x versions, but you can still use the web.config file to determine where to put them.