You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Merge branch 'feature/ITypeLookupService.Lookup-fallbacks' into develop
Previously, the `ITypeLookupService` didn't directly handle fallbacks, and so implementations had instituted their own logic for handling alternatives and defaults. Namely, the `StaticTypeLookupService`—which most implementations use as a base class—accepted a `DefaultType` which would be returned if a match couldn't be found.
In addition, more recently, the `DynamicTopicViewModelLookupService` ((902b380) and `TopicViewModelLookupService` (68a8635) overrode `Lookup()` to fallback to an alternate convention of `ViewModel`; and both `DefaultTopicLookupService` (aac3e97) and `DynamicTopicLookupService` (cd9e540) overrode `Lookup()` to fallback to `AttributeDescriptor` if the `typeName` ended in the `AttributeDescriptor` convention, but a specific type could not be found.
While this fallback logic was valuable, it was also confusing. With the `DefaultType`, this meant that callers couldn't assume that a `null` result meant a miss, and needed to explicitly check the return type against the `typeName` to ensure it matched. With the `Lookup()` overrides, this meant repeating logic between implementations if they didn't share a type-specific base class. Further, all of these meant that callers had little control or transparency over the fallback process. This could result, for instance, in an alternate `ITypeLookupService` not providing the same fallbacks, which could be a confusing behavior.
To mitigate that, all of the above have been removed, and instead replaced with a new `ITypeLookupService.Lookup()` signature that accepts a `param string[] typeNames` instead of a `string typeName`, thus allowing the _callers_ to specify the alternatives or logical defaults that _they_ are aware of and can accept, instead of relying on the `ITypeLookupService`—which they have no insight into or control over—to provide one on their behalf. This makes a lot more sense in terms of dependency management.
So, for instance, the `TopicFactory.Create()` method now handles the fallback to `AttributeDescriptor` (if the `ContentType` ends in `AttributeDescriptor` but a specific type cannot be found) as well as `Topic`. And, similarly, the `TopicMappingService` now specifies a preference for `{ContentType}TopicViewModel`, but with alternative of `{ContentType}ViewModel`.
As this update not only changes the constructor of `StaticTypeLookupService`, but also changes the signature of the `ITypeLookupService.Lookup()` method, it is a breaking change. External libraries, such as OnTopic Editor, will need to be updated. Customer implementations will also need to be updated if they a) pass a `DefaultType` to `StaticTypeLookupService`, b) override the `Lookup()` method, or c) rely on the `DefaultType`. (No customer implementations rely on the new `ViewModel` or `AttributeDescriptor` alternatives names, so there's no worries there.)
0 commit comments