[TYPO3-mvc] Feedback on extbase

[Nils Blattner]

Hello everybody

I just finished writing an extbase extension for my company and would 
like to give you some feedback on how I cooped with this task.

First a bit about myself, so you may better understand from what 
perspective I write this:

I started programming about 10 years ago by scripting for mIRC, but soon 
changed to VisualBasic. I wasn't really happy with either and found PHP. 
Since then I've been to the university, learned a couple of other 
programming languages (amongst them C, Eiffel and, one of my favourites, 
Java).
At university I had a few courses tought by Prof. Bertrand Mayer which 
some of you may know. He is one of the early promoters of OO-Programming 
and invented Eiffel, which is OO-only and ships with a heavy style-guide :).
I didn't quite like Mr. Mayer and I quite frankly hated Eiffel, but some 
practices stuck.
Now since last December I work for cab AG and with this project (my 
second TYPO3 extension) was able to experience extbase.

Now to the project:

The goals were the following:

-	5000 Users should be able to update their data on a daily basis
-	Users would be anything from cleaning personal to CEO, so usability 
was a big point
-	Get to know extbase from an unbiased point of view (as I barely 
scratched "classic" TYPO3 extension programming)
-	Find out whether or not we should all change to extbase

In detail the project is supposed to encourage people to move more. The 
main goal for participants is to do 10000 steps each day 5 times a week. 
The project is supposed to run for 1.5 months and each user could check 
his (and his team-members) progress on a map.

The heavy use of form fields in this application (register/edit a team, 
edit a user and update the steps for each day) made this project 
predestined to check out extbase with the intuitive handling of forms 
and its return values.


So here goes my evaluation of my extbase experience.


After the initial "where the hell is everything" and after getting the 
hang of the extbase source and naming conventions, a lot of the things 
in extbase feel natural.
The upper camel case is nothing new and "call it by what it does" 
neither but it makes a programmers life so much easier when you have to 
read other peoples code.

However, the amount of abstraction used by extbase is sometimes hard to 
cope with! With our infrastructure Eclipse is not exactly the tool of 
choice, so I was limited to a (compared to eclipse) rather basic editor. 
And following some method all the way down to Typo3Backend.php and back 
can be a pain in the arse!
Having that said, I love abstraction. It's what helps keep code 
manageable. But the degree to which extbase uses it makes it hard to 
keep up with all its options. And with the lack of a good documentation 
(there was certainly none when I started) it is not so easy to keep 
track of them.

So then I started with an already very defined vision of the 
application. We defined almost every button beforehand, had a very good 
idea of what kind of data needed to be stored etc.
I went on and made the domain models from that. For someone who has seen 
modern programming styles this really goes natural.
And also fluid templating is very intuitive at first. But soon the 
problems started:
In our application handbook we defined that the labels should become red 
on errors, and not the inputs.
So I tried for some time to replicate the behaviour of the inputs until 
I finally just copy pasted the form.textbox ViewHelper and changed it to 
label (with some modifications of course).

However that was not the end of my pain with fluid. I had to make a form 
which allowed registering a team and up to 5 users. I started by adding 
all objects to the form, then went over to just the team and handling 
the users over direct paths and name="". However neither worked or 
worked the way I needed it so I ended up using a container array. But of 
course in an array the verification doesn't work.
So the solution was to write the whole verification and 
error-presentation (in extbase and in the template respectively) myself.
In a "classic" extension this would have been the normal course of 
action, but somehow I expected this to be solved in a cleaner way.
So this is one of my big "must have"'s, form handling and verification 
with multiple objects.

So after this big holdup there was barely an interruption to my coding 
until I hit the next snag. How the hell am I supposed to find out that 
getByUid (and the magic methods aswell, inherited from 
Tx_Extbase_Persistence_Repository of course) takes an array of UID's and 
behaves just like SQL's IN LIST().
I didn't find any information on that on the web and to date haven't 
found the piece of code that makes this godlike feature work (tough I 
suppose it must be somewhere hidden in the dark forest of the QOM section)!
Anyway, I ended up writing a little method that would just create my 
customized SQL, which sucks, but works.

So all was well for some time before I hit my last big problem:
To create an excel export and a newsletter list generator I made two 
backend mod's. In itself this is nothing frightening at all. And except 
for some issues with where to put it (Web or Direct Mail) it was a 
smooth ride.
But then the pid problem arose. All my data was stored in one pid, but 
the direct_mail-lists had to go somewhere else. After some 
experimentation and pulled out hair I found an option in the typoscript 
called newRecordStoragePid. It goes inside the definition of the table 
and does the trick if you have the same storage place for all records of 
the same type.
Luckily for me, this was the case here so the completion of the 
application was imminent.
But for future projects it is a must have feature to be able to define 
pids directly a) in a query and b) when storing!

Now we're testing the application and hopefully it will hold together 
once we put it in the wild. After which I will give you some more 
feedback on whether it buckled under load or held.


However, I'd like to thank everybody who has helped make extbase and 
fluid (the TYPO3 4.3 flavours especially) the way it is right now, but 
I'm quite sure you know that there is some way to go still.

I will submit what code I feel would be helpful to others in some way as 
a reply to this email. As I'm gonna leave the office in a minute or two 
this won't happen until tomorrow morning.
Whilst doing that I will also put up some bug reports/feature requests, 
so stay tuned.


I wrote this feedback in the hope that it is helpful to the dev's and 
maybe inspire one or three to try extbase with their next project.

PS: Wall of text crits you for 1000000 damage! :)

Regards

Nils Blattner
<nb at cabag.ch>