Building a CMS using XML, XSLT, Ant and ImageMagick
Not so long ago a freelance client approached me with some updates for their website. The site has been growing organically since 2000 and therefore was a big mess. Several attempts to port the site to a CMS driven system failed largely because those CMS systems are usually to complex for our needs (Typo3) or not flexible enough (Joomla, WordPress). So as I was faced with updates to all the updates including image updates which in turn needed thumbnails to be generated. The same day I stumbled randomly over the xsl:result-document function in XSLT 2.0 which allows you to transform a single XML file into several output files. That sparked an idea with me: why not use that to build a CMS system using XML technologies? I've toyed around with Cocoon a couple of years ago but that was not what I was looking for. So I looked for other technologies...
This post is a write-down of my experiences building a XML/XSLT driven simple CMS system. In it I will show you the required technologies, my approaches and my solutions to problems I've encountered. You'll need a solid understanding of XML at least, understanding of Ant and XSLT helps a lot, too.
This post contains tons of XML and I tried my best to format it in a readable way — in fact I've spent hours to get everything nicely on the screen.
Grails GraniteDS Plugin and Flex Modules – Could not resolve ? to a component implementation
I'm currently working a lot with the Grails GraniteDS plugin. Just recently I've started to separate my application into modules and ran into a really nasty error.
It took me some time to figure it out, hopefully I can save you from going through all this.
The Flex web tier compiler usually gives me this error:
Error: Could not resolve <namespace:Component> to a component implementation. <namespace:Component/> error during compilation Could not resolve <namespace:Component> to a component implementation.
Initial research confirmed what I thought, this error is caused by a mismatch between a XML namespace declaration and the actual location of a component. However the location and the namespace declaration looked right and the issue occurred only after I had moved the questionable component into a separate module.
After two painful hours I realized that the Flex webtier compiler, as configured with GraniteDS, resolves namespaces relative to modules, not relative to the source folder. D'oh!
The solution I came up with was simple, might be naïve though. I figured that if resolution is relative to the Module and not to the source folder, there might be no such source folder as I would expect it. A quick look into the flex-config.xml found in <GRAILS_PROJ>/web-app/WEB-INF/flex/flex-config.xml confirmed this:
<!-- List of path elements that form the roots of ActionScript class hierarchies. --> <!-- not set --> <!-- <source-path> <path-element>string</path-element> </source-path> -->
So there is no explicit source path set. So I changed it so it would point to <GRAILS_PROJ>/grails-app/views/flex:
<!-- List of path elements that form the roots of ActionScript class hierarchies. --> <!-- not set --> <source-path> <path-element>../../../grails-app/views/flex</path-element> </source-path>
Voilá - it works. However, as mentioned earlier, this might be a very limited solution, but for now it works.
Pages
My Twitter
Tags
Categories
- Auslandspraktikum
- Cool Tech
- Das tägliche Photo
- Flex
- Grails
- Grillen
- Lego
- LiquiBase
- Lustige Bilder
- Martial Arts
- New York City
- Panorama
- Toronto
- Travel
- Uncategorized
- Uni
- USA