This commit adds a custom index template function that deviates from the stdlib
simply by not returning an "index out of range" error if an array, slice or
string index is out of range. Instead, we just return nil values. This should
help make the new default function more useful for Hugo users.
Fixes#1949
This commit fixes a few things:
1. `given` is now a variadic parameter so that piping works properly
2. add separate template tests to make sure piping works
3. support time values
4. add more tests of the dfault function
The common is the `where` func and this:
```
panic: reflect: call of reflect.Value.Type on zero Value [recovered]
panic: reflect: call of reflect.Value.Type on zero Value
```
There is no good reason to export all the template funcs:
* They're not used outside the templates.
* If usable in other packages, they should be moved (to helpers?)
* They create too broad an interface;
users of the tpl package don't see the forest for all the trees.
Add humanize (inflect.Humanize) to the template funcMap. Documentation and
tests are included.
Various code cleanups of the template funcs:
- Break pluralize and singularize out into stand-alone funcs.
- Sort the list of funcMap entries.
- Add some minimal godoc comments to all public funcs.
- Fix some issues found by golint and grind.
This fixes a exported field check condition in a way described at Go
issue https://golang.org/issue/12367
According to the issue comments, this fix should be safe under Go 1.6.
`where` template function's internal condition check function doesn't
check boolean values and always returns `false` silently.
This adds missing boolean value comparison to the function.
`where Values ".Param.key" true` like clause can be used.
Only "=", "==", "eq", "!=", "<>", "ne" operators are allowed to be used
with a boolean value. If an other operator is passed with it, the
condition check function returns `false` like before.
'sort' template function used to accept only each element's struct field
name, method name and map key name as its second argument. This extends
it to accept a field/method/key chaining key string like
'Params.foo.bar' as the argument. It evaluates sub elements of each
array or map elements and sorts by them.
Typical use case would be sorting pages by user defined front matter
value. For example, sorting pages by 'Params.foo.bar' is possible by
writing the following template code
{{ range sort .Data.Pages "Params.foo.bar" }}
{{ .Content }}
{{ end }}
It ignores all leading and trailing dots so "Params.foo.bar" can be
written in ".Params.foo.bar"
This also fixes the issue that 'sort' cannot evaluate a pointer value.
Fix#1330
sort template function returns `[]interface{}` type slice value
regardless of its original element type.
This fixes it to keep the original element type. For example, if it
sorts `map[string]int` type value, it returns `[]int` slice value
instead of `[]interface{}` slice value.
`where` template function's internal condition check function always
returns `false` when a target value doesn't exist or it's nil value but
this behavior makes it difficult to filter values which doesn't have a
particular parameter.
To solve it, this adds nil value comparison to the function.
`where Values ".Param.key" nil` like clause can be used for the case
above.
Only "=", "==", "eq", "!=", "<>", "ne" operators are allowed to be used
with `nil`. If an other operator is passed with `nil`, the condition
check function returns `false` like before.
Fix#1232
Where `first` will return the first N items of a rangeable list,
`after` will return all items after the Nth item.
This allows the user to do something with the first N items and
something different with the remaining items after N.
`substr` template function takes one or two range arguments. Both
arguments must be int type values but if it is used with a calclation
function e.g. `add`, `len` etc, it causes a wrong type error.
This fixes the issue to allow the function to take other integer type
variant like `int64` etc.
This also includes a small fix on no range argument case.
Fix#1190
`where` tpl function doesn't support `time.Time` type so if people want
to compare such values, it's required that these values are converted
into `int` and compare them.
This improves it. If `time.Time` values are passed to `where`, it
converts them into `int` internally, compares them and returns the
result.
See also
http://discuss.gohugo.io/t/future-posts-and-past-posts/1229/3
