[Typo3-dev] The future of typo3

[Robert Lemke]

Hi Michael,

thank you for taking the time for writing your feedback. I will try to
comment a few points you mentioned.

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

> Item 1: Outdated interaction paradigm

In general I agree with you that it's hard to provide backend like
editing functions to the frontend. And although I still think that the
separation of backend and frontend users is a good idea, it's worth
being discussed.

>  * 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.

There has been some brainstorming and development to provide an easy way
of frontend editing, form rendering for frontends, evaluation and so on.
Daniel Thomas is currently working on an extension providing a better
connection between backend end frontend editing (i.e. rendering of
frontend forms by using TCA information etc.). 

I have also discussed the existing models (feadminlib, Julle's frontend
editing API) and ideas for a new approach with Christian Jul Jensen. We
did not find the time yet to publish our thoughts but Daniel Thomas has
started writing a RFC already and we'd be glad if you joined us with
some fresh thoughts about it!

> This paradigm is outdated and leads to grievances that should never have 
> been there. Why? Because it leads to redundant code.

I agree. But it might make sense to have a separation of frontend and
backend, sharing most of the same code e.g. for rendering forms,
evaluation, database access etc.

> 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.

That should be solved by a frontend forms / editing API.

> 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. 

In my opinion, TYPO3 is not meant to be a wiki but I guess a frontend
plugin providing those functions should be easily made within a day or
two. Dan Frost has been thinking about that already.

> 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.

That is a good point to discuss. I'd like to add more questions:

 - How about a new type of user which is allowed to create backend users
but is not administrator himself (i.e. without access to TS templates)?
 - What about a new user administration module which can easily handle
1000+ (backend / frontend) users?

> 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. 

Should be much easier with the frontend API mentioned above.

> 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. 

We've already had a discussion about if TYPO3 is consistent or not. As
I'm using TYPO3 for quite some time now, I don't see many
inconsitencies, but I understand that it might look like there are many
when you're getting started. The name "TypoScript" is a source of such
ambiguities.

> Typoscript (which is destined to be misunderstood by every newbee, since 
> it is *not* scripting language) is able to produce and manipulate page content. 

Or better: TypoScript is for configuring the engine which produces page
content output.

> 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.

That's a point many people complain about: Often there is more than one
way to solve a certain task. But behind all that there is TypoScript. 

I hope I got you right: You mean HTML Templates vs. TypoScript
Templates, right? Currently there are these two ways (plus PHP functions
of course) of creating page content output.

There are many people, who like the pure TypoScript way. They don't use
external HTML files but put all their HTML tags into TypoScript objects
and wraps. Usually that is the case if it's only one person creating the
HTML code as well as the TYPO3 implementation.

On the other hand there are people who prefer working with HTML files
and use TypoScript to replace certain parts with content. That model is
good for separating the work of a HTML designer and the TYPO3 developer.
E.g. using the automaketemplate extension, the webdesigner simply
provides an HTML file in a certain folder and won't have any contact to
TYPO3 itself.

So, what's the *better* way? 

I think there's no answer to this and even worse: There are already
ideas for a more powerful concept ...

> 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? 

Because in the future it *will* be easier to accomplish many tasks which
were not possible without PHP. TYPO3 3.6.0 will feature some new backend
features, one of the is called FlexForms. With the help of some
extension, it will be possible to create new content elements without
using PHP.

> 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"?

There's no secret about it. Kasper has spent most of his time with
documentation of the source code and cleaning up. Have a look at the
development version of TYPO3 3.6.0, look into the sources, everything is
explained right there were you'll need it - in the source. 

All comments are JavaDoc compatible, so it will be possible to create an
automated documentation out of the source comments.

Additionally some new documentations taking care of the fundamental
concepts of TYPO3 development and a description of the API are on the
way. What is still needed, are people helping us with these tasks.
Anybody who's interested in offering help should have a look at the
Teams and Projects page (http://typo3.org/1448.0.html)

> 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.

Partly on the way. However, if you have ideas on how to create such a
documentation or have examples of good documenation already done, you're
welcome to help us.

> 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.

We just started a reviewing proces of the existing extensions. The idea
behind it is to spread the knowledge of how efficiently program TYPO3
extensions and ensure a certain quality standard.

However, you're right - a bunch of extension programming tutorials
should be done. It's all about lacking time and manpower to do that
quickly.

> 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

I'm glad that - except for the frontend / backend ideas - we have come to the same goals 
for our future work. 

What do others think about this?

-- 
robert