Epic #84101
Updated by Jo Hasenau about 6 years ago
Based on this Blueprint http://wiki.typo3.org/Blueprints/StructuredContentContainers we created https://docs.google.com/document/d/1Wui-vM1K9fOoSYgi5n_vZMFe59v5o2Qg0-HE4fy3e7c/edit#heading=h.kcy7kg7ngpnn as a common base for Epic, Stories and Tasks. h1. WHY - REASONS AND MOTIVATIONS There are several reasons, why people are constantly asking for structured content or content structures in the TYPO3 core for more than a decade now. Sometimes a flexible use of multiple columns or maybe even more complex layouts to structure content is required. Depending on the role these people got in their daily business we identified the following motivations for three different groups of users in the TYPO3 universe - editors, integrators and developers. h2. Editors * I want to speed up daily work so I want to apply certain actions to multiple elements at once * I need a visual structure of a flexible amount of multiple columns both in frontend and in backend that can easily be rearranged and nested on the fly * I want an interface to be as simple and intuitive as possible * I need to be able to make use of structures and containers in multilingual environments and workspaces or combinations of both * I want to be able to edit content within structures on mobile devices h2. Integrators * I want future proof concepts for upcoming and existing CSS features and HTML structures so I need to wrap content elements with certain markup in the frontend output. * I want to be in full control of the output still I would want to be able to create structures without having to nest containers * I want a solution that works independently from a certain frontend framework but still would be able to represent the structures of a given frontend framework as far as possible * I want to have an option to add specific custom configurations to different parts of the structure regarding frontend and/or backend behaviour and rights management * I want to enable people to edit content on mobile devices h2. Developers * I want to separate concerns of structures and containers from the creation of functional containers and custom content elements * I want an API that enables me to use structures and/or containers for my custom solutions in my own sitepackage or other TYPO3 extensions * I want a smooth migration path and a sustainable solution that can easily be maintained in the future and reuse content provided by existing extensions as far as possible h1. TERMS To The final goal should be able to define provide at least the stories must haves and make their goals understandable for everybody, we need to define ideally some basic terms. h2. Page The outermost structure with of the current should haves within the next two versions of TYPO3 of course is a *page*. CMS. Each page can have a certain *backend layout* to seperate that *page* into several *regions*. h2. Backend layout Each *page* can have a certain layout attached to it, that seperates the page into *regions*. These *backend layouts* are used to create a basic structure for editors in the backend view. They can be directly attached to a certain frontend output, but they don't necessarily have to represent a frontend layout at all. h2. Region Regions have been known as _columns_ before, but we need to find another term here. Since the frontend output might not always be based on rows and columns but on CSS grids or other solutions, *region* is the new term. h2. Section Just like a *page* each *region* of a page can be split into several parts again, which are called *sections*. Basically the same functionality we already know from pages applies to these sections too. They can have *backend layouts*, called *section layouts* for better determination, and they can hold one or more *content elements*. h2. Section layout Each *section* can have a certain layout attached to it, that seperates the page into even smaller regions. These *section layouts* are used to create a basic structure for editors in the backend view. They can be directly attached to a certain frontend output, but they don't necessarily have to represent a frontend layout at all. h2. Content Elements This is the term for any other of the usual content element besides the sections we are going to provide as structured content elements.