Tag: careo

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.

So, what I did was to produce an XML-based format to store combined data from what would have conventionally been stored in separate .html and .wod files (I know, breaking MVC, but so what – it does what we need). This XML file can be edited in anything that can edit XHTML – like, say, Dreamweaver…

The cool thing about this “theming engine” is that it allows a form of inheritance on the customized components. If a theme of our application only needs 1 or 2 modified components, then you only have to add new database records for those modified components, edit a couple of XML strings, and you’re done. The rest of the theme will be automatically inherited from the default theme (I’m also wanting to allow users to specify WHICH theme they inherit from. That could be REALLY powerful).

If you want to completely change the look of the app, you’re free to do it. All you need is 1 XML string/file/record per WOComponent being customized.

Basically, I take the XML string, feed it into my XSLT translations and pump out the conventional .html and .wod strings, which will be cached in the database so it doesn’t suck performance-wise.

When the XML source strings are updated, they’re run through the XSLT translation again and the cache is updated. The cool part about the way this will be cached is that it is persistent across applications and instances – the cache is stored right next to the XML source in the repository application database.

I’m actually quite hopeful that this will work out, since it will let our partners hack away on the interface without having to learn WebObjects (or how to compile an application), or the structure of a PLIST file, or whatever… They should be able to happily pump stuff out of Dreamweaver (or BBEdit, or JEdit, or whatever), and feed it into the theming engine. All we have to do is document the WOComponent library that is available to them (classes, attributes, what it does, etc…)

Now, to prototype it actually working in a WebObjects app…

I’m just working on building an interface to allow admins to edit and manage the html fragments that make up a theme in the repository. Ideally, it will be a web-based solution similar to MovableType or PMachine, where you can edit fragments of HTML directly in the repository.

That does expose a risk, though. What if an admin is editing the theme managment page template, and breaks it? Doh…

I’m thinking that a separate Admin WO app (that isn’t themed itself, but knows about theming and can access the database store for the HTML fragments) would be a better idea. If an admin is happy with their theme, they can kill the WO app that manages them…

Maybe even a JavaClient application to manage HTML fragments? hrm…

So, I’ve been working on a way for the repository application to have customized “look and feel” – theming or branding – for various users. Turns out that the best way to do this totally destroys the Model/View/Controller design pattern. I’m basically mashing Model and View together, and using a single Controller for the combo.

Works great, though. I take the .html and .wod files and merge them together into a single .html string, which is associated with a component. This merged .html is then stored in a database, and called up when an appropriate request is made (theme matches, and component name matches). This .html string is then deconstructed into freshly minted .html and .wod files and fed into the standard WebObjects component handling mechanism, and a response is fed back to the user.

Compare

• http://commons.ucalgary.ca/repository/commons
• http://commons.ucalgary.ca/repository/careo
• http://commons.ucalgary.ca/repository/alexandria

All are the exact same WO app (same instance, even), but the ?theme= parameter determines which merged .html combo string should be pulled from the database to generate the response.

VERY flexible. Too bad it breaks the WebObjects tools (WOBuilder doesn’t understand…)

I came up with a way to track navigation through hierarchies of content packages today. The goal of this method is to track position/path within a nested set of content packages, without modifying the content packages themselves. MVC… The content package becomes M, and my method becomes C. Now, to build a way to V the two…

I think it might be a nice way to abstract the packages, and provide some handy convenience methods to navigate through the packages, and track current status/position. I’ll know more when I can play around with the live webservice connection to the Our Roots repository. Should know more on Monday.

One thing I realized today while playing around with some ideas for this technique, is that I seem to have a weird hybridized design strategy. I caught myself doing a LOT of design work on PAPER. Initial diagramming of the relationships between the classes, right down to the first draft of the interface for my controller class. Very odd… Probably because it’s a more visceral approach, and easier to throw out a piece of paper than to delete a file (you trash paper, you save and even back up files…). Interesting. And I thought I was pretty paperless at this kind of thing. Far from it, actually. Kill the trees!