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

[Jigal van Hemert]

Hi,

On 19-7-2012 12:32, Ernesto Baschny [cron IT] wrote:
> I agree that it fits in TsConfig, but I would be sad if we loose the
> Wizards to create them.

The wizard is the tool which makes them attractive for integrators to use.

> 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)?

If that is possible we could migrate from records to TSconfig. Good 
idea, but a bit more complex than this patch :-)

>>> 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).

I know that it can be used for this, but since only the data structure 
is in a file and not the template object it is only half useful for 
versioning. I tried to say that I personally have no knowledge of the 
exact reason for creating this option. It could be versioning, it could 
be something else. The option is there and you could use it for 
versioning, true.

> Deploying (and versioning) database records is a pain in
> the ass, and is discussed over and over how to do it "right".

This is a bit OT, but since most of the data of TYPO3 (pages, content, 
settings, records, etc.) is in a database it will always be hard to do 
versioning and deployment (not impossible, but hard). Moving everything 
to files is not the ultimate solution either. A CMS based on a large 
collection of human readable text files isn't something that will have a 
lot of performance.
The largest problem is incremental UIDs. This really prevents easy 
creation of DTAP streets.

But this is rather off topic here...

>> 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?

Incorrect. The argument was: TemplaVoila stores something in files 
instead of records and therefore BE layouts could also be stored in 
TSconfig. If the argument would have been something like "X uses 
something similar and the advantage is such and so" then it would be 
reasonable. But just because it is used elsewhere (and not even the same 
solution!) is not enough justification.
Templavoila uses it, so it must be correct? A friend of mine jumps in a 
river, so it must be right thing to do?

>> 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.

With this patch the records are looked up first, then the TSconfig is 
looked up because it can override the record. And this is supposed to be 
faster???

To summarize things, for me it's:
- either records or TSconfig, not both
- if it's TSconfig, the Wizard must be rewritten to us TSconfig
- it it's TSconfig, a migration wizard for the Install Tool must be made 
to convert existing records to TSconfig

-- 
Jigal van Hemert
TYPO3 Core Team member

TYPO3 .... inspiring people to share!
Get involved: typo3.org