Template
1
0
Fork 0
mirror of https://codeberg.org/forgejo/forgejo synced 2024-11-27 12:16:10 +01:00
forgejo/templates/repo/graph/svgcontainer.tmpl
wxiaoguang 5b89670a31
Use a general Eval function for expressions in templates. (#23927)
One of the proposals in #23328

This PR introduces a simple expression calculator
(templates/eval/eval.go), it can do basic expression calculations.

Many untested template helper functions like `Mul` `Add` can be replaced
by this new approach.

Then these `Add` / `Mul` / `percentage` / `Subtract` / `DiffStatsWidth`
could all use this `Eval`.

And it provides enhancements for Golang templates, and improves
readability.

Some examples:

----

* Before: `{{Add (Mul $glyph.Row 12) 12}}`
* After: `{{Eval $glyph.Row "*" 12 "+" 12}}`

----

* Before: `{{if lt (Add $i 1) (len $.Topics)}}`
* After: `{{if Eval $i "+" 1 "<" (len $.Topics)}}`

## FAQ

### Why not use an existing expression package?

We need a highly customized expression engine:

* do the calculation on the fly, without pre-compiling
* deal with int/int64/float64 types, to make the result could be used in
Golang template.
* make the syntax could be used in the Golang template directly
* do not introduce too much complex or strange syntax, we just need a
simple calculator.
* it needs to strictly follow Golang template's behavior, for example,
Golang template treats all non-zero values as truth, but many 3rd
packages don't do so.

### What's the benefit?

* Developers don't need to add more `Add`/`Mul`/`Sub`-like functions,
they were getting more and more.
Now, only one `Eval` is enough for all cases.
* The new code reads better than old `{{Add (Mul $glyph.Row 12) 12}}`,
the old one isn't familiar to most procedural programming developers
(eg, the Golang expression syntax).
* The `Eval` is fully covered by tests, many old `Add`/`Mul`-like
functions were never tested.

### The performance?

It doesn't use `reflect`, it doesn't need to parse or compile when used
in Golang template, the performance is as fast as native Go template.

### Is it too complex? Could it be unstable?

The expression calculator program is a common homework for computer
science students, and it's widely used as a teaching and practicing
purpose for developers. The algorithm is pretty well-known.

The behavior can be clearly defined, it is stable.
2023-04-07 21:25:49 +08:00

25 lines
1.5 KiB
Go HTML Template

<div id="rel-container">
<svg viewbox="{{Eval .Graph.MinColumn "*" 5}} {{Eval .Graph.MinRow "*" 12}} {{Eval .Graph.Width "*" 5 "+" 5}} {{Eval .Graph.Height "*" 12}}" width="{{Eval .Graph.Width "*" 10 "+" 10}}px">
{{range $flowid, $flow := .Graph.Flows}}
<g id="flow-{{$flow.ID}}" class="flow-group flow-color-{{$flow.ColorNumber}} flow-color-16-{{$flow.Color16}}" data-flow="{{$flow.ID}}" data-color="{{$flow.ColorNumber}}">
<path d="{{range $i, $glyph := $flow.Glyphs -}}
{{- if or (eq $glyph.Glyph '*') (eq $glyph.Glyph '|') -}}
M {{Eval $glyph.Column "*" 5 "+" 5}} {{Eval $glyph.Row "*" 12 "+" 0}} v 12 {{/* */ -}}
{{- else if eq $glyph.Glyph '/' -}}
M {{Eval $glyph.Column "*" 5 "+" 10}} {{Eval $glyph.Row "*" 12 "+" 0}} l -10 12 {{/* */ -}}
{{- else if eq $glyph.Glyph '\\' -}}
M {{Eval $glyph.Column "*" 5 "+" 0}} {{Eval $glyph.Row "*" 12 "+" 0}} l 10 12 {{/* */ -}}
{{- else if or (eq $glyph.Glyph '-') (eq $glyph.Glyph '.') -}}
M {{Eval $glyph.Column "*" 5 "+" 0}} {{Eval $glyph.Row "*" 12 "+" 12}} h 5 {{/* */ -}}
{{- else if eq $glyph.Glyph '_' -}}
M {{Eval $glyph.Column "*" 5 "+" 0}} {{Eval $glyph.Row "*" 12 "+" 12}} h 10 {{/* */ -}}
{{- end -}}
{{- end}}" stroke-width="1" fill="none" id="flow-{{$flow.ID}}-path" stroke-linecap="round"></path>
{{range $flow.Commits}}
<circle class="flow-commit" cx="{{Eval .Column "*" 5 "+" 5}}" cy="{{Eval .Row "*" 12 "+" 6}}" r="2.5" stroke="none" id="flow-commit-{{.Rev}}" data-rev="{{.Rev}}"></circle>
{{end}}
</g>
{{end}}
</svg>
</div>