- Several classes are legacy and left over from many changes in the Razor code base. This changeset removes those classes.
- Also moved several corresponding test cases
#778
- #760
- using a `NullHtmlEncoder` improves `TagHelperContent.IsEmptyOrWhiteSpace` semantics
- e.g. a tab is still a tab after encoding
- also avoids `NotImplementedException`
- implement `Write(char)` for char-by-char `IHtmlContent` corner case
- Removed `Minimized` from `TagHelperAttribute` and replaced it with `HtmlAttributeValueStyle`.
- Removed `AddMinimizedTagHelperAttribute` method from `TagHelperExecutionContext` since we always provide a `HtmlAttributeValueStyle` now.
- Stopped manually escaping double quotes because we now know how an attribute was originally written.
- Updated tests to account for new attribute format (from kvp).
#705
- Today `TagHelperContent`s always allocate their underlying buffer even though they typically only ever have a single entry. Added a field to enable us to only allocate the backing buffer when we absolutely need to.
- Removed `IsEmpty` from `TagHelperContent` since it was not used in any of our `TagHelper`s for simplification. Changed `IsWhiteSpace` naming to be `IsEmptyOrWhiteSpace` since it can be used to indicate either state.
- Updated tests.
#621
- Previously we'd do `executionContext.Output.Content = await executionContext.Output.GetChildContentAsync()`. The problem with this approach is that it returned a `Task<TagHelperContent>` which could not be optimized when building in release.
- Added test to validate `SetOutputContentAsync` does the appropriate thing.
#721
- `TagHelperOutput` and `TagHelperContext` lifetimes now mach `TagHelperExecutionContext`s. This means once a set of `TagHelper`s have run on a tag the `TagHelperOutput`/`TagHelperContext` will be re-used.
- Added tests to validate the various `Reset`/`Reinitialize` methods behaved correctly.
- Updated codegen to no longer set `TagHelperExecutionContext.Output`.
#719
- was missing when writing out full name of an `enum` value
- was missing in one case when writing out `TagHelperAttribute` type name
nit: updated `CSharpTagHelperFieldDeclarationVisitor.WritePrivateField()` to always include the prefix
- no change in generated code but centralizes the prefix addition and reduces intermediate `string`s
- After discussion offline to maintain consistency we decided to also remove `CodeBase` fallback in the net451 scenario. This will keep CoreCLR and net451 scenarios more consistent.
- Removed `CodeBase` validation tests.
- Added `GetAssemblyLocation` extensibility point to enable proper testing of the `TagHelperDesignTimeDescriptorFactory`.
#709
- Added the ability for users to opt into CSS `TagHelper` selectors in their required attributes by surrounding the value with `[` and `]`. Added operators `^`, `$` and `=`.
- Added tests to cover code paths used when determining CSS selectors.
#684
This change implements the new API for flattening content in Razor.
Also, some optimizations to avoid allocations on paths where we need
to encode HTML attribute values.
- aspnet/Coherence-Signed#187
- remove `<RootNamespace>` settings but maintain other unique aspects e.g. `<DnxInvisibleContent ... />`
- in a few cases, standardize on VS version `14.0` and not something more specific
- Hoist `TagHelperAttribute` creation into `private static readonly` fields to avoid allocations on every request. With the recent `TagHelperAttribute` change that made them immutable we can now pre-allocate them without worry of them being modified.
- Added two extra class configuration pieces to enable pre-allocation.
- Updated test files to showcase new pre-allocations.
#600
- Currently the `TagHelperScopeManager` creates a new `TagHelperExecutionContext` per `TagHelper` on a given page. With this change the max number of `TagHelperExecutionContext`s per page is the number of nested levels that exist.
- Added two tests validating that specific pieces of `TagHelperExecutionContext` are updated as expected.
#674
- Changed the variable used to render templates (`HelperResult`s) so they can be used inside of sections.
- Updated section test file to showcase nested scenario. Also Regenerated existing test files.
#572
- Not all `TagHelper`s have unbound HTML attributes or any attributes at all. A great example of this is MVC's input `TagHelper` which usually takes the format of `<input asp-for="..." />`. By lazily initializing we don't build extra attribute lists where not needed.
- Moved `TagHelperContext` and `TagHelperOutput` creation to CreateX methods on `TagHelperExecutionContext`.
#604
- Remove a lot of the ugly generic work done in `TagHelperAttributeList`/`ReadOnlyTagHelperAttributeList`.
- Removed error cases where we'd check on addition of `TagHelperAttribute`s that their `name` was not `null`. This was due to the pre-existing `string` indexer for `TagHelperAttributeList`. It no longer sets `TagHelperAttribute`s directly, instead it's `[key] = value` (instead of `[key] = new TagHelperAttribute(...))`.
- Updated tests to account for new immutability/string indexer format.
- Removed copy ctor from `TagHelperAttribute` since its immutability kills the value.
- Changed `ReadOnlyTagHelperAttributeList` to inherit from `ReadOnlyCollection`
#604
This change 'flattens' a TagHelperOutput when writing it out to an
HtmlTextWriter. This is a beneficial perf change because more often than
not the thing being written to is a ViewBuffer in Razor, which uses pooled
memory. This allows us to 'join' islands of pooled ViewBuffer memory back
into the main buffer instead of keeping them wrapped up in a
TagHelperOutput or TagHelperContent.
- #643 part 1
- change is viral and requires an update to `RazorPage.StartTagHelperWritingScope()`
- memoize `GetChildContentAsync()` per-encoder
- update generation tests to match and to test new behaviour
- note `HtmlEncoder`s used elsewhere e.g. in other `RazorPage` instances are unaffected
Add `NullHtmlEncoder`
Nits:
- generally clean up affected doc comments and make them more consistent
- remove unused `using`s in files I had open
Changing to IReadOnlyList since we always want to support indexing.
Replacing ToArray() with non-linq when needed, and with a static
EmptyArray when not needed.
Eliminates 50mb of list copies.
- Roslyn currently has an issue where too large of strings result in out of memory exceptions at compile time. To combat this I broke down literal strings into 1024 length pieces each resulting in their own `WriteLiteral`/`WriteLiteralTo` calls. The 1024 number corresponds directly with MVCs response string buffer.
- Added tests to validate large string rendering.
#614
- Prior to this change we'd hit the disk every time we'd create a `TagHelperDesignTimeDescriptor` to locate an assemblies XML files.
- Did not want to tie the XML cache to a static member in-case a user updates their XML information between parses. Therefore, changed `TagHelperDescriptorFactory` and `TagHelperDesignTimeDescriptorFactory` to no longer be static.
- Put the same `TagHeleprDescriptorFactory` extensibility point as we had for its counterpart `TagHelperTypeResolver` to stay consistent. This involved making `CreateDescriptors` virtual and allowing it to be provided in the `TagHelperDescriptorResolver` constructor.
#630
- Updated existing tests and added a new case to understand `@section {....` scenarios.
- Instead of trying to guess 1 character prior to EOF decided to log error on opening brace since we know its position. Updated error to account for change in location.
#625
- This allows users to write `TagHelperOutput` directly to an `IHtmlContent` accepting `TextWriter`.
- This also enables us to inspect backing fields for all of the various contents to lazily initialize them.
#358
This change significantly reduces the amount of string and List<ISymbol>
allocations that occur during compilation by changing the way
LiteralChunks are combined.
This is a low impact fix that addresses the performance issue, the design
issues that caused it still exist.
The problem here lies in what Razor fundamentally does - it parses HTML/C#
into tokens, and then combines them back into 'chunks' a representation
friendly to code generation. When presenting with a large block of static
HTML, Razor parses it into individual HTML tokens, and then tries to join
them in back into a single chunk for rendering. Due to details of Razor's
representation of chunks/tokens, the process of combining literals is too
expensive.
Mainly, what's done here is to not try to combine instances of
LiteralChunk. The process of merging them is too expensive and requires
lots of interm List<ISymbol> and string allocations.
Instead we produce a new 'chunk' ParentLiteralChunk, which doesn't do so
much up-front computing. Various pieces of the code that deal with
LiteralChunk need to be updated to deal with ParentLiteralChunk also,
which is the bulk of the changes here.
Note that we still have the potential for LOH allocations to occur during
codegen, but it's likely to occur O(1) for each large block of HTML
instead of O(N) as it did in the old code.
- Updated .cshtml files to not provide quotes for the various `TagHelper` directives.
- Updated `TagHelper` directive parsing tests. This also involved removing several tests that expected errors which no longer occur since we don't have to ensure quotes are balanced.
- Updated line mappings which significantly changed due to us no longer generating line pragmas at design time for `TagHelper` directives.
#561
- Template attributes should be of type `Func<TextWriter, Task>`. We weren't generating an `async` lambda for attributes prior to this change resulting in a compilation failure when used at runtime and the inability to `@await` code (unless a user returns some sort of `Task`).
- Updated code generation files to reflect the new code generation behavior.
#594
- The using statements had a chance to conflict with user code. Removed them and changed the default configured type names to be `global::` full name based.
- Updated test file `TagHelperDescriptor.TypeName`s to have namespaces to make them easier to read.
#580
- If a `TagHelper` attribute is an `enum` then you no longer need to provide the `enum` name. To override this functionality you can add the `@` symbol.
- Added code generation tests.
- Added `TagHelperDescriptorFactoryTest`s that double for Precompilation tests.
#196
- The init method allows multiple `TagHelper`s to inject data into the `context.Items` bag to properly function when running in unison with other `TagHelper`s that need to communicate with children.
- Transition `GetChildContentAsync` from `TagHelperContext` to `TagHelperOutput`.
- Move `TagHelperContext.GetChildContentAsync` tests to `TagHelperOutputTest`.
- Added `Init` test to ensure `TagHelperRunner` calls it in the correct order.
#571
- Changed non-user facing type names to `Microsoft.AspNet.Razor.TagHelpers`.
- Updated folder structure to reflect new namespaces.
- Updated generated code files to reflect new runtime type namespaces.
#578
- `TagHelper`s used to not flatten correctly resulting in inconsistent start locations for `SyntaxTreeNode`s following/within `TagHelper`s.
- This change indirectly corrected bad indentation that existed in generated C#.
- Added a test to validate `TreesAreDifferent` returns expected behavior when modifying content inside of `TagHelper`.
- Added `TagHelperBlock` `Flatten` test.
#553
- This enables debugging and proper error reporting for dynamic attributes. Without the pragmas errors would showcase generated Razor C# instead of their corresponding .cshtml files.
- Did not have to do any `TagHelper` specific changes since they utilize the same core attribute rendering logic.
- Updated generated C# files for tests.
#569
These changes make TagHelperContent with the IHtmlBuilder pattern, but
retain the signatures returning TagHelperContent.
Removed a bunch of tests that are no redundant with tests for the
extension methods in HttpAbstractions. Kept a few explemars in place to
ensure that the basic plumbing functions as desired.
- Updated the `TagHelperParseTreeRewriter` loosen child restrictions to non-`TagHelper` HTML elements.
- Updated tests to showcase that non-`TagHelper` elements are allowed to be restricted.
- Added an additional test case to showcase sub-sub nesting of non-`TagHelper` restricted children.
#543
- `ParentTag` allows `TagHelper`s to restrict where they apply based on their immediate parent tag.
- Changed the `TagHelperParseTreeRewriter` to understand non-`TagHelper` HTML elements to properly determine a parent tag when applying `TagHelperDescriptor.RequiredParent`. This change will also enable `[RestrictChildren]` to apply to more than just `TagHelper`s.
- Added tests to validate that partial and well formed tags properly discover `TagHelper`s. Also added tests that validate that descriptors are properly created based on `TagHelper` types.
#474
The code generator generates calls to ToString() on a TagHelperContent
when used with dynamic content inside an attribute that needs to be passed
to a TagHelper as a string.
This change updates the codegen to use GetContent(IHtmlEncoder)
- Took the HTML5 spec approach of disallowing specific characters and accepting all others.
- Added several parser and code generation tests to cover both `TagHelper` and non-`TagHelper` variations of symbol bound attribute names.
#137
- To limit the impact of the change ensured that we only do extra work in the case that we detect a script tag with a `type` attribute.
- The parsing changes include normal HTML parsing behaviors when we detect that a script tag has a `type` attribute with value `text/html`.
- Added unit and code generation tests to validate `text/html` script tag behavior.
#502
- Nearly every other `TagHelper` related element targeting attribute has `Html` a part of its name. With this rename, the attribute will be consistent.
#516
- Prior to this change adding a `.` after an implicit expression would result in compile errors due to Razor thinking the `.` was part of the C# (normally not the case).
- Added a code generation and unit tests to validate behavior.
#491
- Specifying the `RestrictChildrenAttribute` enables `TagHelper`s to only allow other `TagHelper`s targeting specified names to be in the children.
- Used the `null` value to indicate that `AllowedChildren` was not specified and therefore everything is allowed. This is the default.
- Added name verification to name values to ensure that no bad values pass through the system.
- Added parsing tests to validate a mixture of content generates errors when expected.
#255