[TYPO3-ect] The Big Plan

Elmar Hinz elmar.DOT.hinz at team.MINUS.red.DOT.net
Wed Jul 5 23:11:59 CEST 2006


Michael Scharkow wrote:
> 
> Right, they *have* to use the same validation methods.
> 

Hypothetic example of different validation methods for view and model:

If the form input is "28.14.2006", it makes sense to inform the user that
there is no month bigger than 12. After validation the form converts to a
unix timestamp. The model accepts unix timestamp only. It checks it for a
valid range to be within.

Both *may* use the "timestamp range check". Only the view will use the
"month check".

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

I don't understand. What do you want to say with this?

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

Now you are talking about TCA, about the configuration. That is not the
same like the data objects.

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

I don't propose to to split the TCA. We need that to configure model and
view generation. I propose to separte the query generator and the form
generator.

Regards

Elmar














More information about the TYPO3-team-extension-coordination mailing list