Auto-Generated Documentation

[JeremyCaney]

Provide a Razor Class Library that generates documentation for the OnTopic Content Types and Attributes supported. This should display the content in a user friendly interface which includes basic explanations of what Content Types and Attributes are.

Features

• Provide a list of Content Type Descriptors in a hierarchy
• Provide a list of parent Content Type Descriptors in breadcrumbs
• Provide a list of Attribute Descriptors for each Content Type Descriptor
• Group Attribute Descriptors into tabs based on their DisplayGroup
• Identify Attribute Descriptors that are inherited from a parent Content Type
• Link to the Content Type Descriptor or Attribute Descriptor definition in the OnTopic Editor
• Allow the endpoint to require authentication, possibly by default

Nice to Have

• Allow Content Type Descriptors and Attribute Descriptors to be filtered by user role, once implemented
• Allow inherited Attribute Descriptors to be filtered out of the interface
• Persist preference for Attribute Descriptor inheritance and user role filtering to a cookie, so it is a default for each page
• Link to documentation for the Content Type Descriptor from topics in the OnTopic Editor
• Display the Content Type Descriptor that each Attribute Descriptor is inherited from, if practical
• Evaluate if an ASP.NET Core template is associated with the Content Type Descriptor—or any of its views—and, if so, provide a reference to them.

  Note: We can’t link to these without knowledge of where they are stored.

Open Issues

• Should this be shipped with the OnTopic Editor, or distributed as a separate project? Lean toward separate project.
• Should this permit being embedded in customer layouts of pages? This would be nice, but likely overly complicated.

[JeremyCaney]

A benefit to including this with the OnTopic Editor is the ability to use the same basic user interface and Stylesheet.

That said, this could alternatively be achieved by centralizing the Ignia admin navigation as it’s own separate NuGet package that both the OnTopic Editor and the proposed documentation rely on, as proposed in #21.

Another benefit would be to simplify linking to the documentation to the editor, since the presence of documentation would be implicitly present and at a known location.

Finally, if a customer is using the OnTopic Editor, they likely want the documentation, while it’s hard to imagine the inverse—i.e., these products complement one another.