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
CMSMain has a tree_class configuration property which is sometimes referenced - but sometimes SiteTree is explicitly hardcoded.
The hardcoded references and the assumptions about using SiteTree should be removed.
Benefits
opens a path for further refactoring to allow other hierarchical data to be displayed in a hierarchical way
opens a path to 'demistify' SiteTree so it becomes just another subclass of DataObject rather than having its own code paths in admin
opens a path to reduce code/feature duplication across admin and cms modules (e.g. the search UI, sending toasts, handling tabs/breadcurmbs and more)
original POC PR - this PR includes many additional notes and implementation details
Notes
There are many ways to make calls to SiteTree methods/properties more generic, such as:
Implementing a method on CMSMain that calls that method if it exists, but falls back on other things - e.g. get MenuTitle if there is one, but fall back on Title
Moving the main implementation of the method from SiteTree into CMSMain, and invoking an extension hook on the record (probably with invokeWithExtensions()) to allow updating the value
Don't forget there's both a tree view and a list view! Both of these need to work and have their strings updated.
Acceptance criteria
A getModelClass() method is implemented, which returns the value stored in the tree_class configuration property
All hardcoded references to SiteTree or Page use the getModelClass() method instead (including subclasses of CMSMain)
Nothing assumes the model has the Versioned extension
Whenever CMSMain, one of its subclasses, or a template tries to call a method or fetch a property that is explicitly implemented on SiteTree, this is handled in a generic way
If any method/property is explicitly required which isn't provided by the DataObject class or the Hierarchy extension, throw clear exceptions if they're missing. One example (and probably the only case) is CMSEditLink.
In an appropriate place (maybe init()), a clear exception is thrown if the model class doesn't meet requirements to be used in CMSMain (i.e. doesn't have the Hierarchy extension applied, or is missing a method/property that is explicitly required for CMSMain to work)
Strings which assume SiteTree is being used are updated to pull from whatever model is used.
e.g. "Page type", "Add page", "Choose where to create this page", "Pages", etc.
With exception of the history tab, filtering the tree list, and batch actions (which will each be handled separately), all functionality in CMSMain works with TaxonomyTerm (when that class has the CMSEditLinkExtension extension applied - see config in the description of the POC PR)
TO DECIDE
Currently the site name (defined in siteconfig) is displayed as the root of the tree. This makes sense for pages but probably not for other models. What should be the root of the tree for non-page models?
Should it be configurable?
Should there be no root?
Should we just leave it as the site name for now and change it later if we feel like it?
CMSMain
has atree_class
configuration property which is sometimes referenced - but sometimesSiteTree
is explicitly hardcoded.The hardcoded references and the assumptions about using
SiteTree
should be removed.Benefits
SiteTree
so it becomes just another subclass ofDataObject
rather than having its own code paths in adminRelated
Notes
SiteTree
methods/properties more generic, such as:CMSMain
that calls that method if it exists, but falls back on other things - e.g. getMenuTitle
if there is one, but fall back onTitle
SiteTree
intoCMSMain
, and invoking an extension hook on the record (probably withinvokeWithExtensions()
) to allow updating the valueAcceptance criteria
getModelClass()
method is implemented, which returns the value stored in thetree_class
configuration propertySiteTree
orPage
use thegetModelClass()
method instead (including subclasses ofCMSMain
)Versioned
extensionCMSMain
, one of its subclasses, or a template tries to call a method or fetch a property that is explicitly implemented onSiteTree
, this is handled in a generic wayDataObject
class or theHierarchy
extension, throw clear exceptions if they're missing. One example (and probably the only case) isCMSEditLink
.init()
), a clear exception is thrown if the model class doesn't meet requirements to be used inCMSMain
(i.e. doesn't have theHierarchy
extension applied, or is missing a method/property that is explicitly required forCMSMain
to work)SiteTree
is being used are updated to pull from whatever model is used.CMSMain
works withTaxonomyTerm
(when that class has theCMSEditLinkExtension
extension applied - see config in the description of the POC PR)TO DECIDE
PRs
CMS 5 PRs
TBD
CMS 6 PRs
The text was updated successfully, but these errors were encountered: