[TYPO3-extbase-kickstarter] Roundtrip concept for the kickstarter

Nico de Haen typo3 at ndh-websolutions.de
Sat Jul 17 12:41:24 CEST 2010


> should we store TCA-information in your ClassSchema? (e.g. attaching the
> default value for a property to the ClassProperty seems like a good idea
> to me)

what kind of TCA information do you mean? the property type for example?
 I think we should only reflect modifications of parts that are not
editable by the kickstarter. So if someone defined a property of type
boolean and then changes the type in the code we will overwrite his
modifications on next save, unless he changes the property type also in
the kickstarter

There might be cases, where a user defined value can't be displayed in
the GUI, Like a TCA wizard definition for example. We have to find a way
how to handle these cases.

In general I would prefer not to store TCA related stuff in the class
scheme. If you think of properties like

'displayCond' => 'FIELD:t3ver_label:REQ:true'

or all the IRRE related stuff:

'appearance' => array(
	'collapse' => 0,
	'newRecordLinkPosition' => 'bottom',
),

I wouldn't like to see that in a php class file.

It's enough to have tags like

@var boolean, string etc.
@validate StringLength(minimum = 3, maximum = 50)
etc.

and these should be editable by the kickstarter.

> BTW: i have parsed the first TCA file now, and it looks quite promising for me so far. guess i will split the array in tca-columns and then decide by diff3
behaviour which changes will go into the result.


That means you manage modifications only with diff? What will happen if
someone modifies the config settings for a property and the renames it
in the kickstarter? Will he loose his changes?

What about the "include(MyCustomTCA.php);" approach? Maybe we should
discuss in this list what is considered to be the best solution...


regards,
Nico


More information about the TYPO3-project-extbase-kickstarter mailing list