views:

86

answers:

1

This seems like a somewhat common issue and I'm wondering what the common pitfalls, best practices, best approach, security concerns, etc., are when creating javascript on the server to be later loaded client side.

FWIW, I'm doing this in Ruby and I'm using JQuery as well. It's basically a form builder. Here's what I'm doing:

I have an admin form builder that dynamically creates the static form inputs (eg select, radio, checkboxes, and a couple of more complex inputs as well) I need to create corresponding javascript event handlers (using jquery). I basically have html builder lambdas and event handler lambdas that are mapped to each predefined input type: ie select has something like {'select'=>[select_builder_lamb, select_js_handler_lamb]} so I can look up the html type and then generate the needed code allowing the administrator to create a form "to their liking". This is working great.

Now I have to figure out whether to serialize this and then reload it when the registration page is requested, write out the javascript to an "unobtrusive" file, or store the raw html and javascript in the database, etc. No problems with the generation itself - so if the high level is: 1) make html & javascript 2) persist for later use 3) use for an http request - my question is for steps 2 and 3.

If you have experience doing this kind of thing and could provide some forwarning and wisdom it would be deeply appreciated!

+2  A: 

A few things that spring to mind:

Code Separation

Although embedded JavaScript within an HTML page is widespread, many consider the practice of code separation to be good. In this respect I am referring to the placement of the JavaScript in a separate file. This is part of a broader concept known as Unobtrusive JavaScript

As web developers, we are required to know many different technologies, e.g. some of:

  • Server Script (PHP, ASP, Ruby, etc)
  • JavaScript (and framework)
  • XML
  • HTML
  • XSLT, XPATH
  • CSS
  • SQL

Imaging a code file that contained all of these! It would be chaotic!

Outputting JavaScript from the server precludes the separation of JavaScript into a separate file. If we separate these out then our code becomes more modular, reusable, readable and testable, which leads me to...

Unit testing

You may not personally be using a unit testing framework, however the modularisation of JavaScript is essential for creating independant testable (and reusable-testable) modules.

Script that is output on the server is not modularised, but more importantly is not static, so is difficult to fit into any unit testing framework.

Tag Soup

Although it is possible to code against this, mixing of client and server script has a tendency to produce tag soup, making it hard to read and maintain.

Debugging

I'm not sure what IDE you are using, but mine allows me to step through the JavaScript that I have written. Outputting it from the server mean's I can't do this.

James Wiseman
Hello and thanks for your response. I too am surprised that the question did not illicit more responses. I appreciate your considerations and in general agree. However, I can't see how to achieve my end goal without some server-generated javascript. I've yet to implement this though, so I'm going to try to make may js files dynamic enough to deal with 1..* form fields of unknown types (again, my app is basically a "form builder"). We'll see just how "unobtrusive" I can make it ;)
Rob