Tag Helpers: Create string => Type[] resolver to indicate what Types are TagHelpers based on a lookup string.. #158

NTaylorMullen · 2014-09-25T17:31:19Z

This item goes along side #99 and is used to translate from string => Type[] where Type[]s are valid types that should have TagHelperDescriptors built for them.

If we wanted to we could change the contract to be from Type[] => Type[] where the ending Type[] is the valid list of tag helper types. I feel that putting the initial string => all Type[]s logic in one object makes sense since it's part of the type resolving process.

The text was updated successfully, but these errors were encountered:

- The TagHelperTypeResolver is responsible for determining the format of lookup text's used throughout the tag helper system. By default it handles the following formats: "assemblyName" "assemblyName, #.#.#.#" "assemblyName, #.#.#.#, specificType" - It also restricts what types are considered TagHelpers. In this implementation we only accept public, non-nested, non-abstract, non-generic TagHelpers. - Added tests to validate the expected functionality. #158

dougbu · 2014-09-26T05:05:27Z

@NTaylorMullen please clarify how this issue differs from #99

NTaylorMullen · 2014-09-26T05:23:25Z

@dougbu #99 passes the lookup text, aka the string in @addtaghelper "MyAssembly" to a this issues TagHelperTypeResolver which is responsible for what that lookup text means. The default meaning behind the lookup text is:

"assemblyName"
"assemblyName, #.#.#.#"
"assemblyName, #.#.#.#, specificType"

Then based on the lookup text it queries the requested assemblyName and returns a Type[] which contains all of the TagHelper types that abides by the lookup text and are valid TagHelpers. Valid tag helpers are defined as follows:

!typeInfo.IsAbstract &&
!typeInfo.IsGenericType &&
typeInfo.IsPublic &&
!typeInfo.IsNested &&
typeof(TagHelper).GetTypeInfo().IsAssignableFrom(tagHelperTypeInfo);

dougbu · 2014-09-26T05:35:25Z

I'm not getting it. why track issues at the per-class or even per-method level? this still sounds like a small part of the resolution scenario, which replaces the "manually-inserted TagHelperDescriptor" stopgap.

NTaylorMullen · 2014-09-26T05:45:26Z

It's slightly different than the TagHelperDescriptorResolver because replacing it can completely change what defines where the tag helper types come from. So this also involves exposing this via an interface so it can eventually be DI'd. It turn out to be decently large: #159

- The TagHelperTypeResolver is responsible for determining the format of lookup text's used throughout the tag helper system. By default it handles the following formats: "assemblyName" "assemblyName, #.#.#.#" "assemblyName, #.#.#.#, specificType" - It also restricts what types are considered TagHelpers. In this implementation we only accept public, non-nested, non-abstract, non-generic TagHelpers. - Added tests to validate the expected functionality. #158

- This involved also adding a TagHelperTypeResolver and TagHelperDescriptorFactory. - The TagHelperTypeResolver is responsible for determining the format of lookup text's used throughout the tag helper system. By default it handles the following formats: "assemblyName" "specificType, assemblyName" - It also restricts what types are considered TagHelpers. In this implementation we only accept public, non-nested, non-abstract, non-generic TagHelpers. - The TagHelperDescriptorFactory is responsible for converting a Type to a TagHelperDescriptor. - Added tests to validate TagHelperDescriptorResolver, TagHelperTypeResolver and TagHelperDescriptorFactory. #99 #158