views:

281

answers:

3

I have a need for generating JavaScript on the server. I can do this by using ASPX pages to template JavaScript but I'm getting warnings and I don't benefit from syntax hilighting which I would like. Is there a way to tell the .Net environment/Visual Studio that a certain ASPX page is supposed to output non-HTML text?

The reason for this is localization. My localized strings come from the server and I need these in JavaScript constructs on the pages. The easiest way I came up with is to have one JS file (I'll call it l18n.js for now) which defines the localized strings in a JSON object.

l18n = {
    OK: <%= GetString("OK") %>,
    Cancel: <%= GetString("Cancel") %>,

    ConfirmDialog: {
        Title: <%= GetString("ConfirmTitle") %>,
        Message: <%= GetString("ConfirmMessage") %>
    }
    // .. etc.
}

This lets me use the localized strings in other parts of the UI

var okButton = $('<button>' + l18n.OK + '</button>')

But as said, just throwing the JavaScript inside an ASPX page, l18n.js.aspx, results in warnings and doesn't provide syntax hilighting. Is there a better way which would at least get rid of the warning? The current one is

Generation of designer file failed: Exception from HRESULT: 0x80042929

And in case it matters the project is built on top of .Net 2.0

Clarification

The language isn't user chosen so it shouldn't change all the time and I should be able to use the language value as the ETag so caching shouldn't be that big of an issue. From the browser perspective I'd consider the templated JS a static file just like rest of the files. I just don't want to declare the ~10 static JS files separately if I can automate it.

A: 

You could make a control (.ascx) that consists of a script block?

To get jquery intellisense, do something like this (it's for asp.net mvc but something similar should work for classing asp.net too):

<% if (false)
   { %>

<script src="../../Static/Scripts/jquery-1.3.2.js" type="text/javascript"></script>

<% } %>
Thomas Stock
This might work, though doesn't this force me to inline the JavaScript inside the html body? In any case it at least forces me to inline the JavaScript which I'd like to do without for some personal preference. Good to know there's a solution in case there's no way to declare the JavaScript in a completely separate file from the browser's perspective though!
Mikko Rantanen
I see your point. I didn't catch that from your question. Good idea, but watch out with browsers caching the .js file when there's dynamic data (supposed to be) in there.
Thomas Stock
I think ropstah's answer is pretty good, since it won't matter that browsers cache the javascript.
Thomas Stock
I probably should have mentioned that it's not really dynamic. The language isn't user chosen so it shouldn't change all the time and I should be able to use the language value as the ETag.
Mikko Rantanen
Wheter or not it changes frequently, you are still creating 'dynamic' javascript. Please see my updated answer...
Ropstah
+2  A: 

An ASPX is a ASP.NET Form. It is expected to represent a Web Form which the user may interact with running further code in the ASPX. Hence the ASPX lifecycle represents much of this.

For raw output such as JS you should use an ASHX which does not have all this Forms overhead.

In your specific case I would be looking into creating a set of classes that can be serialised as JSON. Send the serialised JSON as the output of your ASHX.

AnthonyWJones
Oi! I didn't think of JSON serialization at all! Need to find some handy library to do that in .Net 2.0 now and see how it works. And I know ASPX are supposed to represent Forms, which is the reason I personally hate ASP.Net. :| Too bad I don't have many other options with COM interoperability and such. I'll let you know how the serialization worked.
Mikko Rantanen
I'm not sure why you would hate ASP.NET because ASPX has a specific meaning. This is probably just a misunderstanding in that an ASPX file is mentally considered equivalent to an ASP file in classic ASP. ASP.NET doesn't have such an equivalency. For generating non-HTML raw output .ashx is the correct tool. It doesn't support static content and therefore the <% %> mark up. IMO this is a good thing.
AnthonyWJones
I don't believe all pages should be considered 'forms' and the abstraction ASP.Net provides is very leaky. I'm not saying ASP.Net is a bad thing for what it is meant for but I feel that for general web development the "Everything is a form" attitude is wrong. And just to clarify, I don't hate that ASPX has a specific meaning, I hate that there is no other templatable construct in ASP.Net which forces people to use the "form" construct when designing non-form html pages.
Mikko Rantanen
Oh.. and what I came to say is that I found JSON.Net 1.3.1 which works in .Net 2.0, implemented this solution and it works great! Thanks! Anonymous types even let me declare the localizable strings with very little overhead in code.
Mikko Rantanen
+1  A: 

You could also load all your current pages language-elements in 'global' variables (constants) at the top of each page in a script block.

var LANG_OK = 'ok string';
var LANG_CANCEL = 'cancel string';
var LANG_CONFIRM_TITLE = 'title string';
var LANG_CONFIRM_MESSAGE = 'message string';

This keeps the dynamic part away from your javascript file. This means the javascript files are static like they are supposed to be.

update

You could consider creating javascript repositories for each language based on my solution above.

  • language_EN.js
  • language_NL.js
  • language_FR.js

This would mean you just have to select which file to include in the page:

<% Response.Write "<script type='text/javascript' src='/js/language_" & User.LanguageCode & ".js'></script>" %>
Ropstah
Good idea. Will use this in one of my projects. +1!
Thomas Stock
Language repositories would have been my choice if those were the primary source of localization but since the localized strings are shared between web and native applications I asked about dynamic javascript, one that can be used to pull the localized strings from the primary source. The script block at each page is more suitable for this but it causes huge overhead as it is included in each new page the browser loads.
Mikko Rantanen