What's a clean way to have the server return a JavaScript function which would then be invoked?

Question

My application is architected as a host of plug-ins that have not yet been written. There's a long reason for this, but with each new year, the business logic will be different and we don't know what it will be like (Think of TurboTax if that helps). The plug-ins consist of both server and client components. The server components deals with business logic and persisting the data into database tables which will be created at a later time as well. The JavaScript manipulates the DOM for the browsers to render afterward.

Each plugin lives in a separate assembly, so that they won't disturb the main application, i.e., we don't want to recompile the main application. Long story short, I am looking for a way to return JavaScript functions to the client from an Ajax get request, and execute these JavaScript functions (which are just returned). Invoking a function in Javascript is easy. The hard part is how to organize or structure so that I won't have to deal with maintenance problem. So concat using StringBuilder to end up with JavaScript code as a result of calling toString() from the string builder object is out of the question.

I want to have no difference between writing JavaScript codes normally and writing Javascript codes for this dynamic purpose.

An alternative is to manipulate the DOM on the server side, but I doubt that it would be as elegantly as using jQuery on the client side. I am open for a C# library that supports chainable calls like jQuery that also manipulates the DOM too.

Do you have any idea or is it too much to ask or are you too confused?

Edit1: The point is to avoid recompiling, hence the plug-ins architecture. In some other parts of the program, I already use the concept of dynamically loading Javascript files. That works fine. What I am looking here is somewhere in the middle of the program when an Ajax request is sent to the server.

Edit 2: To illustrate my question:

Normally, you would see the following code. An Ajax request is sent to the server, a JSON result is returned to the client which then uses jQuery to manipulate the DOM (creating tag and adding to the container in this case).

var container = $('#some-existing-element-on-the-page');
$.ajax({
    type: 'get',
    url: someUrl,
    data: {'': ''},
    success: function(data) {                                                   
      var ul = $('<ul>').appendTo(container);

      var decoded = $.parseJSON(data);                
      $.each(decoded, function(i, e) {
         var li = $('<li>').text(e.FIELD1 + ',' + e.FIELD2 + ',' + e.FIELD3)
            .appendTo(ul);
      });                
    }        
});

The above is extremely simple. But next year, what the server returns is totally different and how the data to be rendered would also be different. In a way, this is what I want:

var container = $('#some-existing-element-on-the-page');
$.ajax({
    type: 'get',
    url: someUrl,
    data: {'': ''},
    success: function(data) {                           
      var decoded = $.parseJSON(data); 
      var fx = decoded.fx;
      var data = decode.data;
      //fx is the dynamic function that create the DOM from the data and append to the existing container
      fx(container, data);                  
    }        
});

I don't need to know, at this time what data would be like, but in the future I will, and I can then write fx accordingly.

Answer 1

I doubt you would need the ajax to return the javascript and you could probably just change the .js files each year.

Note that your scripts will need to be signed if they run cross domain

Anyway, you're probably looking for EVAL, which could in theory be used by hackers to mess with your site. It would also slow things down, and make things harder to debug...

Again, you probably shouldn't need to load javascript asynchronously. If the logic changes every year, that's just changing .js files. You would need to load it with ajax if the logic would change while the browser was still on the page... which could cause a problem in the programming namespaces anyway. (ie, you introduce new code in the live namespace of the old code, and the versions don't work nicely).