I published the latest UCRepositoryCore framework, and the latest version of CAREO, to careo.ucalgary.ca today.

Minor "issues" - mostly cosmetic, which will be resolved when all components have been converted to the new xml format.

I've updated the theme for the SciQ Pre-Alpha theme. This version should handle stretching (vertically) much better. Granted, the search results pages won't be too long anyway, but I have to accommodate any length of page since they're being generated dynamically.

Currently, I've used placeholder "content" for all pages. I know, the default "Home" page won't be Q-Live, but I had graphics for that. And yes, I know the Q-Live button doesn't go anywhere (but you JUST SAID Q-Live had graphics! I know... I have to write a WebObjects component in the UCRepositoryCore framework that can handle "changeable" pages like in the Learning Commons Website. Should be done Monday or Tuesday of next week.)

Stephen Downes has posted his notes from the IMS Technical meeting.

The page has a rather disturbing title, but it looks like a quick overview of the session for anyone who missed it (like myself).

Reworked the sliced-and-diced HTML for the SciQ theme in CAREO. Works much nicer now, and scales vertically when needed (without having the table layout puke all over the place).

Now that the basic HTML is in place, I need to write a generic WOComponent that can handle parameters from the URL to read Article text from the database (like the LC website does).

VERY rough version of this is available here (don't send the link around - it's likely going to be down quite a bit, and changing every now and then - I'll send the public URL when it's ready).

Spent the day converting the static photoshop files from IdeaMachine into actual working HTML and JPEG files. ImageReady is worth its weight in gold for this... Set up some guides, slices etc., clean them up, and cest fini.

I'm working with the ImageReady-generated html, massaging it for use as a theme in CAREO (specifically for PageTemplate, but there are quite a few lesser components which will be used - Sidebar, BreadCrumbsCAREO, SearchBar...)

I've decided to alter the .xsl file that generates the .wod string to assume any WOHyperlink, WOForm, WOImageButton etc... will be able to accept a ?theme=x parameter.

It seems to work well, but it also means that links to external pages will have a url parameter tacked on that could either be ignored (hopefully), or possibly misinterpreted.

I don't expect I'll be linking to external CGI scripts, and other pages aren't likely to read parameters from the URL, so it's a risk I'll be willing to take.

My home Mac is an old, creaky 8600/300. It was one of the fastest machines around when it was new, but it's too antique to properly run MacOSX. I'd actually relegated the machine to being a "media hub" a few years ago - it was acting as our basement TV through the ATI Rage Pro card with cable tuner. Worked great as that, and I have my TiBook from work for any real work at home, so it's not a big deal.

I've got to figure out how to handle WOHyperlinks (and WOSubmit etc...) in the theme xml fragments, so that when the user clicks on the hyperlink that is generated from it, their theme is maintained. What might happen currently, is that the ?theme= parameter from the URL is blown away (or, worse yet, the ?wosid= parameter too), so that I can't identify which theme they're using.

Here's a handful of potential solutions:

Andrew Lindesay has just published an article on Stepwise detailing his use of XSLT in WebObjects.

It's quite in-depth, and has some great background info on how to get it all working together. This would have been quite handy a couple of months ago... ;-) Some really nice and clear documentation, including lots of shiny diagrams.

It looks like he's taking a slightly different tact than I am. He's replacing the .html for a WOComponent with an XML string, leaving the .wod string in place as normal. I'm going one step further, and generating both .html and .wod from the single .xml source.

Made a LOT of progress in adding XML fragments to represent the templated components in the default theme of CAREO today (thanks in no small part to the sorta-working Theme Manager app).

This is really going to work out well! Cool... I'll start working on documenting the whole process ASAP - what components are available, what their bindings are, how to add them to other compoennts...

I've got a working version of the theme management application running on commons, and it's coming along quite nicely!

Here's a peek at the Component List for a specified Theme. Note the indicators to show the status of each component. Green lights are good (i.e., the component has some xml to represent it, and it has been pre-transformed and cached.)

Selecting any component will take you directly to a Component Editing screen, where the xml can be edited (or copied/pasted from your Editor of Choice). Also, note the "Add Component' link: you can add new components from here, to fill out the theme as you go along.

One of the main challenges I placed on myself in building the new theme engine for the repository, was that theme administrators shouldn't have to know anything about WebObjects or the code of the repository in order to design and implement their theme(s).

The other main challenge was to make it as simple as possible for the theme administrators, including the ability to use whatever editor they feel comfortable with.