[Typo3-UG Denmark] To-vejs MM-tabeller

[Sune Vestergaard]

Hej

Helt generelt ville det vel være væsentligt bedre at arbejde på at få 
udvidet konfigurationsmulighederne for at definere en mm_tabel i TCAen sådan 
at man, ud over at kunne definere hvad mm_tabellen skal hede, også kan 
definere hvilken kolonne (kolonnen med hvilket navn) den enkelte TCA sektion 
skal betragte som sin egen nøgle - og hvilken der skal betragtes som den 
fremmed nøgle.

I praksis er det da relativt uholdbart at vedligeholde 2 tabeller som både 
teoretisk og i praksis skal være ens. Jeg kan alleree se det cronjob for 
mig - der skal stå at overvåge at det rent faktisk er tilfældet - og den 
stakkels teknikker (i dette tilfælde sikkert dig selv Peter  :-) der skal 
tage stilling til hvilken af de to tabeller der rent faktsik er den rigtige 
når (ikke hvis) det periodiske job igen opdager en uoverenstemmelse.

Jeg vil gerne anerkende at den løsning der arbejdes på nu, muligvis er noget 
af det eneste der på kort sigt er praktisk muligt uden at hacke kildekoden 
direkte. Men når der nu stilles et så konkret ønske (og endda et ganske 
rimeligt og normalt ønske) - og det samtidigt er relativt nemt at overskue 
at implementere det i kernen, uden på nogen måde at gå på kompromis med 
bagudkopabilitet - burde vi så ikke lige ligge nogle timer i det og forsøge 
at overbevise en med CVS-adgang om at det skal implementeres. (du må være et 
ganske overskueligt antyakl steder hvor det er praksis er implementeret).

Hvis jeg kan være med til at få det lavet rigtigt vil jeg gerne bruge et par 
timer af mit liv på det.

MVH
Sune Vestergaard


"Peter Makholm" <peter at makholm.net> skrev i en meddelelse
news:mailman.372.1112278436.19001.typo3-ug-denmark at lists.netfielders.de...
> Christian Jul Jensen <christian at jul.net> writes:
>
>> 1: definere to MM tabeller: tabel1_tabel2_mm, og tabel2_tabel1_mm, og
>> via ovennævnte save-hook i TCEmain, sikre integritet mellem de to
>> tabeller.
>
> Jeg arbejder på denne løsning og det ser ud til at ville kunne komme
> til at virke. Jeg skal lige fifle lidt mere med at sørge for at gøre
> det rigtige med sorting og når man sletter relationer.
>
> En halv dags kodning, så burde jeg have en fuldt funktionel proof of
> concept-implementation klar. Men fredage plejer at være ret
> mødeoptaget, så det bliver først i næste uge.
>
>> 2: kun definere en tabel, og ved at XCLASSe t3lib_db swappe uid_local
>> og uid_foreign på den ene af tabellerne.
>>
>> Mulighed 2 er nok det cleaneste, men giver et lille overhead på alle DB
>> forespørgsler, hvilket I måske ikke er interesseret i.
>
> Det tror jeg ville blive ret omfattende hvis det skulle være
> transparent for resten af systemet. Jeg tror heller ikke at jeg vil
> kalde XCLASS for pænt. Det er godt tænkt, men som løsningsmodel
> skalerer det ikke ret godt.
>
> Det rammer bare ned i et lidt grundlæggende problem med normal OOP og
> PHP. Hvis nu PHP var dynamisk nok til at jeg på run-time kunne pille i
> klasse-definitionen så kunne det skalere. Men det er et problem i PHP,
> ikke i Typo3.
>
> Jeg har dog ikke set andre sprog der ville kunne løse samme opgave.
>
>>> Jeg kan heller ikke helt se den teknisk dybere forskel mellem 'select'
>>> og 'group'. Brugergrænsefladen er lidt forskellig, men når alle mine
>>> elementer er samlet i en lang flad liste er 'select'-boksen vel det
>>> bedste.
>>
>> Præcis, det er interfacet der er forskelligt.
>
> Godt.
>
> -- 
> Peter Makholm     |    I congratulate you. Happy goldfish bowl to you, to
> peter at makholm.net |      me, to everyone, and may each of you fry in hell
> http://hacking.dk |                                               forever
>                   |                                      -- The Dead Past