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

[Daniel Brüßler]

Hello Robert,

thanks for the info about the 5-implementation of MVC/PAC/Registry. It
helps me much to keep an eye on the migration-path to 5. Until now I
didn't care about it ;-)

I'll link to some 5-topics from the ECT-pages in the 4-wiki, so we don't
get double content. I think a page "Migrationpath to 5" or a similar
pagename should be enough in the 4-wiki. Your sum-up in your post is
helping much, I think also this is best to have in the 5-wiki.

I should also have much much more time ;-(

kind regards
Daniel


Robert Lemke schrieb:
> 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
> 
> 
>