This ensures that if you enter a conditional block while inside a list
block, the list "state" from the outer list will still be visible. For
example (somewhat contrived, but gets the point across):
{{#list}}
{{#name}}{{-index}}. {{.}}{{/name}}
{{^name}}{{-index}}. No name!{{/name}}
{{/list}}
Yields something like:
1. Bob
2. Mary
3. No name!
4. Jim
Fixes#90.
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!
There's unfortunately no sane way to do the same reflection-like array access
in GWT, so we just have to enumerate all of the primitive types.
I could have just left this only in the Java backend, but I would prefer to
avoid differences between behavior on the JVM and behavior in GWT whenever
possible.
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.
after_script also runs after the cache is stored, so if we do the coveralls
stuff in after_script we have to redownload a bunch of Maven crap every time.
Hopefully I can do test and then the coveralls stuff in one Maven command,
otherwise I'll have to break things out into two invocations...
Also disabled GWT htmlunit tests because it seems to choke on the fact that I
factored the GWT bits into src/main/gwt.
It should work fine because everything is in target/classes by the time GWT
runs, and target/classes is on GWT's classpath, but it doesn't. I'm sure
someone is doing something clever along the way and passing the value on to the
customer.
Michael Bayne