[TYPO3-core] RFC: Bidirectioanl MM relations

[Ingmar Schlecht]

Hi guys,

I just committed a patch I got from René Fritz a while ago that adds a
feature to bidirectional MM-relation support making it possible to save
different relations to the same mm-table by means of so called
"matchFields".

I tested that it works properly with everything that worked before, and
committed it now already because I wanted it to be part of Beta 3 so it
gets tested by even more people.

cheers
Ingmar

Ingmar Schlecht wrote:
> This is a SVN patch request.
> 
> Problem:
> Currently you can edit mm-relations in the Backend from one side of the
> relation only.
> 
> Example:
> Say you have two tables, "persons" and "companies".
> Now, if you'd want to express the employment relation between those, you
> would either create a field called "employers" in the persons table or
> you would create an "employees" field in the companies table.
> Until now you couldn't make that relation editable from both sides, even
> though it would technically be possible if an mm-table is used.
> 
> Solution:
> We (Sebastian and me) made it possible to configure the same relation
> from both sides exactly the same way. There is only one difference
> between the configuration on the "foreign" side of the relation compared
> to the configuration on the "local" side (You still need to decide which
> side you want to call "local", even though there is no longer a real
> difference between the "local" and "foreign" side): The foreign-side
> needs to have the following defined in TCA:
>     "MM_opposite_field" => 'employees',
> 
> Here's an example configuration:
> 
>     $TCA["companies"] = Array (
>         [...]
>         "columns" => Array (
>             [...]
>             "employees" => Array (
>                 "exclude" => 1,
>                 "label" => "Employees",
>                 "config" => Array (
>                     "type" => "select",
>                     "foreign_table" => "persons",
>                     "size" => 5,
>                     "MM" => "companies_employees_mm",
>                 )
>             )
>         )
>     );
> 
>     $TCA["persons"] = Array (
>         [...]
>         "columns" => Array (
>             [...]
>             "employers" => Array (
>                 "exclude" => 1,
>                 "label" => "Employers",
>                 "config" => Array (
>                     "type" => "select",
>                     "foreign_table" => "companies",
>                     "size" => 5,
>                     "MM" => "companies_employees_mm",
> 
>                         // New:
>                     "MM_opposite_field" => 'employees',
>                 )
>             )
>         )
>     );
> 
> And the tables.sql file:
>     #
>     # Table structure for table 'tx_mmftest_company_employees_mm'
>     #
>     #
>     CREATE TABLE companies_employees_mm (
>         uid_local int(11) DEFAULT '0' NOT NULL,
>         uid_foreign int(11) DEFAULT '0' NOT NULL,
>         tablenames varchar(30) DEFAULT '' NOT NULL,
>         sorting int(11) DEFAULT '0' NOT NULL,
> 
>             # New:
>         sorting_foreign int(11) DEFAULT '0' NOT NULL,
> 
>         KEY uid_local (uid_local),
>         KEY uid_foreign (uid_foreign)
>     );
> 
> Difference between René's patch from 19.01.2006 and this one:
> René's patch didn't only make it possible to edit mm relations from both
> sides of the relation, but also added the possibility to store *multiple
> different* relation-types between the same set of tables into *one*
> mm-table. For example with René's Patch it was possible to store the
> employment relation as well as the customership relation (both are
> companies<=>persons relations) into the same mm-table by what he called
> "ident strings".
> However, we considered this feature to be not so important because you
> could just as well create a different mm-table for each relation-type. A
> positive side-effect of dropping that feature was that our patch only
> touches the "foreign" side and doesn't change any behavior on the
> "normal" side of the relation, so existing normal mm-fields are not
> changed in any way, which hopefully reduces the amount of bugs...
> 
> Now, for those who want to review the patch:
> What we mainly needed to do was modifying t3lib_loaddbgroup to use the
> uid_local field to store the foreign uid and the uid_foreign field to
> store the local uid in case we are lookign at a relation from the
> "foreign side". Unfortunately t3lib_loaddbgroup didn't know the TCA
> configuration of the field it was working on until now, but we needed
> it. Therefore we introduced a new parameter $conf to the start()
> function of t3lib_loaddbgroup containing the TCA field configuration.
> Then we needed to modify all places where t3lib_loaddbgroup::start() was
> called, to make sure the $conf parameter was passed.
> 
> Another problem we faced was sorting: The sorting on the one side of the
> relation (employees of companies) doesn't have anything to do with the
> sorting on the other side of the relation (employers of persons).
> Therefore we introduced another field sorting_foreign to handle sorting
> on the foreign side. If a new relation is added on the one side (the
> person selects a new employer), that new entity (the person) is listed
> on top on the other side (the company side). Whether new items added on
> the other side are listed on top or at the end of the list can be
> ajusted with the MySQL default value of the sorting columns.
> 
> I would like the patch to enter trunk rather sooner then later to have a
> long testing period until 4.1 is released. You can test the new feature
> with the attached test extension.
> 
> cheers
> Ingmar
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mmforeign_matchfields.patch
Type: text/x-diff
Size: 5252 bytes
Desc: not available
Url : http://lists.netfielders.de/pipermail/typo3-team-core/attachments/20070119/a898809f/attachment.bin