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…)
It’s been a fun exercise in implementation of design, since there are always (ALWAYS) things that the designers neglect to think about when designing an interface that’s actually going to be implemented outside of photoshop (you know, like a web page, or anything else). The IdeaMachine guys were actually pretty good (waaay better than most), so there have been very few oversights. Whew…
Check out the in-progress html conversion here.
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.
February 15, 2003 · 1 comment
in Uncategorized
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.
However, Janice is getting interested in getting online, so I’ve set up Old Betsy in my home office so she can surf from home when the TiBook isn’t there. It’s been a real eye-opener for me, since I’ve been taking the software I use every day on MacOSX for granted.
Browsers on MacOS9 basically suck, mostly because there’s no real multitasking – one page loading will essentially lock up the system until it’s done. That wasn’t a big deal, until I’d tasted the fluid action of MacOSX. Regardless, IE on MacOS9 is adequate, but there’s no decent news aggregator!
I’ve resorted to installing Amphetadesk, and it’s just plain clunky compared to NetNewsWire on MacOSX. Oh, well…
Maybe this is the kick in the butt I need to pick up a MacOSX-capable machine for home… Nah, probly not. I’m too cheap.
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:
- Modify all hyperlink-related webobjects to embed the appropriate parameters into the url (wosid and theme) – either through the XSLT generation of the .wod bindings, or on a more procedural level.
- Use cookies so that I don’t have to track any parameters in the url.
- Store active theme reference only in Session, and trust that ?wosid= will survivie hyperlinks.
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.
Hopefully he’ll post his sample .xsl file so we can see his take on it.
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.
I just read the article on The Register about the defacing of Kevin Mitnick’s company website. I figured it must be some obscure Linux hole that was found by a hacker, but according to their own server, they run Microsoft IIS! They were hacked by a 733T script kiddie! Oh, my…
From www.defensivethinking.com :
The page cannot be found
|
|
The page you are looking for might have been removed, had its name changed, or is temporarily unavailable. |
Please try the following:
HTTP 404 – File not found
Internet Information Services
Technical Information (for support personnel)
|
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.
To address these two needs, I had to think long and hard about the way WebObjects handles pages and templating, with the separate .html and .wod files that beautifully enforce the Model-View-Controller pattern. To do this properly would require turning my back on MVC in this instance. Is that such a bad thing?
I looked at many of the components in CAREO, as well as the Learning Commons website, and realized that MVC wasn’t really being used. Sure, the bindings for a component were separate from the html itself, but so what? It was basically just a denormalized version of an html page with dynamic bindings – the .wod file was really just in the way.
With the assumption that I could go ahead with a single-file-to-edit strategy, I created a simple xml element that would be used to represent WebObjects components in a templated page: ucwebobject. Creative, no?
ucwebobject has only 1 required attribute: classname. classname is the name of the WebObjects class used to represent the component (like, say, WOString, WOTextField, WOImage…). Any other attributes for ucwebobject are mapped into the bindings used by that component (a WOString might have a “value” attribute, etc…).
Here’s a sample ucwebobject for a localized string:
<ucwebobject classname=”UCLocalizedString” value=”" />
Note that value of the “value” attribute begins with a $. That marks it as a literal string, and it will be wrapped in quotes when fed into WebObjects for rendering. Any attribute value not having the $ will be assumed to be a class variable, and will not have quotes so that WebObjects will grab the appropriate “live” bit of data.
Here’s another one that has dynamic bindings:
<ucwebobject classname=”WOString” value=”session.user.firstName” />
This one pulls the variable “firstName” from the session objects’ user variable (in this case, an EO).
Also, since the source fragments are now XML, all attributes MUST be in quotes in the source, and all elements MUST be balanced and closed properly, or the transformation into .wod and .html will fail.
