ContentController is currently hardcoded to work with SiteTree. It's not uncommon to want to route to a DataObject that isn't managed in the site tree, and therefore isn't a SiteTree object - but for the frontend to treat it the same way it treats SiteTree objects.
Making this class more generic removes some friction from that use case.
Acceptance Criteria
- Make this controller work with other
DataObject subclasses
- Remove methods that assume a hierarchy (e.g.
ChildrenOf() which is probably barely ever used anyway)
- Remove
Page() method, which is probably barely ever used and would be easy to either implement into SiteTree or for projects to implement if they need it
- Add a new config property or method to tell it what class it's supposed to handle
- Move
URLSegment somewhere more generic (maybe a PageDataObject which has anything related to URLSegment added to it and is either an extension or trait applied to SiteTree, or a superclass for SiteTree)
- Add a separate config property for the class that should be used for the
Menu method
- Set this to
SiteTree from whatever module contains that class
- Remove
SiteConfig() method - that's provided in a global template provider elsewhere
- Change
getViewer() to always (or conditionally based on config) use the base Page template, falling back on appropriately namespaced templates even for non-SiteTree
- If needed, remove assumptions that records will have the
Versioned extension, or throw an exception if they don't.
- If necessary, define an interface or add explicitly
hasMethod()/hasField() checks, and throw exceptions if needed fields/methods aren't available
- Either also make
OldPageRedirector generic, or else only use it when SiteTree is the model being used.
TO DECIDE
Arguably this doesn't open much opportunity if we don't move some stuff around as well - but what should we move, and to where?
- Do we want to move this to
silverstripe/framework?
- Do we want to move this to a new module (along with
ModelAsController and RootURLController)?
- Do we want to keep these here, and move
SiteTree and CMSMain to a new silverstripe/pages module?
ContentControlleris currently hardcoded to work withSiteTree. It's not uncommon to want to route to aDataObjectthat isn't managed in the site tree, and therefore isn't aSiteTreeobject - but for the frontend to treat it the same way it treatsSiteTreeobjects.Making this class more generic removes some friction from that use case.
Acceptance Criteria
DataObjectsubclassesChildrenOf()which is probably barely ever used anyway)Page()method, which is probably barely ever used and would be easy to either implement intoSiteTreeor for projects to implement if they need itURLSegmentsomewhere more generic (maybe aPageDataObjectwhich has anything related toURLSegmentadded to it and is either an extension or trait applied toSiteTree, or a superclass forSiteTree)MenumethodSiteTreefrom whatever module contains that classSiteConfig()method - that's provided in a global template provider elsewheregetViewer()to always (or conditionally based on config) use the basePagetemplate, falling back on appropriately namespaced templates even for non-SiteTreeVersionedextension, or throw an exception if they don't.hasMethod()/hasField()checks, and throw exceptions if needed fields/methods aren't availableOldPageRedirectorgeneric, or else only use it whenSiteTreeis the model being used.TO DECIDE
Arguably this doesn't open much opportunity if we don't move some stuff around as well - but what should we move, and to where?
silverstripe/framework?ModelAsControllerandRootURLController)?SiteTreeandCMSMainto a newsilverstripe/pagesmodule?