I get a certain amount of satisfaction when I find the right way of modelling something in code. I’ve been working with a Zebra printer lately, and is one of those really annoying devices you must send “special” instructions to. I ended up building up some generic commands for representing the language, and then built a small Domain Specific Language (DSL) for using it in our application.
Here’s an example of our code (modified for public consumption of course):
public class StandardLabel
{
private string instructions;public string ToZebraInstruction()
{
return instructions;
}
public StandardLabel(string barcode, string name, string passion)
{instructions = new LabelBuilder()
.IconAt(485, 10)
.BarCode(barcode).At(10, 10)
.Label(“Name:”).At(10, 150).WithValue(name).At(150, 150)
.Label(“Position:”).At(10, 250).WithValue(position).At(150, 250)
.Label(“Passion:”).At(10, 350).WithValue(passion).At(150, 350)
.ToZebraInstruction();
}}
The code above is useful for representing the layout for a label similar to the following (also modified for public consumption):
I think the best bit about this block of code, is that it didn’t take any longer to abstract, and I’ve been able to get our Business Analyst to actually change the layout with only a minimal amount of hand holding. In fact they ended up modifying the label’s entire layout to suit the customer without needing to involve a developer. I like to think it’s a great outcome.
Interesting. Some years ago I was charged with creating a document generation and templating system that could accommodate a number of barcode formats, Zebra being one of them.
The DSL we ended up using was expressed in XML.
Simplifying the markup for barcode printers is an absolute must. Their document format is horrendous at best.