[TYPO3-core] Discussion: Remove default columns in favour for backend_layout

Philipp Gampe philipp.gampe at typo3.org
Wed Jul 18 11:14:53 CEST 2012


Hi Jigal,

Jigal van Hemert wrote:

>> Plus it uses numeric key, so if you assign a different uid to a record,
>> frontend rendering breaks.
>> This can all be avoided by adding the definition to the pageTS.
> 
> Versioning: this is true for each table without versioning support.
> Numeric keys: this is true for each table.

I did not meant versionning it the backend, but for deployment and to keep 
track of the changes in a project.

> What do you propose? Pages, tt_content, be_users, etc. should all go to
> pageTS?

The definition for columns always was inside the pageTS. As we want to drop 
the old column way, we should be able to set the layout with pageTS again.

pages, content, be-users are real records which can not and most likely are 
not shared across installations.
On the other hand, things like typoscript, pageTS and sometimes even userTS 
are configuration which is often shared across projects.

The nature of records and configuration is quite different and putting 
configuration into records has a lot of drawbacks. One of them is that 
(without text keys) you need to change the configuration at another place if 
you import configuration records, because the numbers inside the 
configuration do not much any more.

That is really bad.

The suggested approach is to reuse the exiting tools to store and edit 
configuration for the backend by using pageTS for storing the configuration 
for backend layouts.
That does not mean that the records will disappear, but you can use pageTS 
on top (or below) the records based configuration.
All what is needed to be changed are the columns at reference at the 
records, because they need to store text keys then.

Storing configuration in text files lets you version them together with the 
rest of the project, independent of the actual data (the real records).

> Then those BE layout examples should go to an introduction package.

We should definitely do this. I add this to my (mental) todo list.

> It would be nice to have more different packages with examples as a
> starting point for various targeted audiences. But you would also need
> people who maintain those...

If we can automate the deployment, then we can just create a few variants by 
altering the configuration a bit.
But that would mean we need to be able to change the configuration 
automatically during deployment, independent of the data.
Do you see the need for the above?

We should try to move TYPO3 into the possibility to alter the complete 
layout without doing anything but changing a few (configuration) files and 
clearing cache.
So just one TS record that import the constants and the config from a file 
which in turn may import further files.

I will be at the distributions sprint and I guess we will also discuss this 
there.

Cheers
-- 
Philipp Gampe – PGP-Key 0AD96065 – TYPO3 UG Bonn/Köln
Documentation – linkvalidator
TYPO3 .... inspiring people to share!



More information about the TYPO3-team-core mailing list