[TYPO3-mvc] Why don't we suck at TYPO3?

[Christian Zenker]

Hi everyone,

> Do you have some ideas here? What hinders *you* in using gerrit?

Your post on this issue in the newslist is marked as "important" by me for  
a month now. It seems I should have a look at it again. ;) My problem is,  
I don't have an extbase dev environment running (yet), and I don't really  
know, how to actually test bugfixes. Especially when they are deeper in  
the system, I can't really determine, if there might be side effects.

> For us, it's not easy to motivate people to contribute more; as we think  
> one needs some "inner drive" to do that.

A really important point! Let's talk about me... :) what hinders me in  
getting more involved is, that I don't really know about the development  
philosophy behind FLOW3 and extbase. I see extbase primarily as the  
transition tool to FLOW3, so - in my head - every feature in extbase  
should be implemented in FLOW3 first. I think in most cases its just a  
mental barrier that makes FLOW3 and extbase look too huge to some -  
including me. You know: *The* FLOW3 with the shiny bling bling and the  
pure injected awesomeness to each line of the code? So you should just  
touch the FLOW3 very carefully as you might destroy the shininess - so  
better don't touch it at all.
On the other hand, you have extbase as the little son of FLOW3 and the  
deeper I try to dig into the more often I think "wtf where they thinking  
when coding that?"[1] I haven't really used FLOW3, but I guess it might be  
similar there. But now the question to me is: Am I supposed to fix it? I  
think "someone"(TM) who wrote this stub functionality has an idea how this  
is supposed to work from FLOW3, so I don't have to fix this as  
"someone"(TM) will do it anyway. And even if I fixed it, how can I be sure  
that it will be accepted?

Maybe a solution could be to have prioritized tasks that you leaders see,  
need to be done, but don't have the time for it. So you should specify the  
API and some constrains. Then for everyone who is willing to help, it is  
obvious what has to be done and that his work is not in vain and it will  
be reviewed by a core dev and hopefully in extbase soon.
One of the things were I think this could work is the condition evaluation  
of Fluid (AND, OR, string comparison etc.). That task is not too large to  
handle, and it could really move (in this case) Fluid forward without any  
backwards compatibility issues.

The same goes for a whole bunch of viewHelpers. Sometimes I don't know if  
you even see the need for them. There are lots of viewHelpers in the  
incubator (and most of them look as if they solved common problems). But  
as far as I see, none of it made it to an official repository yet. What is  
missing here is just one of you guys saying, which viewHelpers you want in  
Fluid, maybe discuss the peoples experiences in the newslist and then just  
do it! Or create an official extension with not that commonly used  
viewHelpers. I think especially writing viewHelpers is a nice way to get  
started with helping out the development of fluid and extbase. And even if  
your response to a suggestion is "We don't want to add your viewHelper,  
because..."  or "We have a more general approach here..." (rather than  
"Your approach should be more general") it would be more helpfull than  
just having your viewHelpers lying around in the incubator or even your  
local machine.

> Furthermore, we'd like to prepare quite some sessions on the Dev Days  
> (together with you), to bring Extbase forward and hopefully more people  
> will attend then. As soon as we are in the planning phase for it, we'll  
> let you know here and collect/discuss the most pressing bugs/annoyances  
> to be resolved there.

Definitely!
I'll be there (with a probability of 90% :) ).

> Please don't forget that we're in a different situation than a year ago:  
> We need to keep Extbase backwards compatible more than ever (a lot of  
> people are using it in productive projects today).

I was really surprised by the smooth transition to Extbase 1.3. Although  
many new features where added, your explanations in the Wiki made it  
really simple to upgrade! And that even though I did some really nasty  
stuff with non-public APIs. ;)
So why not use the release cycle of TYPO3 to add new features to Extbase?  
Extbase 1.4 might break a few things as long as Extbase 1.3 will be  
supported as long as TYPO3 4.5. As extbase and fluid are sysexts and not  
in TER this should not be that complicated.


Thanks for your efforts.

Christian.


[1] few examples (you probably know them):
     - the pagination widget: the default template is almost useless. There  
aren't even classes assigned to the tags. And if you want to use your own  
template, you'll have to copy the whole controller logic, too...
     - Dependency injection: Really nice thing! (honestly) I was really  
looking forward to have a possibility to easily extend domain models,  
but... you know the story...
     - AJAX widgets: I had to dig into ajax widgets recently. The idea was  
really simple: You have a timeconsuming, non-cacheable request to do that  
would slow down page generation for a few seconds. As it was just a  
smaller functionality of the page, I thought creating an AJAX widget was  
the right way to go. After a few minutes I had something that was working  
as I expected - really great! But... as soon as it moved to the testing  
server I had to find, that the configuration for the widget was stored in  
the user session and if you received the cached version, nothing could be  
loaded... Ok, that's not the problem yet. I completely understand, that  
due to all of our limited free-time not every feature desirable will be  
implemented when the author sees no need for it. So the idea sounds  
straight forward: Create another Widget_AjaxWidgetContextHolder that  
stores the configuration in the database and inject it to my  
WidgetViewHelper. But this approach would not work as most of the  
properties and methods in Widget_AbstractWidgetViewHelper are private (!)  
and therefore not extensible! (one of those "wtf"-moments) There is just  
no clean way to do this without copying most of the logic in the  
Widget_AbstractWidgetViewHelper. I really don't get why anything in a  
framework, that is supposed to be flexible, should be private (with a few  
exceptions)...



  At the first Extbase meeting on
> the Core Team Sprint besides me (Bastian), only Dmitry was there; so the  
> session was pretty quick; but as a lot of sessions had happened in  
> parallel, this is not surprising nor a reliable sign for lack of  
> interest. Generally we think it makes sense to  do "Extbase code  
> sprints", however this is best for bigger features or  refactorings.  
> First off, we need to improve the day-to-day workflow.

>
> One more commitment by us: We both did not review the Gerrit changes as  
> fast as it should be (some being there for about a month); that's why  
> we'll commit ourselves to at least one hour per week looking through the  
> open changesets, testing, providing feedback and merging.
> However, this also means that we need you: If you pushed a changeset,  
> please be prepared to answer our questions and submit follow-ups.
>
> In the comments of the blog posting [5] it was mentioned that Extbase is  
> missing strong leader. In fact, we're trying the opposite: While we are  
> making sure that the general goals of Extbase and FLOW3 match up and  
> that the aimed-at quality is assured, we do not see ourselves as the  
> "main implementors" of features or bugfixes. Especially, we cannot  
> create the momentum in the community to fix a bug and to share that fix.  
> We can only ask everybody to do so; and would like to help reducing any  
> obstacles on this way (especially using Gerrit, see above). We are not  
> making Extbase, the community does. We are only the shepards.
>
>
> Please don't forget that we're in a different situation than a year ago:  
> We need to keep Extbase backwards compatible more than ever (a lot of  
> people are using it in productive projects today). On the other hand we  
> need to stay in sync with FLOW3, which is still changing a lot - and  
> this conflict is not easy to solve. With the beta release of FLOW3 1.0  
> this will hopefully change and we'll be able to backport all the  
> important features & changes. To be able to keep existing Extensions  
> running anyways, we're planning to introduce a "compatibility flag" as  
> discussed in Berlin.
>
> Our Proposal: We need to be more clear about the next features which  
> will be part of Extbase; but right now, as stated above, the focus is  
> definitely on *bugfixes, not features*. We try to improve our  
> communication in this regard.
>
> So let's join forces, make Extbase & TYPO3 even better and never forget  
> the main goal, TYPO3 Phoenix!
>
> Greets, Looking forward to your feedback,
> Sebastian Kurfürst & Bastian Waidelich (Extbase & Fluid Project Leads)
>
> PS: Maybe we *do* suck at doing Extbase, but the above headline was more  
> twitter compatible ;-)
>
> [1] http://foertel.wordpress.com/2011/05/01/why-do-we-suck-at-typo3/
> [2]  
> http://lists.typo3.org/pipermail/typo3-project-typo3v4mvc/2011-February/008539.html
> [3] https://review.typo3.org/#change,1563
> [4]  
> http://lists.typo3.org/pipermail/typo3-project-typo3v4mvc/2011-April/009173.html