`ReflexiveAttribute`?

[JeremyCaney]

Create an attribute type which invokes an instance of the attribute it is placed on, along with its attributes, in order to allow e.g., a DefaultValue, ImplicitValue, or other value attributes to be defined using the same type and settings as the attribute. This would be an improvement over the current approach, which effectively only supports scalar values, and requires knowledge of how those types will be serialized.

That said, this introduces some challenges—and notably, how to dynamically set the EditorType in order to load the value from the correct source—which may not be practical, and will require additional thought.

[JeremyCaney]

Establishing the ModelType shouldn’t be too difficult. We know it’s grandparent should be a ContentTypeDescriptor describing the type it’s intended to map. It can use that information to construct a new AttributeDescriptor derivative using TopicFactory.Create(), and then relay that ModelType.

The only caveat is it won’t be able to do this if the grandparent is the ReflexiveAttributeDescriptor as that would cause an infinite loop. In that case, we can hard code ModelType.ScalarValue.

Update: The above information is incorrect. The grandparent will always return the ContentTypeDescriptor the ReflexiveAttribute was added to, but this may not be the type of the EditingTopicViewModel since AttributeDescriptors can be inherited from parent content types.

We’ll also need to handle this type of scenario in the view, so it doesn’t attempt to invoke a ReflexiveAttributeViewModel, which would likewise result in an infinite loop. In that case, we can just return a message explaining the situation. It doesn’t make sense in our case to have e.g., a DefaultValue on a DefaultValue regardless, as that’s highly specific to the individual AttributeDescriptor, so this shouldn’t be a major limitation.

[JeremyCaney]

The second challenge is how to get access to the appropriate view model for invoking the target view component. This seems easy in that he AttributeDescriptorViewModel will also be the EditingTopicViewModel.

Unfortunately, though, the type of object will be incorrect, as we need a derivative of AttributeDescriptorViewModel, not EditingTopicViewModel, which the EditorController explicitly maps the currentTopic to.

Options

EditorController

Explicitly handle this scenario in the EditorController by mapping to an AttributeDescriptorViewModel if the CurrentTopic is an AttributeDescriptor. This would require that AttributeDescriptorViewModel derive from EditingTopicViewModel. This is less than ideal, as the editor shouldn’t be aware of the needs of any one attribute type.

ITopicMappingService

Inject an ITopicMappingService into the ReflexiveViewComponent so that’s the currentTopic can be remapped as the specific AttributeDescriptorViewModel derivative identified in the ITypeLookupService. This introduces a dependency on ITopicMappingService and ITypeLookupService, which the StandardEditorComposer doesn’t currently have. This would either need to break backward compatibility by exposing those dependencies to the constructor, or be hardcoded, which isn’t ideal in terms of dependency injection.

Note: Since the OnTopic Editor is an application, it might seem to make sense for it to define its own dependency graph. But as it is embedded in other applications, we’d expect it to take dependencies supplied to the StandardEditorComposer, as it does today. Ultimately, as well-known dependencies that can optionally be constructed independently of the StandardEditorComposer, this might be tolerable. But it’s less-than-ideal, and should be resolved in OnTopic 6.0.0 (since we don’t want to make a breaking change to a minor release).

[JeremyCaney]

The above proposal regarding the ModelType is incorrect. Unfortunately, there isn’t an easy way around this without making the EditorController aware of the ReflexiveAttribute (e.g., to get the ModelType off of the CurrentTopic if the attribute is a ReflexiveAttributeDescriptor). I’d really like to avoid making the editor aware of any one attribute type—which is why we currently store them as plugins in a separate library.

Without this, the value will always be stored as in Topic.Attributes instead of e.g., Topic.Relationships or Topic.References.