- The `@page` directive will now look for malformed directives and treat a view as a Razor page based on the existence of the malformed directive.
- Updated the `PageDirective` type to contain a reference to its responsible directive node.
- Added unit tests to validate malformed directives were picked up accordingly.
- Updated code generation test baselines to reflect the new malformed directive understanding.
#1448
- Prior to this imported `@page` directives would flow through the Razor system without error. This resulted in inconsistent behavior between MVC and Razor. Now, imported `@page` directives result in diagnostics on the page directive node.
- Added two tests to verify that we still treat views with imported page directives as Razor pages BUT we also log a diagnostic on the page directive node.
- Renamed the `ViewComponentDiagnosticFactory` class to `RazorExtensionsDiagnosticFactory` so it can be used for more than just view component diagnostics. This way we can ensure that our diagnostics don't end up overlapping.
#1503
- Rename `CSharpRenderingContext` => `CodeRenderingContext`.
- Rename `CSharpCodeWriter` => `CodeWriter`
- Rename `BasicWriter` => `IntermediateNodeWriter`
- Rename `...BasicWriter` => `...NodeWriter`
- Made `CodeRenderingContext` a public abstract API. Left temporary TagHelper pieces in the class since these will be removed soon.
- Moved several `CodeRenderingContext` methods into extension methods. These make use of the Items collection.
- Moved the reporting of missing code target extensions into the `ExtensionIntermediateNode`. This is the integration point of `CodeTarget`s and `CodeRenderingContext`s; therefore, it made more sense existing there.
- Left SetRenderChildren/SetRenderNode as extension methods due to how they're wired up. Aka, to create a `CodeTarget` you need a `CodeRenderingContext`... To Create a `DocumentWriter` you need a `CodeTarget`... To set the render methods on the context you need a `DocumentWriter`.
- Updated tests to utilize the new code renering constructs.
- Moved code generation testability features from `CSharpLoweringPhase` to the `CodeRenderingContext.Items`.
#1043
instead of methods
More polish to the tag helper descriptor builders.
- Expose underlying builders as getter only list
- Added AsDictionary() extension method to BoundAttributeDescriptorBuilder
- Expose diagnostics as RazorDiagnosticCollection
- Got rid of Require** prefix in TagMatchingRuleBuilder
- Workaround issue aspnet/Razor#1492 by copying the test descriptor
extensions
This makes it possible to use another 'kind' of tag helpers, which isn't
possible today.
This also further decouples the tag helper api surface from the default
implementation.
VCTH now have their own 'kind'.
Also improved generation of display names and error messages where it
was coupled to the type name.
- Updated integration code gen and IR bits to reflect new directive usage.
- Updated existing unit tests that happened to test directives in code blocks to now test what happens when they exist at the document level. Being inside of a code block is now invalid and we have separate tests for that scenario.
#1376
- Replaced the magic strings with extension methods that produce the same behavior as the string keys did.
- Added tests to validate new extension methods.
#1307
The new @namespace directive isn't sanitizing class and namespace names
when generating them. This means that a file-system-legal character like
'-' will show up in a class name, and that's not good.
Note that the old code paths (document classifiers) already had tests for
this and did it properly. It was only missing from @namespace.
This change adds an API for Tag Helper discovery.
I also got rid of the 'design time' flag for the provider as an
experimental change. We need to think through the consequences of this
before committing to it. Right now I've left those tests failing until we
can make a decision.
This change decouples VCTH discovery a bit more, but we're still not ready
to move that into a the MVC extensions assembly. For that we need the
ability to discover the MVC extensibility.
This change removes the default usings for 'System' and
'System.Threading.Tasks' and adds them to the MVC template engine.
This is preparation for removing this feature from the razor options, I
wanted to get all of the intentional diff out of the way.
- This involved not using the `First()` method when reading the directives tokens.
- Added two tests to validate an empty directive token and a missed directive token for the `@namespace` directive.
#1268
- Found that our extensible directive string parsing system wasn't consistent with the rest of the extensible directive tokens. Basically, if there were malformed string tokens we'd consume them and pass them along to extensible directive passes. This was a big no-no because it means extensible directive passes weren't able to rely on tokens being passed to them being well-formed.
- Fixed up existing extensible directive tests that relied on output of string tokens.
#1247
- Made a targeted fix to PageDirective that stops it from crashing Visual Studio when its malformed.
- Added unit test to validate PageDirective didn't throw when attempting to determine if something was a page.
- Added an integration test to validate malformed page tags can make their way through the entire Razor pipeline and don't destroy the rest of the content.
#1247
- Prior to this TModel would be set to a potentially non-fully qualified name. This would cause errors in default MVC templates.
- Regenerated test files to reflect new TModel.
- Updated unit test to reflect new behavior.
#1222
The problem is that @inject uses the type name, and @namespace can change
it. Setting an explicit order makes sure that these things happen in a
sensible sequence.
This change adds support for @namespace, and introduces a set of
changes that are needed to support @namespace in the parser.
@namespace and @class have always been treated as reserved words by Razor,
with the intent that someday they would be allowed as directives.
This changes makes that possible.
You will still get an error about @namespace being a reserved word if you
don't have the directive.