[TYPO3-mvc] FYI: Progress in implementing support for generic domain models

[Jochen Rau]

Hi Christopher.

Christopher Hlubek wrote:
> since we try to use Extbase for a project and really need to address the
> generic table problem now, I made a few (actually quite a lot) changes
> and fixed some bugs to make tableName != className possible.

Extbase is still in alpha state. I don't recommend to use it in 
productive environments until TYPO3 4.3 is released.

I know that we are late but we are catching up.

> But I think we have an underlying conceptual problem:
>
> Generic stuff should not be configured in the TCA!

I don't think we have a conceptual problem here. The only thing that is 
configured in the $TCA is the target class name of relations 
(foreign_class). The mapping of classes <=> table is configured via 
TypoScript in my currently developed implementation (see below).

> Imagine two different Extbase plugins using a generic table (e.g.
> fe_users) and each of these plugins has a model for the generic table (I
> think it's pretty obvious that sharing a common predefined model for
> generic tables would be stupid). In the TCA you could only configure ONE
> model for a table.

Sharing a common predefined model for generic tables is not stupid as 
long as you are able to extend the predefined model

e.g. Tx_MyExtension_Domain_Model_Client extends 
Tx_Extbase_Domain_Model_Person

In case of the fe_users you can use the predefined model directly:

$this->administratorRepository = 
t3lib_div::makeInstance('Tx_BlogExample_Domain_Model_AdministratorRepository');
[...]
$this->view->assign('administrators', 
$this->administratorRepository->findAll());

> IMHO the table name should be configured for the specific model to solve
> this problem. I propose (and have implemented) an annotation "table" for
> the model classes that is only needed for generic models and will be
> parsed by the data mapper with the reflection service. I know that the
> table information doesn't belong to the model from a DDD point of view.
> But I don't see a better solution right now. We could add that to a
> repository and get the information from the repository, but that means
> every generic model needs a repository.

In my current sketch, the mapping must be configured only for those 
tables and fields that are not holding the naming conventions. The TS 
can be as follows

plugin.tx_extbase {
     classes {
        Tx_Extbase_Domain_Model_FrontendUser {
        mapping {
           tableName = fe_users
           columns {
               lockToDomain.mapOnProperty = lockToDomain
           }
        }
     }
}

> So accessing a generic model not only through a relation (that is what I
> read below from the post) is absolutely necessary for things like user
> registration and pages / content modification or whatever we cannot
> imagine right now.
>
> I had some problems to implements this, because dependency injection is
> not used for some objects (e.g. the query factory uses a static method
> on Dispatcher! to get the persistence manager, which is mainly due to
> the fact that the query factory is directly instantiated in a lot of
> places). We should really fix that. Furthermore there were some bugs
> that are not so obvious when the table name is equal to the class name.

Thanks for fixing these bugs. I have patched the lines.

> In this patch I also included a fix for a recursion problem with
> bidirectional associations (e.g. blog<->  post), where the object must
> be registered before mapping properties and relations. We should open a
> different bug for that but I didn't have time to exclude the fix from
> the patch.

Again: Thanks! I hope it works now.

I am going to commit my changes later today. I really appreciate your 
feedback.

Regards
Jochen

> Jochen Rau schrieb:
>> Hi.
>>
>> I just wanted to inform you about the progress I make on implementing
>> support for generic domain models like FrontendUser (=fe_users).
>>
>> My current sketch (not committed yet) is that you can say
>>
>> --8<--- snip -----
>> class Tx_BlogExample_Domain_Model_Administrator
>>    extends Tx_Extbase_Domain_Model_FrontendUser {
>>       // nothing to define
>> }
>> --8<--- snap -----
>>
>>
>> The generic domain model Tx_Extbase_Domain_Model_FrontendUser implements
>> all the class members and methods necessary to access the fields in
>> fe_users.
>>
>> Inside the Blog you have
>>
>> --8<--- snip -----
>> /**
>>   * The Administrator of the blog
>>   *
>>   * @var Tx_Extbase_Domain_Model_FrontEndUser
>>   */
>> protected $administrator;
>> --8<--- snap -----
>>
>>
>> and in the $TCA you specify
>>
>> --8<--- snip -----
>> 'administrator' =>  Array (
>>      [...]
>>      'config' =>  Array (
>>          'type' =>  'select',
>>          'foreign_table' =>  'fe_users',
>>          'foreign_class' =>  'Tx_BlogExample_Domain_Model_Administrator',
>>          'maxitems' =>  1,
>>      )
>> ),
>> --8<--- snap -----
>>
>> You don't need to configure any mapping for yourself.
>>
>> I am a little bit enthusiastic about this feature because that enables
>> us to implement a lot of generic models for
>>
>> - persons
>> - addresses
>> - places
>> - (calendar) events
>> ...
>>
>> No more reinventing the wheel by every extension developer!
>>
>> I need to polish the things a little bit before I can commit it. And
>> maybe I have to wait for the refactoring of the whole PID stuff (done by
>> Sebastian next week).
>>
>> Regards
>> Jochen
>>
>>
>>
>

-- 
Every nit picked is a bug fixed