[Typo3-dev] The future of typo3

[Michael Zedeler]

Hi list

I have been using typo3 for about two months now. This was supposed to be the first typo3-project, and I considered it as an evaluation of typo3 with regard to deciding whether I should start using it in my business. I do proffesional IT-consulting and part of my assignments consists of building portals, corporate websites and intranets.

My descision is that typo3 is not really worth using due to several, critical design flaws. I hav had much more trouble than I "bargained" for when I started my evaluation project, and I have narrowed down the scope where typo3 is useful quite a lot. Since typo3 is Open Source, I would like to share with you why I have come to this conclusion. Maybe it will result in a product more useful some time.

My critique is broken down into items, that I will happily discusss with anybody reading this. I may sound very harsh, so please bear in mind that I do this for the better of typo3. Kill your darlings.

Item 1: Outdated interaction paradigm
Typo3 is built around a paradigm that goes something like this "we publish - they read", where "we" are the people with access to the backend and "they" are those people who only have access to the frontend. This is an old paradigm that dates all the way back to 1995 where I started my career as developer, and I thought it was long gone. Yes - there is a way of adding data here and there using some very rudimentary frontend plugins, but the basic idéa is that you need backend access to do anything really fancy.

I base this observation on the following facts:

 * The frontend users and groups have been completely separated fron the backend users and groups by putting them in separate tables.
 * The code that handles permissions works very differently depending on what part you're logged on to.
 * The backend uses fairly advanced form-building libraries that seem impossible or very hard to reuse as part of the front end.

This paradigm is outdated and leads to grievances that should never have been there. Why? Because it leads to redundant code. If you want to make a front end plugin that receives data from a user, you'll basically have to start from scratch. This is absolutely crazy, when you keep in mind that the backend has a lot of nice form-building libraries. It leads to longer development time and more (possibly critical) errors.

Another, much more fundamental problem is that many websites uses heavy interaction with all users, and does not comply with the very rigid frontend/backend-scheme. An example is wikis where everybody have access to edit everything. I know it is possible to do with typo3, but only by letting people straight into a backend that uses a fixed layout with little room for customization. Another example would be any website using heavy user interaction with many levels of permissions (or roles), such as an information portal, an intranet, extranet or the like. In those cases, you have to either let the users straight into the backend when editing something or doing it all ground up.

Ask yourself: how many times have you developed a front end plugin that uses the rich text editor? My bet is none or very few because it is cumbersome. This is a waste of good code. I can go on ad infinitum with regard to the rest of the backend code.

I propose that:

 * All users and groups belong in two tables. Not four. Merge backend and frontend code.
 * The backend should not be built as an application seen very differently from the rest of the system. It should be just another - very advanced - facility available on the website, possbily broken into a large number of plugins that you can insert wherever you want them.
 * The frontend should have access to the advanced libraries today only available in the backend.

The new paradigm should be "everybody can edit - if permitted to".

Item 2: Inconsistencies and loose ends in the system
Typo3 does not seem very consistent to me. Most things seem to have been invented and implemented without thinking about the overall design. I haven't had time to dig around in the code for long, so I'll just mention the conflict between typoscript and the templates. Typoscript (which is destined to be misunderstood by every newbee, since it is *not* scripting language) is able to produce and manipulate page content. The same can be done using templates, so which one do you choose? Typoscript has access to templating functions, so why not choose it as a basis for almost everything you do? That is not possible, because typoscript isn't complete with regard to the tasks you may have to solve. Putting data in a table in a database is one of those things not possible.

So what is the alternative? The alternative is to switch to PHP, which has the effect that typoscript is hardly useful for any purpose besides simple configuration of the application you write, and nothing else. My conclusion is that most serious work cannot be done without coding something in PHP, so why promote Typoscript so strongly? Why is there almost no documentation of all the PHP-libraries for typo3, when this is actually what makes everything in typo3-world tick?

What I see when I look at the development plans is that there is a lot of effort put into developing new features. This is more fun for the developers, but please keep in mind that what I think is really neeeded is a big cleanup and a completely new set of documentation. I find it aggrevating to see little or no mention of theese problems on the website. Is it a "family secret"?

Item 3: Lacking architecture documentation
I have had a hard time trying to find a manual that explains the core of typo3. When developing typo3-plugins using PHP, I need some kind of roadmap that explaings how the most important parts of the system works. What it should cover is a description of the request-response-cycle, how parameters are passed to various parts of the system, user authentication and the properties and methods of the TFSE.

Item 4: Lacking best practise documentation
There is no documentation specifying how to write a plugin from a-z with all bells and whistles - using best practise. New developers are left to reinvent their own best practise which can be very time consuming.

Item 5: Kickstarting in the wrong direction (minor item)
The kickstarter is a great tool for getting started, but I think that the code it produces is of very low quality. I have had to rewrite the class files for forntend plugins completely because they were really not very flexible or easilly extensible. Other wierd inconsitencies found were:

 * The text "[Insert your comment here]" for commenting the code has been inserted in functions that have already been made by the kickstarter for you. What is the idea here? Comments are supposed to help developers understand what the code does, but for some reason commenting has been turned into a guessing contest.
 * The functions getFieldHeader and getFieldContent has clearly been developed for use in some other context.
 * The file ext_typoscript_editorcfg.txt is undocumented. Asking on the mailing list what it does lead to Christian Jul answering "its not really meant to be used for anything".
 * The files ext_tables.php, tca.php, locallang.php and locallang_db.php are riddled with syntax errors because consecutive rows in arrays are terminated by an extra comma. PHP can parse them, but syntax checkers choke on the errors there and it doesn't look nice.
 * AFAIK the main()-method tries to access a value called "CMD" that will always be unavailable because the field "select_key" from the table "tt_content" has not been passed to the plugin. Since the main()-method isn't working as it should, most people trying to extend a class generated by the kickstarter will get a tough start.
 * It would be nice if templates were used by the plugins generated.

Summary:
I think that the future development of typo3 should be focused on the following items:

 * Get to grips with the actual intensions of the different parts of the system. What is typoscript supposed to do? Are developers supposed to work mainly in PHP? If "yes", please provide documentation! Are developers supposed to work mainly in typoscript? If "yes", please make it complete!
 * Working out better documentation - see above.
 * Cleanup of code with two main targets: (1) make it available for reuse everywhere - eliminate the separation between frontend and backend and (2) rethink local design descisions that leads to redundant code.

Developing new features is just another mudcake on top of the foundation of mud that has already been made. There is no solid foundation for large extensions, so don't even try.



- Michael Zedeler (mzedeler)

-----------------------
The mailing list archive is found here:
http://typo3.org/1427.0.html