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

[Ernesto Baschny [cron IT]]

Jigal van Hemert schrieb am 19.07.2012 11:39:

> On 19-7-2012 10:34, Helmut Hummel wrote:
>> I also agree. Backend Layouts are configuration, thus perfectly fit into
>> Ts*Config*
> 
> But what is the point of having them both in records and in TSconfig?
> Having them in two places will add confusion. Some BE layouts can be
> edited with the wizard, some must be edited in TSconfig.

I agree that it fits in TsConfig, but I would be sad if we loose the
Wizards to create them.

So how could the Wizard fit in the TsConfig setting world? Maybe finding
a way of adding the Grid-Wizard into the already existing TsConfig
wizard (typo3/wizard_tsconfig.php)?

>> Besides that, TemplaVoila introduced the possibility to have the data
>> structure in files. That was introduced because the need was there.
> 
> That last conclusion is dangerous. This was an "experimental" feature.
> No idea why it was introduced.

Maybe you don't use it, but most site implementator which work with
versioning systems to deploy their sites are happy to be able to move
away from database based storage of configuration to file based (because
of git / svn). Deploying (and versioning) database records is a pain in
the ass, and is discussed over and over how to do it "right".

> The rest of this argument is like "I jumped in the river too because I
> saw a friend of mine jump in".

Your argument is like "I won't use it (versioning of configuration), so
I don't see the need to change it". :) So now the question might be
which argument is more short sightet?

> It will introduce extra parsing of TSconfig and looking up extra data
> when handling the BE layouts. This will certainly not speed up the BE.

I expect that it gets faster, because TSconfig is being parsed *anyway*
in the backend. In the current backend layouts solution it needs to look
up the records (more DB queries) and *then* parse the backend layouts:
That costs even more performance.

>> Denying such a change for the core would not make sense.
> 
> Slowing down the BE and introducing more confusion for integrators
> doesn't make sense to me.


Cheers,
Ernesto