You can't normally reflectively access methods on Map because it has a
special fetcher, but being able to reflectively access 'entrySet' is
super useful when you want to iterate over the keys+values of a map, so
we're going to hack it in there. Ha!
For some reason I sort of blocked from my mind the fact that none of the actual
tests were running in GWT. Really I was just testing that things compiled.
So now the tests actually run in GWT. This means I had to split the tests that
rely on method/field lookup via reflection into a separate file because that
stuff will never work with GWT. I also changed a bunch of the other tests not
to surreptitiously use reflection because they were ostensibly testing
something else, so no point in those tests being GWT-incompatible just for
kicks.
This also means we can't use JUnit 4 annotations (sigh, I wish GWT would step
out of the stone age, but that's a whole other fiasco that I don't even want to
think about). So some of the tests that were using @Test(expected=FooException)
had to be rewritten to manually catch the exception and fail if it was not
thrown.
Anyhow, now most of the tests are in fact running in GWT (when you do "mvn
integration-test") and the test that I expected should fail in GWT is in fact
failing. Yay!
Fortunately this did not require using any JDK 1.8-specific APIs, just
searching (via reflection) through the set of interfaces implemented by a class
in addition to its super-classes.
One downside is that the transitive set of all implemented interfaces could be
much larger than the super-class chain, but this is the last thing we search,
so in theory we only even get here if we were about to fail to find the getter
entirely.
This also means that our tests have to be compiled and run with Java 8, because
I was not in the mood to figure out how to do all the complex Maven jockeying
to have a special JDK8 profile and disable JDK8 tests in the normal profile and
re-enable them in the JDK8 profile and blah blah blah, just shoot me now.
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.
Michael Bayne