go 1 template {{if}} condition

[DEXTER]

Hi

How can I test if if a variable matches a value
ex: {{if $name == "id"}} {$name}} {{end}}
or
{{if $index == 2}} {$index}} {{end}}


Thanks
Dexter

[Kyle Lemons]

You can define a function to check equality (using whatever definition of equality and whatever kind of values are appropriate for your project) and add it before parsing it with http://golang.org/pkg/text/template/#Template.Funcs and then it will be available in the template as (if memory serves) {{if equal "id" $name}} etc.

The reason there is no general function to do this is that any definition we choose for equality will not be appropriate for all applications, and there is no clear choice as to which would be the better one generally.

[Rodrigo Kochenburger]

The template package implements logic-less templates. So, you should avoid having this logics in the template and instead have those decisions in the go code and only set .Name for example if it should be displayed.

Then you'd just have {{.Name} or {{if.Name}}Hello {{.Name}}{{end}}.

Logic in the views are bad practice anyway.

[Gustavo Niemeyer]

On Mon, Apr 2, 2012 at 18:31, Rodrigo Kochenburger <div...@gmail.com> wrote:
> The template package implements logic-less templates. So, you should avoid
> having this logics in the template and instead have those decisions in the
> go code and only set .Name for example if it should be displayed.
>
> Then you'd just have {{.Name} or {{if.Name}}Hello {{.Name}}{{end}}.
>
> Logic in the views are bad practice anyway.

You mean that conditionals are not logic?

</rhetorical question>

--
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/plus
http://niemeyer.net/twitter
http://niemeyer.net/blog

-- I'm not absolutely sure of anything.

[Rodrigo Kochenburger]

Lol. No, you know what I mean. Checking for value existence is necessary, doing comparisons or anything else is not :)

Rodrigo Kochenburger

[Gustavo Niemeyer]

On Mon, Apr 2, 2012 at 18:49, Rodrigo Kochenburger <div...@gmail.com> wrote:
> Lol. No, you know what I mean. Checking for value existence is necessary,
> doing comparisons or anything else is not :)

Value "existence" is actually a comparison. Anyone that argues that
logic isn't necessary in templates either has never used templates or
doesn't know what logic is. That said, I certainly agree that people
often put *too much* logic in the template, which is a more subtle
issue.

[Kyle Lemons]

I think logic is fine in templates (especially conditionals and looping), but "computation", "manipulation" and "processing" are a bit beyond the scope of what a good templating library should be burdened with.  That said, the funcs mechanism is there precisely for farming out such tasks so the template mechanism needn't handle it.

[Gustavo Niemeyer]

Hey Kyle,

On Mon, Apr 2, 2012 at 19:32, Kyle Lemons <kev...@google.com> wrote:
> I think logic is fine in templates (especially conditionals and looping),
> but "computation", "manipulation" and "processing" are a bit beyond the

The fact you've quoted every word there means you probably understand
you're in shaky ground. I'd prefer not to get into that argument,
though.

[Rodrigo Kochenburger]

Gustavo,

Sorry, but you just seen like a person not worth arguing with. I simply answered DEXTER's question and you answered back being rude.

The template package is meant to be logic-less and the logic I was referring to was business logic or behavioral logic. Having those two things in the view (comparing something with another value to decide if you show something is that type of logic) are bad.

Anyway, if you want to learn about logic-less templates just google it (for sure you need to) otherwise stop trolling.

Rodrigo Kochenburger

[Gustavo Niemeyer]

On Mon, Apr 2, 2012 at 21:59, Rodrigo Kochenburger <div...@gmail.com> wrote:
> Sorry, but you just seen like a person not worth arguing with. I simply
> answered DEXTER's question and you answered back being rude.

My apologies. It certainly wasn't my intention to be rude, although
you're probably right.

(...)

> Anyway, if you want to learn about logic-less templates just google it (for
> sure you need to) otherwise stop trolling.

I wasn't trolling. I was providing some insight. I'll shut up now, though.

[Ugorji Nwoke]

Wow. Gustavo trolling?

Gustavo is arguably a member of the core golang team. He's just a classy guy who wouldn't respond in kind. 

K. Didn't want to ... but couldn't resist responding ...

[Rodrigo Kochenburger]

Apologies accepted and sorry if I was rude as well.

I just would like to say that I'm very well familiar with logic-less templates and support them as it tends to keep your templates/views much simpler. I also assumed that logic-less template was a well known concept so when you argued that checking for existence is also logic it seemed to me like you were trolling since checking for existence is necessary and even logic-less templates allow you to do that (in one way or another).

Also, the template package is -- at least for me -- logic-less, as it makes harder to have complex logics in the view and focus on displaying and navigating over a data structure.

Anyway, my apologies if I was rude as well, and thanks for helping this awesome language.

[Rodrigo Moraes]

I believe that the template package, as it is, requires you to put too
much presentation logic in your code.

Now I am trolling.

-- rodrigo

[Russ Cox]

I have found this function to be useful in my templates.
I install it as "eq".

// eq reports whether the first argument is equal to
// any of the remaining arguments.
func eq(args ...interface{}) bool {
if len(args) == 0 {
return false
}
x := args[0]
switch x := x.(type) {
case string, int, int64, byte, float32, float64:
for _, y := range args[1:] {
if x == y {
return true
}
}
return false
}

for _, y := range args[1:] {
if reflect.DeepEqual(x, y) {
return true
}
}
return false
}

Russ

[Rob 'Commander' Pike]

I would like to point out the loveliness of Russ's eq function. The
beauty is concentrated in the range loop, where x==y is an interface
equality check that verifies type and value equality while avoiding
allocation. It is enabled by the "case string, int, ..." etc. line,
which does the type check but leaves x of interface type.

By the way, there could be more types on that case; if you borrow this
function, be sure to add the types you need.

-rob

[Gustavo Niemeyer]

On Wed, Apr 4, 2012 at 21:16, Rob 'Commander' Pike <r...@golang.org> wrote:
> I would like to point out the loveliness of Russ's eq function. The
> beauty is concentrated in the range loop, where x==y is an interface
> equality check that verifies type and value equality while avoiding
> allocation. It is enabled by the "case string, int, ..." etc. line,
> which does the type check but leaves x of interface type.

Wouldn't it be equivalent to just having "switch x.(type) {", in this
case, since x was actually already of interface type? I guess you're
looking at it from the perspective of a language without such an
interface type, in which this would be pretty inconvenient to do?

[Rob 'Commander' Pike]

Yes. The x := x.(type) buys nothing if there is no single-type case.

-rob

[Johann Höchtl]

If memory serves well, there has been the discussion to include a form of equality check for the template package sometimes after Go1. Is this a candidate?

Russ

[Russ Cox]

Your function looks good to me.

Russ

[pabl...@gmail.com]

I know this is a quite old topic, but for whoever -like myself- falls in here trying to find binary comparison operators.

{{with $x := functionX "value1" "value2"}}{{if eq $x "some-result"}}true{{end}} {{end}}

Maybe there weren't in 2013 but exists in 2019

https://golang.org/pkg/text/template/#hdr-Functions