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.
I know this is on the Blapp homepage - there’s even a screenshot of it working - but I never tried it out until now.
Dang, that Links window is cool! It scans all blog entries for hrefs, then presents a simple interface to list and search them, so you can reuse previous links. Well done. Dragging an item from the Links window into a new blog entry even generates the appropriate HTML element. Slick.
I’ve been using Blapp for a while now to manage the entries for this blog. It’s pretty cool, and I just saw that Michael McCracken now has a badge for his cool software.
Anyhoo, here’s credit where it’s due:
It’s good to see that Michael plans on continuing development of Blapp, even though NetNewsWire Pro will have integrated blog edting. I like Blapp, it’s a neat little program. Could use some tweaks, but it’s not bad at all. Oh, and it’s free, which is a Good Thing.
I’ve just “upgraded” to Blosxom 1.0, and it was (of course) a smooth process.
Congrats, Rael, on hitting the mythical 1.0!
I finally figured out where to modify blosxom.cgi so that it doesn’t render the entire freaking blog with each static rendering of the site… Easy change in line 167, to remove the first condition (if dynamic, pay attention to the entry count limit) - after removing that condition, all pages will obey the entry count limit.
Looks like it’s working properly now. Not sure why it was acting up before, but it looks like Operator Error (code ID 10 T, most likely).
Thanks to Rael for double-checking my copy of the blosxom.cgi file, to rule out any kind of serious problem.
I’ve now limited the number of entries on each page to 15, so it’s not a 50K hit each time. There’s also a category index on the left side now, as well as indices for each category (just change the index.html URL to index.index, and you’ll get a list of entries).
This is just my take on it, but I’ve just about had my fill of the “Apple is Evil” rants regarding their actions toward the developer of iCommune.
It seems like a clear-cut case: iCommune violates the device-plug-in-API license agreement. It has NOTHING to do with what iCommune does. Apple isn’t saying “you can’t do that”, they’re saying “you can’t do that with that API”.
They have a history of doing this kind of thing especially around APIs that are either half-baked (i.e., incomplete, not half-assed), or on the way out (planned deprecation), or about to be superceded by something better.
