Epic #84101
Updated by Lidia Demin almost 5 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 be able to define the stories and make their goals understandable for everybody, we need to define some basic terms.
h2. Page
The outermost structure with the current versions of TYPO3 of course is a *page*.
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 needed 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.
Regions will get real names instead of having just numbers, so you will be able to fetch the content from "footer" instead of "colPos 0".
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*.
So sections are the actual "structured content" we are aiming for.
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 Element
This is the term for any other of the usual content elements besides the structured content elements we are going to provide as *sections*.
h2. Protocolls
# February 13th, 2019 - 20:00 - 22:45 CET: https://docs.google.com/document/d/1CDUhpemaTJ-P5oqjV8tzNQ0RBoAzKme70qBiFUF9Ktk/
# March 13th, 2019 - 18:00 - 22:09 CET: https://docs.google.com/document/d/1KR1DCxSmPWKKcCkbrytHtGFf8HajgX2ao6sJ4uK-iw4/
# April 17th, 2019 - 18:00 - 22:00 CET: https://docs.google.com/document/d/1p1nUT2g7vO1DrVkpGZ_uG0E6-IyDtT6_tgm_WIPM-Eo/
# May 8th, 2019 - 18:00 - 20:00 CET: https://docs.google.com/document/d/1cmCW2TAGBkH85uywGlTMZ524jm1ykBnRI9s197hp05c/