[Typo3-dev] The future of typo3

["Kasper Skårhøj"]

Hi Michael.

I have spend enough time on private mails with you already so this is going to be short:

- Some of your points are not fair when you talk about paradigms and ways things should work which obviously is just your own idea. Sometimes, what you call outdated, we call a feature. And customers agree.
- Some of your points are good, I agree, but I have done my best, is still doing and have in the process also become aware that my ambitions for TYPO3 which could easily be exactly what you have described is just not possible for me to do overnight. This is already hard enough to accept, that your thoughts are always lightyears ahead of what you can actually get done.

All in all I'm very proud that TYPO3 has become what it is. When I think about the process of making this project I'm very proud to see how FEW inconsistencies there are after all. I'm proud to realize how often I made a decision that after all made TYPO3 better than another decision would have meant for it.

TYPO3 is not perfect but I've tried my best to make it. And to the degree it has been realized I'm actually exceedingly satisfied. And honestly that makes me trust myself and my views far more than yours.

And lets say that everyone agrees with you and suddently nobody wants to use TYPO3; I would still be happy with my creation since I works for me and actually that was where it all started anyways; To create a tool to help myself. I'm sorry for sharing that with the world. What a sin.

Finally michael; If you had had 5 years of full time development starting also 5 years back in experience - would you claim that you could have achieved something better than TYPO3? In terms of quality, community, documentation, consistency, standards etc?

I'm sorry TYPO3 was not the system for you, there must be something else outthere since there are so many things wrong. 

Thanks for your comments. It could have been more constructive if you offered and proved your own help in terms of solving some of these issues and maybe mentioned a few nice things about the system on top of it - currently you have portraited yourself as a bitter man who has spend a lot of time on a system which does nothing right. So why bother giving us advice?


God bless

- kasper

*********** REPLY SEPARATOR  ***********

On 25-10-2003 at 12:51 Michael Zedeler wrote:

>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
>				
>
>
>_______________________________________________
>Typo3-dev mailing list
>Typo3-dev at lists.netfielders.de
>http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-dev



God bless

- kasper


- kasper
-------------------- o ---------------------
>>>    In God I trust - others pay cash!     <<<
Check www.typo3.com