Epic #84101
Updated by Jo Hasenau about 6 years ago
Based on this Blueprint To be rephrased: "See 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 final goal should be to provide at least the TYPO3 core for more than a decade now. Sometimes a flexible use must haves and ideally some 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 should haves within the following motivations for three different groups next two versions of users in the TYPO3 universe - editors, integrators and developers. CMS. h2. Editors * I want to speed up daily work so I want to apply certain actions to multiple elements at once * I need We started with a visual structure of a flexible amount of multiple columns both first try in frontend and in backend that can easily be rearranged and nested 2015 already, but this has been postponed on request by several members of the fly * I want an interface core team due to be as simple and intuitive as possible different reasons. * I need The first reasons was, that we should avoid to be able to make use of structures and containers in multilingual environments and workspaces or combinations of both * I rush things in, just because we want to be able have them, since this has lead to edit content on mobile devices h2. Integrators * I want future proof concepts for upcoming and existing CSS some pitfalls with other features and HTML structures so I in the past. The second reason is, that we need a well implemented technology to wrap deal with tree structures, since nested content elements with certain markup in is basically nothing else but a tree Last but not least to make sure that the frontend output. concept we are going to implement fits the needs of our userbase, we need properly written stories first * I want to be So before we get lost in full control discussions about details of the output still I would want implemetation like configuration syntax or data management, we need to be able make sure we all know WHY we are going to create structures without having do it and WHAT we actually want to nest containers * I want get. The blue print was a solution first step into that works independently from a certain frontend framework but still would be able direction. Now everbody is invited to represent join the structures of interest group on slack https://typo3.slack.com/messages/C8Z2UM50Q/ so we can build a given frontend framework as far as possible * I want team there to have an option to add specific custom configurations to different parts of come up with the structure regarding frontend and/or backend behaviour and rights management * I want to enable people to edit content user stories, which we will then put up for discussion on mobile devices https://decisions.typo3.org/ 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 Keep in my own sitepackage or other TYPO3 extensions * I want a smooth migration path and a sustainable solution mind, that can easily be maintained in the future first place this is about WHY, then about WHAT and reuse content provided by existing extensions as far as possible The final goal should be after the decisions have been made, we will start to provide at least think about the must haves and ideally some of the should haves within the next two versions of TYPO3 CMS. HOW."