State of development:

THYME mirror
DAIA mirror

Currently we have two versions of CWLD completely implemented with the JavaLina front end enhancements. One version resides on the library's server, while the other lives on thyme, where the cgis live. This is important because security restrictions built into javascript prevents certain kinds of interactions between windows with different domains - namely, terms pasting isn't possible under this architecture.

There are a few solutions for this problem.

• Set up a the site so that the search forms and cgis reside on the same machine. (best solution)
• Change the document.domain property in both documents to "uchicago.edu". this allows terms pasting but messes up the history function. there is also a way to change the history cookie to a "uchicago.edu" domain but i came across a lot of browser differences and bugs when testing this. this is not a great solution and probably involves writing a bunch of browser conditional forks that might break anyway with the next releases.
• Pretend that the forms and cgi are on the same machine. set up virtual links on one of the machines that point to the other machine. this is transparent to the browser.

Issues:

• HTML formatting: there is (at least) one item that contains italic html tags inside the database, under battle names: cherbourg.... Since the html formatting actually lives in the database, it needs to be present in a search to return a match. Paradoxically, the < and > characters are not legal in an sql search. The best solution is to remove the HTML formatting from database entries, or perhaps just this one. The current implementation replaces the < and > by the wildcard character, . , during the terms pasting. This is ok but might confuse the user.
• Should we have one universal hash or many different ones? We use hash tables for two things: to figure out the user-friendly name of form inputs for the search history and error popups, and to figure out the type of field (sql, philologic, sql numeric, etc) for error checking purposes. Currently, we have one .js file for each search form, which contains the relevant information for that page. However, it is apparent that some effort in setting up these hashes could be saved if there was only one hash for the entire database, containing all the names and types of every field on every page. For example, the advanced.js file for cwld contains almost every field in the whole site.

  Possible problems with the unified approach:

  • If on different pages form fields have the same html name but a different label (this is not going to happen though, right?)
  • I use the individual .js files for another thing: page specific mappings from form names that the terms search sends back that are different from the names of the fields on the search forms. for example, 'allauthorforms' needs to be changed on some pages (but not all) to 'docauthor' or something similar. In each file, i have a function that reads gives the terms pasting command a look over before it gets pasting, making any necessary modifications. if we did away with the individual .js files, we could include this function in the html, or in a new .js file that would only contain these kinds of functions. i also store a variable in these files that tells the term pasting window where the cgi is. this could be done away with if the cgi location is standard.