5b89670a31
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.
35 lines
1.5 KiB
Handlebars
35 lines
1.5 KiB
Handlebars
{{template "base/head" .}}
|
|
<div role="main" aria-label="{{.Title}}" class="page-content repository file editor upload">
|
|
{{template "repo/header" .}}
|
|
<div class="ui container">
|
|
{{template "base/alert" .}}
|
|
<form class="ui comment form" method="post">
|
|
{{.CsrfTokenHtml}}
|
|
<div class="ui secondary menu">
|
|
<div class="item fitted treepath">
|
|
<div class="ui breadcrumb field {{if .Err_TreePath}}error{{end}}">
|
|
<a class="section" href="{{$.BranchLink}}">{{.Repository.Name}}</a>
|
|
{{$n := len .TreeNames}}
|
|
{{$l := Eval $n "-" 1}}
|
|
{{range $i, $v := .TreeNames}}
|
|
<div class="divider"> / </div>
|
|
{{if eq $i $l}}
|
|
<input type="text" id="file-name" value="{{$v}}" placeholder="{{$.locale.Tr "repo.editor.add_subdir"}}" autofocus>
|
|
<span data-tooltip-content="{{$.locale.Tr "repo.editor.filename_help"}}">{{svg "octicon-info"}}</span>
|
|
{{else}}
|
|
<span class="section"><a href="{{$.BranchLink}}/{{index $.TreePaths $i | PathEscapeSegments}}">{{$v}}</a></span>
|
|
{{end}}
|
|
{{end}}
|
|
<span>{{.locale.Tr "repo.editor.or"}} <a href="{{$.BranchLink}}{{if not .IsNewFile}}/{{.TreePath | PathEscapeSegments}}{{end}}">{{.locale.Tr "repo.editor.cancel_lower"}}</a></span>
|
|
<input type="hidden" id="tree_path" name="tree_path" value="{{.TreePath}}" required>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<div class="field">
|
|
{{template "repo/upload" .}}
|
|
</div>
|
|
{{template "repo/editor/commit_form" .}}
|
|
</form>
|
|
</div>
|
|
</div>
|
|
{{template "base/footer" .}}
|