- move a few functions to the prototype
- call bind() on the function that's used as a NodeVisitor
- for clarity, replace `currentParser` with `this` (made possible by
the previous changes)
- for consistency, move currentSourceName to the prototype
`cache` and `settings` are no longer private fields.
This was done so
that plugins could use this class without messing up
the final output
when template name collisions occur. i.e. each instance
has it's own
template cache. The `settings` were made specific to each
instance so
that users of this class could redefine the underscore
template
settings if they want to.
The new underscore template includes a tag sequence for escaping. I
added an override for that tag that is consistent with our overrides for
evaluation and interpolation.
Added filters for input end of line character where evilstreak/markdown
was called because it chokes on `\r\n`. We'll have to do this to any
input to this markdown parser unless/until they accept my pull request
and we update the upstream source.
https://github.com/evilstreak/markdown-js/pull/64
This was causing it to mis-calculate the paths, and end up losing the
output directory entirely, and overwrite the template static files
with themselves, resulting in truncation to zero-length. Of course,
they were also missing in the output.
It was expecting to be able to split paths on
System.getProperty("path.separator"), but that describes how to put a
path together, not how to take one apart, which is more complicated.
In particular, in windows, / is as valid a separator as \ in all but a
few UI contexts.
And since we need to pass / in paths that may get turned into URI's,
it's important to handle this correctly.
Java already provides a File facility to handle these sorts of operations.
This patch makes use of java.io.File to:
1) Find the parent of a File for dirname.
2) Find the name of a File for basename.
It also now makes use of substring for removing the ext for basename,
rather than Array.prototype.slice + join(""). I'm not sure what that
was all about... It does have the effect of ensuring it's a Javascript
String, but calling String() has the same benefit and is much more clear.
You can put that back if there was a reason for it, but it looks just
confused to me.