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.
The IMS just bumped the DRI spec to 1.0. That’s a good thing, as it will impact how the various repository projects will be able to communicate with one another. This will have some immediate benefits for the EduSource Canada project, which is in the midst of building its communication API.
Woohoo! I just got an XSLT prototype working that will let me re-implement theming in our repository application!
My goal was to produce a solution that would allow (some of) our users to completely customize the interface of our WebObjects application, in a way that simply mucking about with the .html part of a WOComponent simply couldn’t support. They need to be able to add/remove/move/modify functionality that may not be predetermined in a .wod file.
I’ve been using JEdit for a while now, and am constantly amazed at how complete it is. It’s even got a plug-in to manage XSLT transformations… Not as elegant as I’d usually like, but the integration into a kick-ass editor more than makes up for it.
WIth the addition of the Project Manager plugin, it’s pretty full-featured, and the somewhat sluggish Java UI is still very usable (even on a pokey TiBook 400! (one aside on the Project Manager plugin - it seems to require Java 1.4.1 to install, but if you run JEdit once under the 1.4.1 prerelease, you can install the plugin and it still works under 1.3.1…
I’m working on a simple java application to manage transformations using XSLT via Xalan-J. Not sure if I’ll use Cocoa-Java or SWING. Don’t care a lot about cross-platformability, since it really only has to work on my machine…
I don’t have a lot of experience with SWING (did a simple app a couple of years ago), and have no experience with Cocoa, so I’m kinda ambivalent (although having an excuse to learn Cocoa would be cool, I’m not sure I have the time to take that on). Since I have a brain-dead-simple command line Java app working already, I might just do it in SWING.