We have a wide variety of customers and each has different business rules. Instead of having a single compiled code base, we are considering having different templated script files for each customer.
I'd say that the premise for this is kind of flawed. You are after some sort of modular coding. This can be done with other languages too. Define the modules, create a Factory that serves the one you want and use that. It is probably a lot simpler than trying to do multiple temptation of the source itself.
In addition, we need to get data into the scripts. So, we are thinking we will have variable declarations in the script, and those variables will be set to some character sequence that we will treat as a token. Then with another app, we'll process the document looking for the tokens replacing them with the actual data.
This is where things get ugly.
You've got some data in some file, and some preprocessor (lets pretend its gnu m4 - if you do find yourself following down this path you might as well use a good one - the associated SO tag m4) which reads the file, identifies the template macros and modifies the source, which is then deployed out to the customer.
So now you've got something like
site = "_SITE_"
print site, "\n"
as some ruby code and then a macro file
and then you run it through the m4 application
$ m4 main.m4 main.rb
site = "programmers.SE"
print site, "\n"
Now you start getting a lot of moving parts in there. You've got to make sure that each file parses correctly, that some site didn't include something like a
" which would be valid macro, but an invalid variable (will you catch that before it goes to the client site?).
Most of all, you had better hope that the code doesn't diverge. Once you've got something more than just running a macro against the code, but replacing the code it gets ugly. You've got to be very strict with naming conventions so that the values used in one part of the templates class don't collide with the other ones... and that you don't even use the values from one part of the template in another one (you pull just that part of the template in without the template part that sets up the data). It just gets UGLY.
Worst of all, and the thing that will burn you in the end with this, you cannot unit test the code you write. You can test the code that is generated (will you? really?), but you won't be able to actually test the code you write is doing what it should.
The fundamental flaw in this thought is mixing the data and the code. Essentially, the code you are writing in this model is data for a macro processor that spits out new code.
If you want template variables, read those out of a property file of some sort.
Store the data as data and load it as data. For example store it out in a JSON object and load it in to an object with the appropriate library (ruby python).
Then you're just deploying the different data to the different sites (with all the same code base) that indicate the values that are different between them. You will use the values in the data to call the proper factory method (that works fine on its own without any templates and can be unit tested).