[TYPO3-ect] The Big Plan

[Michael Scharkow]

Hi Elmar,

I just comment on the last part because that's what bugs me most atm.

Elmar Hinz wrote:

>  3.) How to use the ideas of rapid prototyping for building forms?
>      -------------------------------------------------------------
> 
>   In rails the configuration of rapid protoping is retrieved from the DB
> fields. In TYPO3 we invert this procedure. We build the configuration (TCA)
> before the DB tables are generated. We usually do this with the
> kickstarter. We can understand the kickstarter as an rapid prototyping wizard.

Note that in Rails 1.1 and later, the pure use of DB schemas is 
discouraged in favour of migrations which are defined in fake-SQL-Ruby, 
just like the adodb dictionaries work. Furthermore, even in Rails the 
model is defined in two places: the db schema *and* the model object 
where validations and constraits are added as well as custom methods.

In TYPO3, we define the models, including validations and constraints, 
in TCA and additionally in ext_tables.sql. The later must absolutely 
positively die because we need database abstraction anyway, and the 
schema is redundant.

>   However the TCA does not contain all configuration we need to generate
> the forms. We need to discuss the best solutions to fill this gap.

I disagree: Not only does TCA contain enough configuration for both ORM 
and form building, but it does even contain too many form-building 
related (=view related) options, i.e. palettes.

Concerning form building for TCA objects, I have the following demands:

1. TCAObjects must be able to validate themselves, independent of forms.
2. TCAObjects must render themselves both input (=form) and output 
(list, detail view), or the other way round: view classes should accept 
any TCAObject as input and render forms, single view accordingly
3. The Client-Side-Validation belongs to the view part, although the 
requirements are derived from TCA

By mixing both model and view aspects in TCA we gain a lot of 
configurable "magic" views which IMHO far outweighs the advantages of 
strict M-V separation.

Greetings,
Michael

PS: I still don't understand why this core issue is part of ECT (except 
extensions may use the API) but as long as you manage the discussion I 
don't care about names ;)