I'll describe that task in some detail so you won't go chasing quickie solutions that can't do the job.
I'm now managing a web site which is embedding ads from a Big E-tailer. (If you're thinking big, you've got the right one.) We have ad blocks for a large number of books and a variety of swag (totes, banners, pins, mugs) and we'd like random selection of ad blocks, as below. Since each ad block results in a request to Big E-tailer's servers, and since our 'library' of ad blocks may run into the hundreds, we don't want the code for a block to be interpreted unless we choose it for display.
In addition we'd also like to have a lot of control over how the blocks are selected, so we would like to be able to store parameters both with the ad blocks and in the display spaces. (Example to follow.) My feeling is that it would be fastest and least stressful all around if the ad blocks' HTML could be stored, with the control parameters, in a single file on the file system we see in our hosting company's server environment. We might have a second file, also there, with parameters for the various display spaces.
What I envision is something like this: An ad display space in the web page (perhaps in the coding for a sidebar) contains a JS program (or the URL thereof). Parameters for that space (one of many) say "three NewBooks, two ClassicFiction, two ClassicNonFic, one Swag, one to three selected randomly from NewBook, ClassicFiction, ClassicNonFic, and Swag.
This yields nine to eleven slots to be filled for this display space, each needing an ad from the specfied category. The order of the slots is now randomized. (I -know- there is a random number function in JS.)
The list of ad blocks (and associated parameters) resides in the server file. Perhaps each category is read into an array, and each array element has a string with the ad block HTML and display control parameters.
For each ad slot in the display space, an ad is selected as follows: First a weighted likelihood is assigned for each available ad, based on the parameters and the slot's location (eg. from top to bottom in the display space). Then, based on the weighting and more "random" numbers, the ad is selected and its text is "injected" into the page. Finally, the ad is removed from consideration for re-display on that page (unless there are not enough left).
Since we have many times more ads than we will use on any given page display, it seems best to keep them as text rather than as Object Model Objects until we know that the particular ad will be needed. This is doubly true because each one results in a request to the e-tailer's servers and too many requests from one browser can make those servers send generic ads rather than the particular product ads. (And of course, making unneeded requests is Not A Nice Thing To Do.)
So where can I use advice? Mostly with the tools and suggested practices for reading the hosting-server files, structuring their content to be interpreted by the program (variable numbers of parameters and defaulted parameters, keyword and numeric, would be helpful; so would a comment convention in the file), and mechanisms for injecting HTML and the subtleties and pitfalls associated with it. Since I have the Rhino Book, pointers to chapter and section would be just fine, if that's best for you.
If you're read this far, I thank you for your patience and attention, and I will be grateful for any pointers you care to offer.