Expose Compiler to extend features

[lazd]

@terinjokes, it's easy to expose the Compiler constructor, but there are a number of utility methods that aren't on Compiler's prototype:

• usesVariables(string)
• safe(string)
• isBlank(string)
• isInline(node)
• isFragCandidate(node)
• hasSubstitutions(node)
• hasConditionAttributesOrHandles(node)
• isRealElement(node)

I'll move those to the prototype, then export Compiler so it's available. Would that give you what you need?

[terinjokes]

@lazd I honestly just needed to override setTextContent to use a utility library, since el.textContent isn't cross-browser enough for my needs.

(That said, all the usages of setTextContent went away when I fixed the stripWhitespace bug I'm clean up to PR to you…)

[lazd]

@terinjokes, I went ahead and simply exposed the Compiler constructor in the exported module. You can now extend it and override setTextContent or simply monkey-patch the prototype.

That should handle your use case. If the other functions I mentioned become required, we can just throw them on Compiler's prototype.

This issue opened my eyes to the fact that people are definitely going to want to change DOMly's output in various ways, so the compiler should facilitate that. I'll be thinking about that in general, let me know if you have thoughts on how to expose that kind of flexibility in a simpler way.

[terinjokes]

@lazd how often do you do releases?

[lazd]

I haven't released yet as I was trying to get a solid test on another issue I closed with @cif. I'll release tomorrow.

[lazd]

@terinjokes, a bit late, but I've released DOMly@0.0.7 that includes the fix for this issue.