Section behavior used to be somewhat hackily determined from nullValue and
defaultValue, but it was messy. Now it has its own configuration and things are
more explicit.
Previously missing/null sections were treated as false, but if you set
nullValue to something, then missing sections became an error, but null
sections remained false. If you set defaultValue to something, missing sections
went back to being omitted. Kooky.
Now missing sections are omitted, unless you set strictSections to true, in
which case they become an error. nullValue and defaultValue have no impact on
section behavior.
There is no way to make null sections an error, but I don't see any demand for
that, so I'm going to leave that as a TODO.
Closes#60.
Mainly we also needed to trim around comment tags, but also there were a bunch
of tricky edge cases that were only partially addressed. This is some edgy
business!
The specs tests assumes an implementation will silently ignore invalid delims.
I think that's a bad idea, so I throw an exception on invalid delims. So I just
ignore those "tests".
This allows one to have a map with keys like "foo.bar.baz" even when not in
standards mode. If a whole key is missing, then we attempt to decompose it and
look it up piecewise.
Closes#55.
Fixes#39.
This fixes a bug where falsey values were not properly triggering inverted
sections, and consolidates some logic.
Also did some renaming. Couldn't help myself.
In javascript implementation, zero is a falsy value and is treated as a false boolean.
An option is added (false by default) to treat zero as a falsy value as in javascript implementation.
It means that section like:
{{#zeroValue}}foo{{/zeroValue}}
will not be rendered.
The groups with failing tests are currently commented out (everything except
interpolation). The main reason for failures are due to the requirement that
standalone lines that contain nothing but whitespace be stripped from the
output.
- triple-stache mode reverted to only work with {{{ }}} rather than working
with whatever default delims you set; I think this is more in the spirit of
the Mustache spec
- Compiler.withDelims takes a delims string rather than the internal Delims
class which callers don't care about or have access to
- nixed Delims constructors, made updateDelims fluent
- nixed DelimsTest, it wasn't testing anything that wasn't also already tested
by the functional tests in MustacheTest
If Compliler.nullValue contains a substring "{{name}}", then this substring
will be replaced with the name of variable.
For example, if nullValue="?{{name}}?" and variable is resolved to null,
then string "?foo?" will be used.
I've ironed out most of the kinks, but the GWT unit test still fails because
we're forced to do some sneaky things with java.io.Reader/Writer. I think it
will all work when compiled to JavaScript, so I need to check it in a real
project.
Kali/Bertrand convinced me that being consistent with other Mustache
implementations is more important than whatever wacky reasons I was harboring
for keeping compound variables different than singleton sections.
a pluggable component.
This allows scaling down to the GWT environment by hiding the reflection code
via GWT's super source mechanism.
And it allows scaling up to non-Java languages (like Scala) by allowing the
library client to extend the DefaultCollector and teach it about Scala
Iterators, Iterables and Maps.
I also just realized that GWT has no facilities for Reader and Writer, which is
going to complicate making things work in GWT even further. But for now, I'll
just leave things as is.
Otherwise you get undesirable newline skipping if you do things like, for
example:
{{#foos}}
{{bar}}{{^-last}}, {{/-last}}
{{/foos}}
where you want the newline after {{/-last}}, but it was getting skipped.
Reorganized the parser as a proper class so that I could easily reenter it to
deal with things like optional second open and close tag characters. In the
process, made the parser simply pass through certain kinds of malformed input
as text.
I hope to go further in this regard, avoiding parse exceptions in favor of
simply showing the user the malformed output unsubstituted. It's just as easy
to see "{{broken blah blah" in ones result template as it is to read exception
messages, and apps that wish to use JMustache for things like end-user
templates will find this much more agreeable.
for use when variables resolve to null, but still wishes for exceptions to be
thrown when values are not resolvable (i.e. are typos). Pre-existing behavior
is preserved if one uses defaultValue() or does not change the default
configuration.
Nota bene: there are complexities, so be sure to read the documentation.
rather than "missingVariableValue" because the value is used any time a
variable resolves to null, not necessarily just when it is missing. If you
have a context like:
new Object() {
String foo = null;
}
and reference {{foo}} in your template, foo is not missing, per se, but the
default value will still be used for it.
Michael Bayne