[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