- Updated all of the tests to use the new ITagHelperDescriptorResolver signature so instead of passing strings they now construct TagHelperDescriptorResolutionContexts.
- Removed several tests from the AddOrRemoveTagHelperSpanVisitorTests. This was due to the change in responsibility of managing the found TagHelperDescriptors; the TagHelperDescriptorResolver now does this.
- Added several new tests to verify the TagHelperDescriptorResolver manages resolved TagHelperDescriptors based on the given TagHelperDirectiveDescriptors.
#214
- Modified the AddOrRemoveTagHelperSpanVisitor to no longer manage TagHelperDescriptors found in the system. Instead it now manages TagHelperDirectiveDescriptors which are then used to resolve TagHelperDescriptors.
- Changed the signature of ITagHelperDescriptorResolver to take in a TagHelperResolutionContext which will allow us to pass more information without breaking tooling.
- TagHelperDescriptorResolver now resolves all TagHelperDescriptors at once and manages descriptors found in the system based on values on the provided TagHelperDirectiveDescriptors.
#214
- TagHelperAttributeDescriptors changed to be lighterweight and not depend on PropertyInfo, had to modify our use of them to work with the new contract.
- scenarios where helper takes different code paths were not well-explored
nits:
- improve a few comments and names
- refactor some setup code into helper methods
- use `EmptyModelMetadataProvider`, not `DataAnnotationsModelMetadataProvider`
Test gap around `GenerateTextBox()`'s `format` argument is temporary.
- #1523
- remove `TagHelperOutput.Merge()` extension method entirely
- test tag name preservation with all MVC tag helpers
- `<input/>` tag helper generation of a checkbox wasn't previously tested
nits:
- fix argument order in a couple of `Assert.Equal()` calls
- remove use of "original tag name"
This change enables some compatibility scenarios with MVC 5 by expanding
the set of legal ways to configure attribute routing. Most promiently, the
following example is now legal:
[HttpPost]
[Route("Products")]
public void MyAction() { }
This will define a single action that accepts POST on route "Products".
See the comments in #1194 for a more detailed description of what changed
with more examples.
Sometimes the first request to the application results in exceptions like 'No connection could be made because the target machine actively refused it'. Adding a retry to mitigate that.
- Upgraded to Angular 1.3 (Fixes#267)
- Fix XHR GET caching issue in IE with new NoCacheAttribute
- Slight fix in admin home page (album list) to ensure initial data fetch has the sort expression in the query
When file names are missing from exception stack trace the above line of code does not pass the detected function name. As a result issue described in bug : https://github.com/aspnet/Diagnostics/issues/49 happens.
This issue happens on mono. With this fix method names show up in the error page middleware output on mono.
This is a sample of the pattern for building a MapRoute method that
customizes routing by adding constraints, datatokens, or defaults. This is
the replacement for adding data to the route directly.
Also fixed up the sample to work. It was massively out of date.
The properties on TemplateRoute for DataTokens and Defaults are now
readonly. This prevents modifying these collections in a way that
invalidates cached data, or violates thread-safety.
To do the same for constraints, this change includes a substantial refactor
of how we realize inline constraints, and moves the constraint resolver
out of the parsing phase.
This allow creates a builder for the constraint map, that will make it
easier to implement features like optional constraints, and is reusable
for anyone building their own type of routing system.
These tests verify that per-request services can be injected into assets
that users provide/implements (filters, constraints, controllers, views,
etc).
The purpose is to verify that the services are correctly resolved from the
per-request service container, and don't have state that lingers and
influences the next request. This is important because changing the
lifetime of a framework services could easily impact the lifetimes of
others, and ultimately of something the user created.
Rather than throwing here, this does what routing does. If request
services aren't set, we just create our own scope.
This will NOT create an extra scope if request services are already set.
Pranav K
N. Taylor Mullen
Ryan Nowak
Doug Bunting
Praburaj
Ajay Bhargav Baaskaran
DamianEdwards
ianhong
Suhas Joshi
rowanmiller
Chris Ross