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

[Michael Knoll]

Hi Elmar,

wow - I thought you'd rather laugh at me for my proposals :-) But as I 
read your answer, I think we have kind of the same opinion in using 
already developed pieces of software :-)


Elmar Hinz schrieb:
> Hello Michael,
> 
> that is good news. Having a proof of concept and this nice article is
> already half the way. With this knowledge people can already start to
> develop extensions with propel.
> 
> Are this relations right?
> 
> generator way <-> generic way 
> normal ORM    <-> active records
> torque        <-> hibernate   
> propel        <-> ???
> symfony       <-> cakePHP

Hm - yes and no. You mix equivalent and non-equivalent things so here is 
my "correction"

generator way  vs. generic way

"normal ORM"   vs. active record
(I suggest to take a look in "Patterns of Enterprise Application 
Architecture" to get the difference [1])

torque         vs. Hibernate
Never worked with either of them, only know them theoretially. As far as 
I can see, Torque uses a bottom-up aproach, which means, that you build 
your data-objects out of an existing database (like Propel does in our 
case), whereas Hibernate uses a top-down aproach, where your Java 
classes implement certain interfaces to make them persitent via 
Hibernate, no matter how the database looks.

propel can be rather compared to torque, I suppose.

symfony is a framework like cakePHP

> 
>> 1) Transform TCA structure into XML
>> 2) Adapt ORMs to use TCA
> 
>> 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.
> 
> My proposals:
> 
> 1.) Pimp your current doc and put it into a documentation extension: 
> 
> http://typo3.org/documentation/document-library/extension-manuals/http://typo3.org/documentation/document-library/extension-manuals/
> 
> We should also think about something like: http://ect.typo3.org, to
> communicate ECT results and extensions.

I will do that. Perhaps, I could write an article about ORM and the 
techniques behind in the T3 Wiki, to get the main ideas and getting a 
basis for discussion.

> 
> 2.) Making a tca2xml converter for propel configuration. 

As you can use "reverse engineering" from your DB structure to Propel 
XML, perhaps that's rather the way to go than creating XML out of the 
TCA structure - but I will give it a try!

> 
> 3.) Making lib/div interface. 

A good point here. As lib/div doesn't really differentiate between the 
domain modell itself and helper classes to create data-objects. I try to 
give you an example for what I mean. Let's say, you want to put up a 
model for fe_users. The first example is the lib/div way:

$model = $this->makeInstance(...);
$model->loadUserById(...);
$model->setName("t3poweruser");
$model->save();

So what you have, is a model, that contains the domain functionality as 
well as the ability to create itself. For me, the second part (creating 
the model) should be part of a static class, that creates a model for a 
certain domain. I'll give you an example:

$model = FeUserModelHelper::createNewUserModelById($id);
$model->setName(...);
$model->save();

I'm talking about this point, because Propel differentiates between so 
called "Peer-Classes" and the model classes according to your database 
schema. So perhaps, we should also differentiate in those two aspects of 
functionality in lib/div.


> 
> I think we shoul use Propel unaltered, without a piece by piece replacemet.
> All modifications of external tools are quickly outdated upon updates.
> 

That's exactly, what I think :-)

> Regards
> 
> Elmar
> 
> 



Still there are some points, I forgot in my last post, where we have to 
find a solution


1) Double DB Access with Propel:
================================

Propel doesn't use T3 DBAL and replaces it with Creole.

2) Fake M:N relations:
======================

Propel won't be able to work with these non-atomar database fields. 
Besides they
are really messy, the developer will have to extend the basic Propel 
classes, so
that they can do the job. I will put this in my documentation.


I will use the weekend to put that all together in a first draft for a 
documentation extension and send you a link to read it!

Thanks for sharing your ideas, I hope, we get this working!



Michael