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

[Daniel Pötzinger]

Very interesting - Thanks for your work!


I recently read the book DDD from E.Evans and just want to point out 
some things I remember in relation to this.
* there is always a (semantic and technical) diffrent in the domainmodel 
<-> relational database.
* a strong use of ORM has the danger to
   ** have a class for each relation, which does often not fullfill the 
real purpose of a domainmodel.
   ** let the developer thing to much of the ORM classes instead of a 
clean domainmodel

I think this ORM mapping tools are very useful for some relations to use 
in the underlying functional layer of a model.
I dont know how a integration in lib/div/cool is planned but i think its 
good to have such ORM just as an option to use where really useful. And 
have the freedom to use just simple SQL in your classes where the use of 
a ORM framework is overhead (maybe a default interface for this can be 
defined on the basis of the propel interfaces?)



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