Closed NightJar closed 6 years ago
To clarify, the problem you're trying to fix with this is that different styling is required in different contexts, as well as certain things like React routing being tricky when the HistoryViewerField is added to a form in the CMS?
I'm pretty unclear about how your suggested solution would help with this. Perhaps you could do a lightweight RFC at some point to make it clearer?
Feel free to reopen if you'd like to revisit this =)
Related: https://github.com/silverstripe/silverstripe-admin/issues/590
The UI is react driven now (for elemental as a whole) so separate controllers aren't really a thing now anyway.
At current the history viewer is implemented in two ways:
FormField
-HistoryViewerField
HistoryViewerField
Form
that uses theHistoryViewerField
Problems with this second method is that it often does not make contextual/semantic sense to have a history field nestled in amongst other edit fields for Form Submission, leading to it usually being separated via a
Tab
, which then comes with it's own set of problems such as exemplified by #22 and to a lesser extent https://github.com/silverstripe/silverstripe-versioned-admin/issues/1#issuecomment-401658520Ideally there would be a new
RequestHandler
implementing theGridField_URLHandler
interface, allowing for a new endpoint specifically for dealing with history of versioned objects, in a similar manner to howGridFieldDetailForm
is for editing the latest version.As A developer I want an easy way to add historic views to
Versioned
DataObjects
in the CMS So that I can support Content Authors in auditing a change history from objects managed in aGridField
Instead of Adding aHistoryViewerField
to the current version of that object's editForm
So that The component is cleanly separated in concern, reusable, easily maintainable, and provides a consistent user experience throughout different areas of the CMS dealing with History.