Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor ContentController to be generic #2953

Open
GuySartorelli opened this issue May 30, 2024 · 0 comments
Open

Refactor ContentController to be generic #2953

GuySartorelli opened this issue May 30, 2024 · 0 comments

Comments

@GuySartorelli
Copy link
Member

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?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants