[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