Being pragmatic (aka. lazy) is a desirable skill in a developer. Mainly because time spent in a client task has, most of the time, a direct relationship to the size of their bill. And the better bang or their money, the more likely is to get another engagement. And so on…
Been said that, I am no big fan of code generation but I certainly see the point of it sometimes. And when it is me creating the generator of the code and it helps to cut the time performing boring and repetitive tasks, I am more than willing to take the chance.
The frame is: tabular data coming from a web page (Html) that has to be somehow manually enriched with extra information, and then some code has to be generated based on that enriched data for the use of developers. Not rocket science, but really boring to do manually (no matter how helpful snippet technology within the IDE could be).
So having a history with XML and related technologies (XSL, XPath, XSomethingElseICannotRecall,…) and being the primary input of my task an Html page I took the “Way of the Xml” (named after a great memory of mine “The Way of the Exploding Fist”) by transforming that piece of “angly bracket” soup into another more palatable soup. So, after step 1, I have a bunch of Xml with just the format and the information I need, thanks to the very concise syntax of XSL and a mix of memory-and-google fu.
After some boring manual “enrichment” of that Xml I have everything I need to start converting it into code. Which tool to use now? I thought of templating framework for code, such as CodeSmith (which I used in the past), but I discarded it after a brief Google-investigation. After that, my pragmatism sense (not somewhat the same as spider sense as it turned out) tingled and pointed me into sticking with XSL all the way. How hard could it be? And I had already taken advantage of some of its powers…
The first part of the code to be generated was a piece of cake for XSL as all the information was available in the Xml with a gentle touch of XPath. But alas, stormy clouds were in the horizon when the second piece of generation demanded string manipulation of the Xml data: I needed to “pascalize” (have SomeTextInPascalCapitalization) some data for a member name. I remember from the past that this was not going to be pretty. But from “not pretty” to “ultimate nastiness” there is a looong way. And a long way that takes surprisingly short time to be run:
- google some cleverly chosen keywords
- getting a bunch of promising hits
- read about custom templates with parameters
- read about call-template
- freak out with the translate() function
- nervous breakage after seeing whole alphabets with its correspondent capitals
- fade to black
After passing away, I was this close to abandon XSL and move somewhere else when Visual Studio pointed me out the <msxsl:script> tag that allowed me use javascript. Hooray!! As I cared nothing about portability of my XSL I implemented a simple function that pascalized a given string and voilà, my code generation was finished in no time.
The take-away from this little story is not unveiling my utter ignorance about XSL and the akin, but also that pragmatism must not be confounded with stubbornness (I stick with whatever I thought it was going to be THE tool for the task). Instead, whenever I got the first signs that I was sliding down a rabbit hole, I should have re-assessed and question what I was doing. I would have probably chosen a different tool.
And that is exactly what I am going to do whenever the data in the html changes and I have to regenerate the code: I am going for shiny new T4 ;-) Big boys and their new toys, you have to love them.