HCMC Blogs

I've been kicking around some ideas for how the CSS system should operate, and I think I've come to some conclusions:

We have a range of different types of CSS data that will need to be combined. First of all, we have the base (default) CSS for the Website; then there will be customizations overrides for that CSS (user). This distinction is the same as that for the interface strings. Next, we have the base CSS for article/contribution display; then, layered on top of that, is the CSS specific to each style guide (APA, MLA etc.); then on top of that come the user customizations of that display. It's really complicated trying to figure out exactly how all of this should fit together.

I need a system which enables a single stylesheet (or possibly two) to be created from the database through an XQuery, which intelligently merges all of these layers of data, which are stored in a range of different XSLT attribute-sets in the db. The problem is that some of the rulesets may be additive (at the base level, for instance, <h2> tags may be set to text-align: center, while further down they're specified as a particular font size), while others may be replacements for each other; it will be difficult to tell the difference. One approach is to gather all the instances of a particular selector from all the db files, then iterate through their attribute @name values, using only the lowest-level one (so that an h2{text-align: center;} at the lowest level would be overridden by a text-align: left setting in a user file further down the cascade). That this is possible shows the advantages of storing this info in XML format -- it's easy to parse and compare values -- but the problem is slightly complicated by the existence of shorthand properties. However, as long as user rules are included after any default rules with which they might clash, the cascade will take care of the problem, albeit at the cost of a larger file.

So the "hard" problem is really how to divide up the data amongst the various types of file. The cascade should probably go like this:

1. "Base" file -- controls the site interface, and sets core font choices etc.
2. "Style" file (APA, etc.). This is another base file which is added onto the top of the site style, to provide new styles required for the display of articles in the default style, etc.
3. "User" file. This is a set of customizations which are added at the end of the cascade. When the user is customizing, they start from the style guide they've chosen (in other words, their GUI will present them with a combined set of existing CSS, based on the combination of the "base" and "style" data). Their customizations are modifications to this.

The only wrinkle here is that, if the user then changes the style choice AFTER adding customizations, those customizations might not interact perfectly with the new style. However, that's to be expected, and the user can be warned about it, and can modify the user styles appropriately after choosing a different style.

Second half of testing in preparation for putting FCK editor into pages on french site. For first half of testing, see post "test 2 FCK editors on one page".

I modified the settings.php and ajax_methods.js files, and created an indexBOTH.php file. The files were modified to allow for a value of "both_lang" in the $SESSION[language] variable. The indexBOTH page now allows the user to select French, English or Both and displays appropriately by hiding and showing the French and English divs appropriately.

By combining this with the 2 editors in one page code I'm testing in the philosophy site (because there is no FCK editor code at all in the French site right now), the result will be the ability to edit both the French and the English texts in separate editor boxes on the page in the browser.

In the philosophy account, I created index_test.php and web_page_text/index_test.inc. The php file is identical to index.php with the following exceptions:
- addition of a call to index_test.php
- addition of code to create a second instance of an FCK editor, that instance points to index_test.php
The index_test.inc file is identical to index.inc with the exception of some text changes I made just to make it obvious the new file is being read.

When I log in, I get the two editors, each displaying the appropriate source file and saving changes properly. I'll combine this knowledge with that gained on the French site (see posting on "test both languages visible in French site") for possible deployment on the French site to support editing French and English texts in separate boxes on the page in the browser.

Took off half an hour early to get to the bank.

Final details were small but took a long time to figure out. Among them were issues of subelements. For instance, there's a need to include the names of editors and encoders in the data, but the only tag available for this is DC.contributor, which is vague. This can be qualified, like this: DC.contributor.editor. However, there's no official set of terms for this. There was a proposal to add "editor" but it was voted down a few years ago. Therefore I've had to use my own unofficial extensions, and I'm simply basing these on the value of the <resp> element in the relevant <respStmt> tags.

Beyond that, everything is fairly straightforward, although the implementation took a little while. My plan now is to base the Web view of the metadata on the Dublin Core <meta> tags that are already in the header, parsed through JavaScript, so that (for instance) the JS code would iterate through each <meta> tag, and if its name begins with "DC.", take the string after the last dot (e.g. "editor"), upper-case the first letter ("Editor") and then show the value in the content attribute. That would make a neat little JS class that could be used for any page with DC metadata in it.

The template for most pages in the history site includes a call to a javascript function which updates an image and a text div every 10 seconds. Many of the pages for individual faculty members include only one image and text reference appropriate to the person. For some reason those pages had the id attribute for the image and text divs removed, but not the call to the js code, so when the js code ran, it generated a null-value error.

I modified the template for the faculty pages and each existing faculty page to comment out the js call in the body tag and the include js tag in the head. I reassigned the id's to the divs and added an explanatory comment. If someone wants to have changing images, they need only uncomment the include js line and the body tag.

Also made some text edits to specific files as requested by the dept.

Began working on the XSLT for XHTML output of articles. Noticed a problem with caching in Cocoon: where an XSLT file includes another XSTL file using <xsl:import>, changes to the imported file will not be registered by the transformer; it seems to use a cached copy. Only an update to the root XSLT file will trigger reloading of all the cached files. Reported this to sysadmin, because I've never seen this behaviour before, and I use imports a lot.

Spent the morning working through the Dublin Core spec, and making sure as much as possible of the <teiHeader> metadata is represented in HTML <meta> tags in the header of the document. I still have a few bits of info that need to be included, but it's basically done.

Further to a previous posting, you must use the URL box in the advanced section of the insert link dialog to include a relative link. If you put the relative link into the link box in the basic section of the insert link dialog, Contribute precedes the relative link with the "http://" protocol.

I further discovered (with Jennifer's assistance) that to create a link to an anchor within the same document:
- create the anchor first using the "Section Anchor" item in the insert menu of contribute
- select text for link, choose link-web page, open the advanced part of the dialog and then insert the name of the file (even if it is the same file as you're editing)
- by inserting the file name, Contribute finds the anchor tags in the specified document and populates a dropdown list in the advanced section of the dialog; you then select the anchor.

We also confirmed that Contribute is 'smart' about relative URLs and tends to make a relative rather than absolute URL wherever possible.