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

[Michael Knoll]

Hi Daniel,

seems like, we've read the same book ;)

Daniel Pötzinger schrieb:
> 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.

Of course there is. The domain model is much richer in logic and 
functionality as the Relational Model could ever be. But I think, ORM 
can build up a basis on which you can develop your domain models on.

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

As I tried to explain by dividing the classes into Helper- and 
Domainmodel-Classes I wanted to show exactly that fact.

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

Yes.

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

That's what it is. There is no need to use the ORM, you can still use 
your common way to access the database. Take a look at my document, so 
you can see the possible ways to access your data. It works perfectly in 
parallel, but it really makes the job a lot easier for you.

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

You have that - not with Propel, but by using Propel, you can either use 
Creole for simple DB access or use the DBAL.

So far!

Michael




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