API: Whitespace trimmed from custom form field templates
The introduction of trailing newlines on all template files introduced
some changes that needed to be made.
Notably, whitespace has been trimmed from rendered form field templates.
This is the minimal impact to SilverStripe developers, as it preserves
the behaviour of the default field types, but I’ve still noted as a
change.
The main benefit of this is so that authors who make use of
.editorconfig don't end up with whitespace changes in their PRs.
Spaces vs. tabs has been left alone, although that could do with a
tidy-up in SS4 after the switch to PSR-1/2.
The command used was this:
for match in '*.ss' '*.css' '*.scss' '*.html' '*.yml' '*.php' '*.js' '*.csv' '*.inc' '*.php5'; do
find . -path ./thirdparty -not -prune -o -path ./admin/thirdparty -not -prune -o -type f -name "$match" -exec sed -E -i '' 's/[[:space:]]+$//' {} \+
find . -path ./thirdparty -not -prune -o -path ./admin/thirdparty -not -prune -o -type f -name "$match" | xargs perl -pi -e 's/ +$//'
done
Currently the only way the extend SSTemplateParser is to define a class
extension of it and then tell the injector component to use your new
custom class. This new change allows a user to define new "open blocks"
and "closed blocks" for SSTemplateParser to use without needing to
recompile the real SSTemplateParser class.
The following example shows how the functionality can be used
to add a new <% minify %>…<% end_minify %> syntax to the template parser
In a config.yml file, define the new minify closed block to call the
static function "Minifier::minify"
```
Injector:
SSTemplateParser:
properties:
closedBlocks:
minify: "Minifier::minify"
```
Define a new class with the minify static method that returns the new
template code when regenerating templates:
```
class Minifier {
public static function minify(&$res) {
return <<<PHP
{$res['Template']['php']}
\$val = zz\Html\HTMLMinify::minify(\$val, array('optimizationLevel' => zz\Html\HTMLMinify::OPTIMIZATION_ADVANCED));
PHP;
}
}
```
Since ViewableData was returning a casting helper for Link, but DataObject was
only using $this->$fieldname to set values on that casting helper, you could
not use <% if Link %> (or <% if $Link %>) in your templates because Link is not
a field, and thus had no value to be set on the casting helper, causing
hasValue to think that there was no value. Since DataObject->dbObject says that
"it only matches fields and not methods", it seems safe to have it call db(..)
to get the field spec, and not call ViewableData->castingHelper at all.
The parser could sometimes generate invalid code if the
source-file-comments were enabled, this moves the comments outside the
html-tag to circumvent these problems, update test as well.
The entire framework repo (with the exception of system-generated files) has been amended to respect the 120c line-length limit. This is in preparation for the enforcement of this rule with PHP_CodeSniffer.
