[TYPO3-ect] TYPO3 5.0 and lib/div/registry/orm/world domination

[Robert Lemke]

Hey everybody!

As a long-term lurker on this list I am embraced by the enthusiasm  
you are developing here in the ECT. By your research and discussions  
you undoubtedly aim to put TYPO3 4 on a new level, giving extension  
developers the opportunity to create extensions using modern  
techniques. While lib/div originally was about implementing a Model- 
View-Controller mechanism for TYPO3 4.x plugins, you recently  
expanded your goals because you see the need for a cleaner  
architecture with more potential.

Now, with the current suggestions about registries, autoloaders,  
ORMs, domain layers and so forth, I would like to intervene a bit.  
While you are seeking for something I absolutely agree we should  
have, we should be aware of the fact that these requirements are the  
main reason we started with a rewrite of TYPO3 (ie. 5.0) in the first  
place. Therefore let's join force and make sure that we know what  
each team is working on - otherwise we'd not only waste a lot of time  
but also confuse all the developers and users out there ...

I've been in contact with Elmar and promised to create him an  
overview of what the 5.0 MVC component is up for and how it is  
designed. I'm also looking forward to have a meeting with members of  
the 4.x Core Team, the ECT and 5.0 Dev Team in order to discuss a  
common roadmap and strategy.

Well, the only problem is that all this catches me at a bad point in  
time - I'm still working on some parts of 5.0 which I need to get  
finished until T3CON07. Along with the code I will also present some  
documentation (which still needs to be written) - something which  
could be interesting for you as well. So what I can't afford  
currently is investing a big amount of time into discussions; but I'd  
like to comment a few topics you've been discussing recently, just to  
give you an idea what we've been planning in that regard for the 5.0  
project.

I hope for your understanding that I try to keep my involvement in  
discussions a bit short for now, but I promise that I'll invest more  
time for that after T3CON07!

Here are my comments:

=== General overview of 5.0 ===

Phew, I guess I won't manage to give you a complete overview in this  
post but at least some pointers.

Generally if you'd like to browse our code, visit our Trac website,  
there you'll find everything you need: http://5-0.dev.typo3.org/trac/ 
TYPO3/. This includes API documentation (currently offline) and the  
"Guide to TYPO3"

I recently tried to give an overview of the 5.0 architecture in a  
video podcast (http://castor.t3o.punkt.de/files/ 
podcast_robert_001_thecurrentarchitectureoffivezero.m4v) - it's quite  
lengthy but it hopefully gives you a general idea.

You can try out TYPO3 5.0 on your own - but you'll need PHP6 for  
that. Check out our page about a quick installation:
http://5-0.dev.typo3.org/trac/TYPO3/wiki/QuickInstallation

The general notion of TYPO3 5.0 is: Focus on the domain! We want to  
free developers from the burden to check security, fiddle with  
templating, different types of access (command-line, web, GTK, etc)  
and allow him to fully concentrate on the business logic = the domain.

=== lib/div: MVC in 5.0 ===

This is the main point which is under construction at the moment -  
and also experiences heavy changes every now and then.

The MVC part is part of the "Framework" package in 5.0. Although its  
main task is to provide the basic MVC mechanisms, it fulfills a lot  
of related tasks as well.

A hit on a 5.0 website generally intiates a sequence which can be  
seen in this diagram: http://robertlemke.de/downloads/posts/ECT-5.0- 
MVC_Regular_HTTP_Request.png
(Be warned: things change quite rapidly at the moment and this  
diagram could be outdated very soon)

So, as you can see, we have a RequestHandlerResolver which chooses  
the most suitable RequestHandler for the current request type. The  
RequestHandler acts as a Front Controller and prepares the Request  
object (by invoking some RequestBuilder) and creates a void Response  
object. They can be modified by some processors which run in a chain.  
The Request and Response are handed over to a Dispatcher which solely  
has the task to invoke the correct Controller and call the right  
(action-) method.

A Controller will usally be an ActionController. It is responsible to  
decide about what actions to take and fulfill them. It aquires the  
model and - in the simpliest case - fetches a view, passes the model  
to it and adds the rendered output of the view to the Response object.

In a more sophisticated approach, the Controller does not create /  
select a view himself but rather uses a Widget to display his model.  
A Widget basically consists of a Presentation Model, a Presenter and  
a View - it generally follows the Model-View-Presenter pattern (see  
this great article for details: http://martinfowler.com/eaaDev/ 
uiArchs.html). The point is that the Action Controller does not know  
and doesn't have to care about the type of request or response - it  
only carries out actions, prepares the model and selects one or more  
widgets. The widgets on the other hand have a view for XHTML, for CLI  
etc.
With that approach your Controller will automatically work at the  
command line or in the web - if you want.

Here's a little example of an action method:

   /**
    * Lists all phone book entries of our phonebook
    *
    * @return void
    * @author Robert Lemke <robert at typo3.org>
    */
   public function action_displayPhoneBookEntries() {
       $tableModel = $this->componentManager->getComponent 
('T3P_Widget_ModelAdaptor_Domain2Table');
        $tableModel->setDomainModel($this->phoneBook);
	
         $tableWidget = $this->componentManager->getComponent 
('T3P_Widget_Presenter_Table');
         $tableWidget->setModel($tableModel);
	
         $this->response->setData($tableWidget->render());
    }

Of course this all is a very simplified view on the mechanisms - but  
as I said, I'll prepare that for T3CON07.

Maybe, when the concept is more stable, we can find out how we can  
adjust the terminology and some mechanisms between 5.0 and lib/div a  
bit so users have it easier to migrate eventually when 5.0 is released.

=== Registry ===

The idea of creating an object registry for TYPO3 is a good one. But  
there are big implications with that.

All I can say about that is that we've chosen to implement a full- 
featured Component Manager with Dependency-Injection support. The  
Component Manager not only acts as a registry (as in the Registry  
pattern) but completely controls the lifecycle of any object. Here's  
a nice article about Dependency Injection: http://martinfowler.com/ 
articles/injection.html

My recommendation is that you _not_ try to create a registry for  
TYPO3 4.x. After you did that you'll want many more features which  
all make sense and finally end up realizing that all that doesn't fit  
within the 4.x architecture and that it already has been implemented  
in 5.0.

=== ORM ===

To make it short: Please don't start with it either. It might be fun  
trying to integrate an existing ORM, but really, the 4.x architecture  
is not well suited for working with objects in an object-oriented  
way. And writing an ORM is a huge task.

The approach in 5.0 is to create a persistence manager which is as  
transparent as possible. You create a class in the Domain Layer (for  
example a "PhoneBook" class) and implement all neccessary properties  
and methods (createEntry(), deleteEntry() etc.). Finally you define  
the scope of this class (we say "component"): it's not "prototype",  
not "singleton", not "session" but it's "persistent". That's it. You  
don't implement a save method or create some model.xml, schema.xml or  
whatever - the Persistence Manager will reflect your class and makes  
sure that your object is always there.

If you're seriously interested in this topic, you're very welcome to  
join us in the 5.0 team (preferibly after T3CON07 ...).

So the notion of the 5.0 approach is: You just work with objects and  
act as if there wasn't any database. Why should you care to write an  
SQL query if you can ask the PhoneBook object for PhoneBookEntries ?

=== Domain Layer for lib/div ===

Although it's good to think from a Domain's perspective, a Domain  
Layer isn't something you can just implement for an extension. It's  
rather a part of the overall architecture of your application. An  
example is the sketch we scribbled at some 5.0 meeting in February  
(http://news.typo3.org/typo3temp/pics/6744977b95.png).

I highly recommend two books here, really, they are a must read:

http://martinfowler.com/books.html#eip
http://domaindrivendesign.org/books/index.html#DDD

=== Action Chains ===

I have something like that in mind for 5.0 - but it's not a new  
thing, I must admit. The idea is that we have Commands (following the  
Command pattern) which act as a well-defined interface for  
ActionControllers and other Controllers. Now, a Command can either  
execute a single action or may consist of other Commands (a Composite  
Command or "Macro"). These Commands can be triggered by Controllers,  
events or for example by a workflow engine.

=== Auto Load functions ===

We use a Resource Manager for that which provides one or more class  
loaders. The RM will have more tasks in the future but currently is  
more or less a stub of what it's going to do.

*******

Okay, I'll better stop here for now, got to get back to my work ;-)

I hope that this post contained some interesting information for you  
and that I could make you aware of the problem we run into if we  
don't adjust our courses. After all I'm very happy that you brought  
the awareness of MVC to TYPO3 4.x. Now let's see how we can use that  
expertise for 5.0 and provide the users of TYPO3 a smooth migration  
path.

Cheers,
robert
-- 
http://typo3.org/gimmefive