HCMC Blogs

Completed the last two features of the backup system: there's now a button which can back up all the files, one by one; and there's a link to download a zip archive of all the files.

Because of (very reasonable) browser restrictions to prevent cross-domain scripting, it proves to be impossible to retrieve the response from the server when doing either an individual file backup or all of them, when the site is proxied through Bruno's server. What happens is that the JavaScript on the client runs, but the XMLHttpRequest object quite sensibly says that it can't do anything with the response because the response originates from a server which is not the one serving the page. Fair enough; I have some error-trapping in place which gives reasonable feedback for that, and given that (we hope) this password-protection nonsense will go away soon, we can live with it.

The other feature is pretty cool, and worth documenting in some detail. This is how it works:

• A directory generator is called to create Cocoon's standard directory generator XML output.
• This is run through an XSLT transformation which formats it as expected by Cocoon's zip serializer.
• The zip serializer streams out a zip file, as if it were a normal download of a static file. Whether it's creating a temp file first, then serializing it out, or serializing a zip file on the file, file by file, is difficult to know, but it's very fast and it works perfectly.

So now, with one click, the editor can create backups of every output format of every file on the system; and then download a zip archive of the results.

Worked with EM and LW on the encoding of the title pages and frontispieces of their documents. This seems to be complete now, so my next task is to enhance the XSLT to output it appropriately. Now EM and LW are proofing each other's work, while we wait for news of PG's job situation, and TG is still finishing her markup.

Covering Greg's new early-leaving day.

Having got the actual mechanisms of the backup system working (generating files and saving them onto the server), I started integrating the AJAX scripting so that backup calls don't actually leave the page. Getting it working with Firefox was easy -- I initially had a pipeline that returned a single XHTML anchor tag, of which the text was the new modified date of the file -- but the predictable problems surfaced with IE, so I had to rethink. In the end, I have this:

• The "Generate backup" button makes a call to the appropriate flowscript function for the type of backup being made.
• The flowscript creates the backup, then reads its last modified date.
• The flowscript hands off (through a cocoon.redirectTo call) to an XQuery script, passing the last modified date.
• The XQuery script generates a single XML node, which is actually another anchor tag.
• The output from the XQuery is processed into text by an XSLT script.
• The text is received by the AJAX object, which uses it to replace the text in the existing anchor.

While the page is waiting, the target anchor tag has its text replaced with a series of dots, which shows a simple progress system. The effect is that the date/time shown on the link is updated on the page, every time a new backup is generated.

This is tested and working on FF, IE, Safari and Opera. The next stage is to create a sequence wrapper which can call the script many times, causing the items to update one at a time, while showing per-item progress somewhere at the top of the page. That shouldn't be too hard now.

Moved some new content from the development site location into the main site, on the instructions of MK.

A kind soul on the Cocoon list pointed out a missing variable in my XHTML code (the "realpath" component was missing from the path to the folder I was trying to create -- a dumb typo), and I've now got XHTML backups working fine, including saving copies of the CSS and JS into the backup folders, to create independent packages for each document.

The next stage is to make this all function through AJAX. This isn't too complicated, but it will require some thought; I need to return some useful content (the date/time of the file created), in a usable format, to replace the current info on the page, so I'll need to read that using Java once the file is created.

PC found a bug in the interface translation code while translating the Markin program. Fixed the bug in Markin at home, then migrated the fix to IMT and did a new release. I took the opportunity to update the way the site handles version numbers and download links, as I've been doing for the Markin site, to centralize all references to versions, making new releases easier and more reliable.

Took off a little early.

Contact list completed and forwarded
to EGW & EF as requested.

Rewrote my backup page so that it now shows a useful and more readable table of all the files that exist, along with buttons to generate or re-generate hard copies of any documents. Documents that exist are shows as date/times of their last modification. The generation pipelines no redirect, on success, to the backups page they were called from, with a hash component to make sure the page doesn't jump around too badly when there's a lot of content on it. What's there so far works great.

However, I've spent all day struggling with the problem of creating directories in which to store the individual XHTML files. They should each have their own directory so that copies of the JS and CSS can also be stored there; that's required in order to make them actually functional and portable. However, I can't get the flowscript to create a new directory. After many trials, I've finally posted a message to the Cocoon mailing list. We'll see if anyone can suggest what might be causing the problem.