Where’s Lou

The Spark docs are out of date now in a few ways. Some features added from the recommendations in the discussion group haven’t been fully documented with nice code examples.

I wonder if there is a good editor for Drupal that supports code samples. I’ll have to look into that.

After that there are one or two more things to change. Maybe streamline the debug and precompile support. Maybe also look further into a Visual Studio language extension. Other than that, for the Spark view engine itself I’m thinking it might be getting pretty close to cutting the first official version.

I was ranting recently about the WiX toolset. Perfectly normal thing to do, of course, especially when you’re talking about creating installers. Today however when I returned to that task to do some more research I learned something about how it is designed which is so nice it’s overwhelmed the complaints I had earlier.

The situation is one where I’m using heat to generate file components for all of the assets that happen to be in a directory. The problem is no combination of switches would produce a wxs file that had an inventory I could pull in conveniently.

Then I saw an article describing the heat extensions architecture, specifically for mutators. This has cleared up all of the significant problems I was having pulling together boilerplate unattended msi generation.
Read the rest of this entry »

Some of the software I’ve been working on has been a pleasure to create. It’s all managed code, it’s very unit testable, the frameworks are well designed and developer-friendly. Castle Project and Asp.Net MVC for example are a joy to work with.

Two other things which came up this week were really brutal by comparison. One of them is Windows Installer XML (WiX) and the other is the Visual Studio Integration SDK.

Not that I’m saying they’re “bad.” I’m sure many people would swear by WiX as the best tool for creating installers there is. On the other hand maybe that’s just because all of the others are so much worse. The model of Product-Package-Feature-Component overlying a rats nest of Directory-File-Fragment-DirectoryRef elements, all bound up and interconnected with an overwhelming mass of Properties, Ids, Guids, Etc. Ouch! I know a lot of it is a function of the msi architecture, but the whole thing could use a serious injection of convention over configuration.

The thing with making Visual Studio Packages… It’s also kind of harsh going… It’s remarkable how the development environment is so modular in a way that enables you to provide so many different types of extensions. But since the interface is so firmly grounded in the world of Com, even Ole, it’s very challenging to implement. Plenty of deja vu, returning lots of VSConstants.S_OK, and trying to figure out what’s expected from a component by how the dozens of methods are invoked and in what order. And the biggest kicker is Reflector isn’t there to help you. My fingers are crossed Visual Studio 2010 will be a 100% managed rewrite.

So I guess you could say I’m mostly ranting. It’s just frustrating working with tools that take a great deal of effort to accomplish very modest, incremental tasks.

Turns out the answer is four! No wait… Five? Definitely less than six at least.

This is talking specifically about different ways one Spark files can pull in, render, or otherwise import another one. Of course the goal is not to create an unmanageable mess of individual files, rather to organize your files in a way that that the contents are more manageable and the html from one template to another isn’t unnecessarily redundant.

So let’s walk through the situations! Starting with the obvious ones.

Read the rest of this entry »

I saw a comment the other day on a post about asp.net mvc. The post was old enough that additional comments were no longer being accepted, but I thought the points raised were worth a response.

Today we see there are many view engines. What is the implication of that? They offer a lot of convenience, but you can’t step through them with the debugger. Are they even compiled? It could be that under load you will find that the view engine spends a lot of time interpreting the ’smart’ notation they came up with.

Talking of view engines, this is some spark I saw the other day, I’ll let the code speak for itself:

<test if="expression">
...
<else/>
...
</test>

And the answer is… Heck yeah it’s compiled! You can view the generated source at any time and you can absolutely step through it with a debugger. Lucky.

Read the rest of this entry »

A few more tricks added to Spark language. There was a question about how you would have an attribute that is present or not based on a condition. Say you have a bool isFooChecked variable and you want to do the following:

<input type="checkbox"
       name="foo"
       ${isFooChecked ? 'checked=""' : ''}></input>

That doesn’t work of course… Spark elements are parsed by the xml spec. Plus this type of thing really messes with typical xml editors like Visual Studio, so keeping roughly xml spec compatible is one of the goals.

After mucking around with a few different ways you could express a conditional attribute, while trying to keep the attribute valid, one of them really stood out. Since there’s already a ${expr} syntax to output text, adding a ?{expr} to control the output seemed like an intuitive approach.

So the above example becomes:

<input type="checkbox"
       name="foo"
       checked="?{isFooChecked}"></input>

Read the rest of this entry »