[TYPO3-ect] The Big Plan

[Michael Scharkow]

Hi Elmar,

Elmar Hinz wrote:

> Well, palettes are specific for the BE. There will always be differents in
> the display for BE and FE or more general between different groups of
> users. I am very open for proposals how this can be done.

Palettes are specific for the BE only because TCEforms et. al. is BE 
specific, that's just a legacy issue, not a conceptual constraint.

> Yes, I also see an advantage of an additional validation on the model
> level. Especially if the data comes from other sources then forms. However
> model level and view level can make use of the same validation library.

Right, they *have* to use the same validation methods.

>> 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
> 
> I wrote the long intro to point out the disadvantages of this monolithic
> concept. Obviously I didn't convince you. I don't will repeat my arguments
> and negative experiences with this.

Right, please consider only the latter proposal: A generic view class 
(or some of them) that accepts any model and displays some CRUD forms 
and a record browser, basically Rails's scaffolding. Everybody hates it, 
but it does work as a default/fallback mechanism.

> If functionally can be separated one should separate it. Kaspers code
> suffers mostly from overloading classes with to much functionality.
> Combining of separated function when it is needed is much easier than to
> separate functionality from oversized classes.

Right, so the question is whether to completely move all display-related 
configuration away from TCA, or just use a kitchensink TCA as a 
multi-purpose definition used by the model *and* the view classes.

>> 3. The Client-Side-Validation belongs to the view part, although the
>> requirements are derived from TCA
> 
> * Yes. Requirements of validation are derived from TCA in all cases.
> * Validation is done with a separte validation library.
> * Client side validation is JavaScript based. If we use JavaScript, we
> directly can use AJAX. If we use AJAX, we directly use the server side
> validation.
> 
> That makes it very simple for us. AJAX clientside, serverside view and
> serverside model validation can all be done with the same library.

Yes, see 
http://tetlaw.id.au/view/blog/really-easy-field-validation-with-prototype/ 
which seems very suited for us as prototype will hopefully be the TYPO3 
standard JS library.

>> 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.
>>
> 
> The advantages, the magic, you see in the monolithic concept can also be
> gained at a very cheap price with separated funcitonality by combination.
> 
> With separation of functionality you don't loose any functionality. You
> simply structure it more fine grained.

I never doubted that, and I'm all for more separation of *classes*, but 
I'm at least uncertain about splitting up TCA.

GReetings,
Michael