Currently I've the impression, excuse if I'm wrong, the whole solution is somehow monolith and decisions to add this or remove that are made once and for all.
This shouldn't be the case, it was ok when extbase was relatively new and people had to learn how it works, and how extensions have to be built in general.
Some decisions I've in mind, and that left somehow -- at least some thoughts:
- removal of the test folder, including all test files
- the change from plugin based on field
list_type to one based on CType
I think those things should be configurable and optional available.
Furthermore I've the impression that the whole classes rely strongly on the implemented view logic, and the switch from one JS-framework to another one has impact on almost everything.
Instead I'd prefer an agnostic core API and the view is built around it. Like this theoretically even different views would be possible, i.e. one like that of sav_library_kickstarter.
I know concerning the update to v12 I'm coming quite late with my thoughts, but I didn't have the ideas before.
Currently I've the impression, excuse if I'm wrong, the whole solution is somehow monolith and decisions to add this or remove that are made once and for all.
This shouldn't be the case, it was ok when extbase was relatively new and people had to learn how it works, and how extensions have to be built in general.
Some decisions I've in mind, and that left somehow -- at least some thoughts:
list_typeto one based onCTypeI think those things should be configurable and optional available.
Furthermore I've the impression that the whole classes rely strongly on the implemented view logic, and the switch from one JS-framework to another one has impact on almost everything.
Instead I'd prefer an agnostic core API and the view is built around it. Like this theoretically even different views would be possible, i.e. one like that of
sav_library_kickstarter.I know concerning the update to v12 I'm coming quite late with my thoughts, but I didn't have the ideas before.