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
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?
The text was updated successfully, but these errors were encountered:
ContentController
is currently hardcoded to work withSiteTree
. It's not uncommon to want to route to aDataObject
that isn't managed in the site tree, and therefore isn't aSiteTree
object - but for the frontend to treat it the same way it treatsSiteTree
objects.Making this class more generic removes some friction from that use case.
Acceptance Criteria
DataObject
subclassesChildrenOf()
which is probably barely ever used anyway)Page()
method, which is probably barely ever used and would be easy to either implement intoSiteTree
or for projects to implement if they need itURLSegment
somewhere more generic (maybe aPageDataObject
which has anything related toURLSegment
added to it and is either an extension or trait applied toSiteTree
, or a superclass forSiteTree
)Menu
methodSiteTree
from whatever module contains that classSiteConfig()
method - that's provided in a global template provider elsewheregetViewer()
to always (or conditionally based on config) use the basePage
template, falling back on appropriately namespaced templates even for non-SiteTree
Versioned
extension, or throw an exception if they don't.hasMethod()
/hasField()
checks, and throw exceptions if needed fields/methods aren't availableOldPageRedirector
generic, or else only use it whenSiteTree
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?
silverstripe/framework
?ModelAsController
andRootURLController
)?SiteTree
andCMSMain
to a newsilverstripe/pages
module?The text was updated successfully, but these errors were encountered: