Introducing ExtensionIRNode and an implementation of templates based on
the new feature set.
Now TemplateIRNode is-a ExtensionIRNode. It's implemented using just
extensibility and isn't part of the standard razor codegen. I'm adding it
to the RazorEngine so that it's still there by default.
I've also included a pattern for visitors to special case
ExtensionIRNode-derived classes that they know about. This requires a
little bit of boilerplate but makes it easy to traverse just the nodes you
care about while keeping the set of nodes open.
For now the general codegen feature still hasn't had a refactor, but this
opens things up for us to start finishing things like MVC's @inject
directive.
This is a new abstraction that represents the api surface available for
codegen to target. Every kind of document should have an associated
RuntimeTarget or just use the default.
To prevent breakage, our DocumentClassifierBase class will provide a
default API set to implementors (like MVC).
I haven't fundamentally changed how codegen is done yet, I've just hidden
it behind a new abstraction. The RuntimeTarget now is also responsible for
selecting between design time and runtime.
The bulk of the noise here is from splitting a lot of the codegen stuff
into its own files.
- If needed, a phase/feature can always retrieve the syntax tree to lookup whether the parse tree was made in a "design time" fashion.
- Future DesignTime / Runtime specific bits will be added to their corresponding `AddRuntimeDefaults`/`AddDesignTimeDefaults` methods.
- Added TabSize,IsIndentingWithTabs and NamespaceImports to the RazorParser options. These are replacements for the existing RazorEngineHost abstraction.
- Added RazorParserOptions consumption pattern to more than just the parsing phase.
- Added a ChecksumIRNode to ensure Debugging can work.
- Updated tests to to react to new Checksum and Namespace nodes in the IR tree.
Ajay Bhargav Baaskaran
Ryan Nowak
N. Taylor Mullen