[TYPO3-mvc] TYPO3-Core complete rebuild to realize modern development paradigms?

[Gabriel Kaufmann | Typoworx]

Hello Jigal,

thanks for your feedback and critics are also welcome!

To try to give some short feedback on your suggestions:

> First of all, the extensive use of words like "old", "antique", 
> "dusty", etcetera gives a rather negative vibe. The fact that 
> technology or code wasn't created last week doesn't mean that it isn't 
> usable or maintained. 
I think both of our opinions are correct partly:

Of course "old" functions are not always bad or never touched since it's 
initial release. But since I also had some projects I needed to figure 
out and find bugfixes that are core-based, I think I can have my opinion 
on the code there. Of course my opinion does not apply on the whole 
core! But as mentioned there are some places that might have been 
updated, but somehow it's structure is "locked" in a state to maintain 
compatibility that it makes impossible to give it the new kick to 
modernize it.

I think it's only a matter of time that places will become a real 
problem for TYPO3 then....


> Same reason as 1.; you can use better relationships in your extensions.
As long as the TYPO3-Kickstarter, TYPO3 Tutorials and Literature is 
introducing the function as it is, it will never be dropped by 
developers! In some cases I also need a feature like that, but I would 
prefer a solution that is modernized in it's backend/storage under the hood!

Of course this may lead into some adaptions in the Core as until today I 
even didn't find a core-method that covers the Split-Preparation for 
this situation. Every single place is covered by custom code there, 
which makes a fix to something new harder.

But I also think it may be possible to find a solution that makes the 
Core have a fallback-option that transparently changes the 
storage-solution. Only some Extensions using direct MySQL may lead to 
incompatibility which could be fixed by an Announcement and introducing 
a Core-function solving this issue.

> Regarding FlexForms...
>
> The XML is transformed into a PHP array. Flexforms are for example a 
> powerful tool to make BE forms for editing plugin configuration. 
I totally agree with you and I'm also a supporter of FlexForms as I 
really love to use them!

But as you stated: FlexForms are rather the same than native TCA 
(PHP-Array). But why then some features documentated in TCA-Syntax 
simply don't work as expected then?

To give only one banal example I am currently fighting with: FlexForms 
"Select" doesn't support foreign_table_where Markers (###REC_FIELD_[ 
fieldname ]###) for a back-relation to the FlexForm-Fields itself! F.e. 
TemplaVoila does automatically "merge" the current database-table with 
the FlexForm-Data it is currently focused in. For Non-TemplaVoila 
Flexforms (f.e. TCEforms) you always have to cook your own itemsProcFunc 
solving the problem by hand.
( Refer to: http://forge.typo3.org/issues/50785 )

I think such features should work out of the Box: If TCA provides it, 
there should be a similar/same way to do it in FlexForms.


> You've started a discussion about this in a separate thread, so I 
> think it's best to keep it there. 
Your correct. It should not be part of this discussion here to solve 
that - but in fact it's one focus of the problem discussed here.


> It's always possible that bug reports or feature requests are closed 
> which should not have been closed. [..]
Of course I know and understand your argumentation. I also know that 
most developers (even like me) work more or less for free or in their 
spare time on the TYPO3-Project.

But if there is a solution for a problem is provided "on tablet" with a 
patch that could be approved and used, I think those issues could be 
processed prefered as they may improve TYPO3 a lot. I also found 
sometimes really nerve-wracking bugs that I thought I post the bug as 
first-person - but then found out there exists a complete bug-track with 
a patch provided (that even works for us), but the Issue itself is 
sometimes older than one year where nobody takes notice of that!

For developers like me spending their time on such things, it is also 
frustrating if nobody of the community seems to care about that and the 
work was useless as it is not noticed for newer TYPO3 releases.


> also came to the conclusion that there might be the right time to start
> something "new" upon TYPO3 to begin a new-age for TYPO3. 

As noticed in my last post... I have eyes on NEOS and hope they don't do 
the same faults they've done on TYPO3 v.4 Extbase and TYPO3 6.x _not 
doing a clean-cut-off_ old paradigms.



Best regards