Feature #60368
closed
Build TCA and SQL Definitions from Entities
0%
Description
When adding some features to a project i allways wonder why there is not way to port an entity model into TCA.
It should be able to get most settings from the properties by now.
Now you allways have to synch TCA>eval, SQL Definitions and Model Validations, it would be much more efficient to simply create your model and add something like
\TYPO3\CMS\Extbase\Persistence\Generic\SomeTCATool::migrate('Vendor\\Package\\Domain\\Model\\SomeEntity');
SQL Definitions would be added automatically
TCA Definition would be added automatically
To add special things like Wizards, etc the TCA Overrides would have to be used.
Additonally you could connect the main engine that saves records in the backend to the model and do the persisting via the repository, so singal-slot hooks would also work, a TCEMainHook would not be neccessary anymore. That way an entity cache for extbase models would be very easy to implement too.
So effectively we would have 2 parallel ways of developing. The old - complicated - way of doing everything separately and the new way of letting extbase handle all those things.
Then you could also provice a command-controller to alter the SQL definitions automatically (for deploying):
php5 typo3_src/cli_dispatch.phpsh extbase migrate:addfields
I think this would also bring TYPO3.CMS\Extbase much closer to TYPO3.NEOS and would migration make much easier.
Updated by Philipp Wrann almost 10 years ago
Forgot:
Things like I18N, Workspaces, crdate, tstamp, cruser_uid etc could also be added automatically
Indexes could still be created in ext_tables.
To configure language settings you could still add the definition in TCA overrides.
Generally everything could be defined in TCA Overrides.
EG:
By default 1:M relations are created as group field, if you want a select instead you add the override.
Updated by Martin Sonnenholzer almost 10 years ago
I like your basic idea and support it, but how to deal with simple select boxes (that are not relations but just item select boxes).
I think this task would need a lot of thinkning and this extension https://forge.typo3.org/projects/extension-autoloader could be a first draft in my opinion.
Updated by Philipp Wrann almost 10 years ago
I think at first we would have accept that it could never deal perfectly with all situations, the specific example with the select is easy:
The property stays simply string|integer etc and the rendered SQL/TCA are exactly like that, because it fits for the model.
But if you need a select instead of a simple input you write it down in the tca override.
A type field could automatically be generated by superclass/subclasses setup.
Labels, Typeicons, etc should all be created with a strict convention.
All Labels located in
EXT:package/Resources/Private/Language/localllang.xlf:property.SuperClass.propertyPath
Overrides are located like its defined by now
Entity Icons are located in
EXT:package/Resources/Public/Icons/SuperClass/SubClass.png|gif || EXT:package/Resources/Public/Icons/SuperClass.png|gif || EXT:package/ext_icon.png|gif
That would be such a beneficence for all developers. More convention, less Configuration.
IMPORTANT: Dont think about complex packages (tx_news) where the benfits would not be that big (because so many things are afjusted here and there) but think about mini-extension you allways have to write for every project. It would be a model-created, migration, adding of some labels and its done.
Updated by Markus Klein almost 10 years ago
- Project changed from 534 to TYPO3 Core
- Category deleted (
Extbase: Generic Persistence) - TYPO3 Version set to 6.2
Updated by Markus Klein almost 10 years ago
The Extbase project on forge is legacy, please always add issues for the Core project.
Regarding your select box example: If you have a select for an integer property, you're likely to have a missing relation in db. And at some point in the life of an extension you will come to the point where you change that to a real 1:n relation, which would be rendered as select/group anyways.
Updated by Mathias Schreiber over 9 years ago
- Target version changed from 7.0 to 7.1 (Cleanup)
Updated by Benni Mack almost 9 years ago
- Target version changed from 7.1 (Cleanup) to 7.4 (Backend)
Updated by Susanne Moog over 8 years ago
- Target version changed from 7.4 (Backend) to 7.5
Updated by Benni Mack over 8 years ago
- Target version changed from 7.5 to 8 LTS
Event Sourcing and CQRS might be interesting here.
Updated by Riccardo De Contardi about 7 years ago
- Target version changed from 8 LTS to 9.0
Updated by Christian Kuhn about 7 years ago
- Status changed from New to Rejected
If you're doing DDD right, your models are often only a sub-set of what TCA can do.
The main glue in typo3 is not an extbase model, but TCA.
Thus, we will clearly not auto-generate TCA from domain models as functionality in the core. Maybe, maybe the opposite way (generate model from tca), and even that only if the clumsy domain modeling of extbase is improved at any time in the future.
What could be done is generating ext_tables.sql from TCA, but that should be done with a different issue (and i maybe work on that for v9).