views:

216

answers:

6

I'm developing a facebook app right now all by my lonesome. I'm attempting to make a javascript call on an onclick event. In this onclick event, I'm populating some arguments (from the server side in php) based on that item that is being linked. I'm inserting a little bit of JSON and some other stuff with funky characters.

Facebook expects all the attribute fields of an anchor to be strictly alphanumeric. No quotes, exclamation marks, anything other than 0-9a-Z_. So it barfs on the arguments I want to pass to my javascript function (such as JSON) when the user clicks that link.

So I thought, why don't I use my templating system to just autogenerate the javascript? For each link I want to generate, I generate a unique javascript function (DoItX where X is a unique integer for this page). Then instead of trying to pass arguments to my javascript function via onclick, I will insert my arguments as local variables for DoX. On link "X" I just say onclick="DoX()".

So I did this and viola it works! (it also helps me avoid the quote escaping hell I was in earlier). But I feel icky.

My question is, am I nuts? Is there an easier way to do this? I understand the implications that somehow somebody was able to change my templated local variable, ie:

var local = {TEMPLATED FIELD};

into something with a semicolon, inserting arbitrary javascript to the client. (and I'm trying to write code to be paranoid of this).

When is it ok (is it ever ok) to generate javascript from the server? Anything I should look out for/best practices?

A: 

it's fine to generate JS from the server. just bear in mind not to fine too big a page from the server.

Chris Jones
+2  A: 

Depending on your application generating JavaScript in your templating language can save a lot of time but there are pitfalls to watch out for. The most serious one being that it gets really hard to test your JavaScript when you don't have your full templating stack available.

One other major pitfall is that it becomes tempting to try and 'abstract' JavaScript logic to some higher level classes. Usually this is a sign that you will be shaving yaks in your project. Keep JavaScript login in JavaScript.

Judging from the little bit of information you have given it your solution seems sensible.

leonm
+1  A: 

JS generated from server is used in lots of areas. The following is the sample from a ASP.NET page where the JS script is generated by the framework:

<script src="/WebResource.axd?d=9h5pvXGekfRWNS1g8hPVOQ2&amp;t=633794516691875000" type="text/javascript"></script>

Try to have reusable script functions that don't require regeneration; and 'squeeze' out the really dynamic ones for server-side generation.

o.k.w
+2  A: 

If you must generate javascript, I would suggest only generating JSON and having all functions be static.

It more cleanly separates the data, and it also makes it easier to validate to prevent XSS and the like.

cobbal
A: 

If you want to feel better about it, make sure that most of your JavaScript is in separate library files that don't get generated, and then, when you generate code, generate calls to those libraries rather than generating extensive amounts of JavaScript code.

Spike Williams
A: 

Generally speaking I avoid ever automatically generating JavaScript from a server-side language, though I do however; create JavaScript variables that are initialized from server-side variables that my JavaScript will use. This makes testing and debugging much simpler.

In your case I may create local variables like the following which is easy to test:

<script type='text/javascript' language='javascript'>
<!--
var FUNC_ARG_X = <%= keyX %>;
var FUNC_ARG_Y = <%= keyY %>;
var FUNC_ARG_Z = <%= keyZ %>;
//-->
</script>
<script type='text/javascript' language='javascript'>
<!--
function DoCleanCall(arg) {
    // Whatever logic here.
}
//-->
</script>

now in your markup use:

<a href='#' onclick='DoCleanCall(FUNC_ARG_X);'>Test</a>

Now of course you could have embedded the server-side variable on the <a/> tag, however it is sometimes required that you refer to these values from other parts of your JavaScript.

Notice also how the generated content is in it's own <script> tag, this is deliberate as it prevents parsers from failing and telling you that you have invalid code for every reference you use it in (as does ASP.NET), it will still fail on that section only however.

Brett Ryan