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.
Made a lot of progress on the Theme Management application for the repository. There are a few minor tweaks to make (like adding and deleting themes and themed components, as well as some security), but it works.
It will take the XML input, transform it into .html and .wod, and cache the results in the ThemedComponent (TblComponentContent) table for use in CAREO. Works great.
Meanwhile, back at the ranch, I finally committed a metric boatload of changes into CAREO and UCRepositoryCore. Most are minor tweaks, but theme support hadn’t been fully committed to CVS until now.
The Onion, that last great bastion of true reporting power left in North America, has identified a potential rogue nation which may require UN and/or Shrub action… North Dakota!
I got a rough version of a Theme Manager application working for CAREO today. For now, it’s a separate WebObjects application that uses UCRepositoryCore (and therefore CAREO.eomodel) to talk to the repository application database.
It gives an admin a way to list all themes, list components in a theme, and edit the componentXML (as well as save, transform, cache…).
I’ll have it working almost 100% by Monday or Tuesday next week, and then work more on converting all components to the new componentXML format.
Just cut the XSLT code to a shockingly small 42 lines. Wow.
The XLST that converts the repository theme xml fragments into WebObjects .wod strings is only 16 lines… The XSLT that produces the .html strings from the same xml fragments weighs in at 26 lines.
Smaller is better. Less code, less to maintain, less to go wrong…
Tim made the point that “web services” are about performing remote operations. When viewed in high contrast, “web services” build a web of interconnected verbs, while “semantic web” builds a web of interconnected nouns. It was encouraging to see a journalist relaying the message that the two worlds will be complimentary, rather than succumb to the typical Zoroastrian storyline.
It’s working great now! Better than I had it yesterday, and I’ve reduced the whole XSLT portion down to 46 lines of XSL code separated into 2 files (one to produce the WebObjects .WOD file, the other to produce the modified WebObjects .HTML file).
I removed my hand-coded XML-to-HTML cloner, since it was waaay to possible that I’d miss some HTML entity or attribute and have themed pages munged without explanation. The new method takes 6 lines to exactly clone any element that I don’t explicitly deal with. Very cool. And that removed 1 extra XSL file, and an additional 98+ lines of code.
It basically says that prototyping is a Good Thing, and that solid prototypes lead to a better understanding of the problem, which leads to better software in the end.
This is something I’ve always done, just because that’s the logical way to go (in my opinion)… Start by analyzing the problem, then enhance your understanding of it, then solve it.
It’s waaay too easy to get it wrong if you go the other way around…
I got the XSL translations working yesterday, and modified to better accommodate whatever random bits of HTML might be included in the themed page fragments. Works like a charm.
I’ve got the main menu of CAREO (and all of it’s included components) modified to use the new XML format, and have UCRepositoryCore checking all components for the XML fragment, and cacheing the result of the transformation for later use.
It’s a LOT faster than running the transformations on the fly (it can take almost a second to transform a big component into HTML + WOD on my TiBook, but after it’s cached, it’s almost instantaneous).
I just installed MovableType on the Learning Commons server. Dave and I have been talking about weblogs, so I figured the best way to show him was to set it up so we could try it out…
Wow. That was easy. (of course). Not having a digital video cam, I brought in a bunch of photos from iPhoto, and a track from iMovie, and used the famous Ken Burns Effect to make a slide show.
Went pretty easily. MUCH faster than the old way I used to do this. Several years ago I had to do a couple of slide shows, and used Director and Premier. The result was effective, but consumed about 2 weeks of my spare time. That sucked.
