The most direct way to do what you want is to write the Go function
you need and call it in the template. It could do the lookup and
validate:
</li>{{if osIs "windows"}}class="active"{{end}}Windows</i>
osIs looks up "os" in data. Or there are a myriad of other ways to
factor this. You could even just do an equals function:
</li>{{if index data "os" | equals "windows"}}class="active"{{end}}Windows</i>
Perhaps equals should be pre-installed. I'm taking a slow-and-steady
approach to adding built-ins, though.
-rob
An equals function, as I proposed, makes all these examples trivial.
-rob
Unthinkable and ridiculous to ignore how easy it is to write your own
equality function if you need one. There's a whole programming
language at your disposal, called Go. The template "engine" is
designed to be driven by it, not to replace it.
The problem with building equality in is that one must decide what
equality is. What's right for one user may be wrong for another. (In
fact, Go doesn't even have a full definition itself, because of the
subtleties involved.) You know what form of equality you need, so you
should implement it. chances are, it's one line of code, much less
text than your complaint.
-rob
> I apologize for my tone, it was late and I was frustrated. What's wrong with including a function that just checks using ==? Maybe that's enough and if that doesn't work, then it makes sense for the developer to build their own.
It's not trivial; one must verify types and comparability and so on. It could use reflect.DeepEqual, and that may be the right answer, but it might not and that's a relatively slow operation.
As is often the case with library design, easy things are easy, difficult things are best delayed it's clear what the right answer is, as long as the user can work out the answer for his own problem without too much burden.
-rob
t.Funcs(template.FuncMap{"eq": reflect.DeepEqual})
Andrew