I’ve recently been made aware of how type-centric Sitecore is in its architecture and best practices.
Consider the main sections in Sitecore: Content, Templates, Layouts, and even the folder structure /xsl, /layouts. Sitecore seems inherently to point the architect towards categorizing his solution after which types of elements it consists of, i.e. which templates do my website consist of, how many layouts do I have, which XSL’s do I have to write etc. instead of looking at the conceptual structure of the website, i.e. which functionality do I have, e.g. newsletter, document, navigation etc. Trying to piece together all the parts which make one function on the website involves browsing through a lot of folders in Sitecore and looking into a lot of code, whereof many of the references are very loose e.g. template names in XSLT files, or assembly references in the web.config (or even worse: assembly references in Sitecore). All in all it is not an architecture which is very helpful for reuse and overview.
I vision Sitecore in a future version working in a more functionality-centric way, for example imagine the Sitecore content tree:
- Content (This is where the editors edit the site – not much different here)
Components (This is where we – the developers – roam)
Component (each functionality has its own section)
- Templates (this defines the templates for this component)
- Presentation (This defines all the presentation elements for this component, layouts, renderings etc.)
- Settings (General settings, dictionary texts etc. needed by the component)
…and that’s it. No more browsing the entire tree looking for the settings for the Mailing list module. No more: “I wonder if this layout is used by any of my 367 templates”. No more: “Was that document.xsl or document.ascx”. Just imagine the ease in making of package for porting functionality to a new website.
Just my two cents…