GWT doesn't provide Collections.synchronizedMap so we can't default to that.
Because we don't want someone to extend BasicCollector on a multi-threaded
platform and get an unsynchronized HashMap, which would cause things to fail,
we instead make creatFetcherCache abstract and document that if you extend
BasicCollector, you need to return a synchronized map (if the platform you're
targeting is multithreaded).
The ' entity is an XML entity, rather than an HTML entity, and is not
supported by Internet Explorer. The numeric form is supported in both XML
and HTML.
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.
Call missingVariableValue(value) on a Compiler object to get a new
version that will insert "value" for missing values (rather than
throwing an exception). Useful when you have templates you would
rather generated *something* instead of erroring or for when objects may
have null values themselves.
into inner interface Mustache.TemplateLoader, eliminated top-level
UnsupportedTemplateLoader. Eliminated static configuration of active template
loader in favor of per-Compiler configured template loader, which is how all
other configuration is handled.More complex tests are needed, but will have to
wait until I'm less sleep deprived.
whether we're seeing {{.}} or not. Also reinstated treatment of ".foo" as a
compound key. I'm not 100% sure that makes more sense than treating ".foo" as a
simple key, but I'd rather change less behavior than more when making the {{.}}
fix.
This is implemented so that by default, the library does not support template loading (which it already does not)
but instead of treating partial calls as a context lookup for a ">key", an exception is thrown.
in the replacement for this tag." This is already supported via {{&foo}} as
well, but we like to be thorough.
Also generate MustacheParseException when parsing (a subclass of
MustacheException) mostly for convenience in testing.
not search parent contexts for name bindings, nor do we support compound keys.
Also added support for {{.}} which has the same semantics as {{this}}. I must
have missed this when reading the Mustache spec.
Michael Bayne