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:
Read MoreAndrew 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.
Read MoreMade 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…
Read MoreI’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.
Read MoreMade 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.
Read MoreThe 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!
Perhaps that Canadian MP who was suggesting that the UN should send weapons inspectors into the USA may have been onto something…
Full article here.
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.
Read MoreJust 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…
Read MoreThis article talks about Tim Berners-Lee’s speech to the NSF on the Semantic Web.
Joshua Allen’s take on the speech is found here.
From Joshua’s site:
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.
Read MoreIt’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.
Read MoreInteresting article online at http://www.infoworld.com/article/03/02/06/06stratdev_1.html.
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…
Read More