[TYPO3-ect] New roadmap lib/div/cool

Michael Knoll mimi at kaktusteam.de
Wed Nov 28 19:46:34 CET 2007


Hallo everybody,

long time gone since the last post here... ok. I've seen my name on this 
  post from Elmar and wanted to give some response... At the moment, I 
tried to combine Propel with lib/div, which works quite well, if you 
don't focus on deployment, because that could become quite a bit ugly.

I've done a little research and came to some conclusions on ORMs which I 
wanted to share with you.

As far as I discovered, you can chose between two techniques for ORM:

1. The Generator - way (Propel)
======================

* Code is generated for each table in your database

+ You can easily use these classes in your editor (tool hint, 
auto-complete...)
+ You an easily deploy those classes, as they are independent of the 
environment

- No dynamic "reaction" on changes in the DB config (TCA)
- Changes in DB config require a rebuild of the Base classes


2. The generic - way (e.g. Hibernate)
====================

* Only a set of classes needed, which are generic for all purposes

+ "One library for all" - means that no code needs to be created to fit 
project specific requirements
+ Easy to deploy
+ Changes in DB structure are easy to integrate

- No tool hints (auto - complete)
- Many dynamically created methods and properties make debugging difficult



Besides those main architectural differences, most ORMs use XML for 
configuration. So there are two ways for us to make those ORMs run with T3:

1) Transform TCA structure into XML
===================================

+ No changes in the ORMs are required, so no problems with updates
+ Easy to implement

- Changes in TCA are not automatically transformed to the DB structure
- Lot of informations from TCA gets lost, as ORMs are limited in their 
DB structure
- Double configuration

2) Adapt ORMs to use TCA
========================

+ Best integration into the T3 environment
+ ORM could react dynamically on changes of the TCA config
+ no double configuration

- Lot of work
- Every update of the ORM needs to be adapted


So - what to do? I'm not sure, whether I can implement a new ORM from 
the scratch all by myself. Object Relational Mapping seems to be quite 
well described in a lot of papers and books - so that there is only a 
lot of implementation left. Besides other projects need to be finished 
and can't wait for a ORM.

So my proposal would be the following: We could use Propel and first of 
all Propels interfaces for implementing extensions with lib/div. After 
some testing, we'll see, whether Propel does the job well and could 
implement our own ORM with the Propel interfaces, so that no change in 
the extensions is required - or at least only a little change. Thereby 
we could implement the ORM piece by piece and could replace Propel bit 
by bit.

To get an impression on how Propel works with T3, I've set up a little 
paper, which you can download from

http://www.kaktusteam.de/fileadmin/t3/t3pip/T3PIP.sxw

I'm looking forward on your ideas and suggestions!

So far

Michael






Elmar Hinz schrieb:
> Hello,
> 
> the last week I need to spend some time into work and research, to get a
> vision where to lead the lib/div/cool project and how to get it into a
> stable state. I want to give a short overview of the upcoming steps, as far
> as I can see it today. I will explain details later.
> 
> 
> 1.) Bringing lib/div to a final alpha version without adding new features:
> 
>     * lib/div is basically defined as a controller, with some assisting
>       helper classes (lib_link, lib_image, ...).
>     * The option to call "subcontrollers" like the resultbrowsers,
>       should stay.
>     * The pipe of processors should be stripped and 
>       exported to an optional addon extension. 
>     * Philip Almeida is interested to support here. 
> 
> 2.) Migrating lib/div to a PHP5 version with autoloading:
> 
>     * That's the part already started, but needs to be finished.
>     * This becomes the beta and stable branch of lib/div.
> 
> 3.) Component TS, probably under the key cool:
> 
>     * Make TS easily extendable with real objects, by extensions.
>     * Keywords: Object-TypoScript (obts), Tapestry, container, Spring, PAC.
> 
> 4.) Connecting ends:
>     
>     * The final step will be to optionally embed the components into 
>       nested XHTML templates. 
>     * It will be possible to set the component properties both from 
>       TS and from XML.
>     * Keywords: Tapestry, Asp.Net, Formidable.
> 
> Lib/div/cool will give solutions in the field of the controller and the
> view. They don't giv solutions for the model. We need projects in parallel
> here. As far as I can see there are two different successfull approaches,
> unsing dynamic or statically generated SQL:
> 
> A.) Active record: (Steve Ryan?)
>     * Ruby on Rails
>     * TYPO3 Core Engine (TCE)
> 
> B.) ORM: (Michael Knoll?)
>     * Propel
>     * Torque
> 
> There has been talking about projects in this direction for TYPO3 since
> years now. I would like to see some people comming up with an official ECT
> project here. 
> 
> Regards
> 
> Elmar
> 
> 
> 
> 
> 
> 
> 
>     
> 
>     
>     
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 


More information about the TYPO3-team-extension-coordination mailing list