[TYPO3-ect] Final goal of the new framework ?

[Michael Scharkow]

Jean-Baptiste Rio wrote:
> Hi,
> 
> Thanks to JH and Michael for your answers

Hi, thanks for joining the discussion.

>> 1. Screw backwards compatibility: Anyone who still likes the XCLASS 
>> hell, the GLOBALS['foo'] inflation, the weird includeonce and require 
>> statements and various mysql_bla() calls is invited to maintain and 
>> develop the 4.0 branch until GNU HURD comes out or the end of time...
> 
> 
> I'm not that kind of guy :p I just want to avoid nights of work to 
> simply rebuild my extensions because the main class has disappeared. As 
> far as i have the insurance that the pibase class is still available, 
> i'm ok with any kind of new framework.

As JHH said, nothing is going to disappear anytime soon, so the worst 
thing that can happen to your extensions is that they don't profit from 
a better API.

>> 2. The basic extension *functionality* is not touched at all by the 
>> new approach, so in the *worst* case, you'd just move some code around 
>> and everything will be fine. I see this actually as a good thing 
>> because we can finally enforce compatibility with DBAL and the CGL.
> 
> 
> I have no experiment with DBAL stuff but i use the t3lib_div "exec_...3 
> functions . Is it enough to be compatible or do you plan to modify that 
> too ?

No, DBAL is just becoming more widespread, and it works. Why should we 
touch it. DBAL compliance means mostly *not* using raw mysql calls but 
TYPO3-DB->foobar() instead. Our future object-relational-mapper will 
also sit on top of this.

> Sometimes i'm a bit surprised by the extension meaning the Typo3 
> community has. I see three main kinds of extensions :
> A - Short or heavy development to add new specific Typo3 functions 
> (templavoila, ...)
> B - Short (sometimes heavy) implementation of an external application / 
> protocol / module / ... (by example : HTMLArea, NuSOAP)
> C - Short implementation to modify, enhance, ... TCA and other Typo3 
> static parameters
> 
> A => Targetted by the new framework ? Am I right ?

Yes, in the sense that we're basically replacing a lot of TYPO3 core 
stuff with our own implementation. But I hope that the MVC stuff will 
move into the core rather sooner than later because we could also 
rewrite sysexts etc. with it. In fact, I hope to get the install tool 
implemented in our MVC style for 4.5, because for usability reasons a 
rewrite is long overdue.

> IMHO, when i start such a job, i design, fix the final goals, ask for 
> people agreement, produce some document before binding a prototype. The 
> risk i see for this new prototype is that it could be not understood as 
> the good practice for new extensions.

I differ from this view and prefer more agile methods to writing docs 
first and doing design by committee. If we can up with a working 
implementation that makes extension writing (and almost everything in 
TYPO3 *is* technically an extension) so much easier and productive, why 
should anyone object to this being put into the core?
And even if it does not end up in core, we can put it in a lib just like 
Elmar did yesterday, and build on that. But I prefer the first because 
I think a lot of TYPO3 cannot be refactored but needs to be rewritten 
for 5.0.

> Again, i'm not against this new prototype, i just "rise up my finger" 
> and ask if you have thought to the "change management". It is just a 
> question of adhesion, as we say in french :)
> 
> Sorry, if you feel that i try to slow down the process, it's not my aim.

No need for excuses. You have a reasonable standpoint which I only 
happen to not agree with ;) I think large changes are needed (did you 
have a look at TCEMAIN recently?) because otherwise TYPO3 will become 
less and less maintainable. And now that the 4.0 is almost out of the 
door, why not already start with 5.0 in mind. Kasper himself has written 
that 4.0 is almost feature-complete, so chances are that 4.x will last 
for another few years, and maybe in parallel to 5.0

Greetings,
Michael