Schnellnavigation:

Kategorien

« Dezember 2013»
S M T W T F S
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        

Kopieren Sie diesen Link in Ihren RSS-Reader

RSS 0.91Nachrichten
RSS 2.0Nachrichten

In eigener Sache

Peter Linzenkirchner, Lisardo EDV Beratung in Augsburg. Freelance und Partner für Design- und Webagenturen in Augsburg und München. Pixelgenaue Templates, valides HTML, barrierearm. TYPO3-Projekte, Extension-Programmierung und mehr ... 

Zur Zeit wird gefiltert nach: Dezember 6
Filter zurücksetzen

Mit dem Extensionbuilder können Datenbank-Relationen für Extbase-Extensions leicht angelegt werden. Das wirklich schöne Interface hat aber zumindest in meinem Fall dazu geführt, dass ich mich anfangs nicht darum gekümmert habe, was genau denn dabei passiert. Und dann stand ich plötzlich vor dem Problem, dass die 1:n-Relation doch bitte ohne IRRE funktionieren soll. Das Problem ist an sich leicht zu lösen, aber eben nicht mehr allein über den Extensionbuilder. 

Worin liegt das Problem? 

Model A (Location) soll eine 1:n-Verbindung erhalten zu Model B (Image). Ziel ist die Präsentation von Orten mit Adresse, Beschreibung und beliebig vielen Bilder. Wird die Relation über den Extensionmanager angelegt (was sehr einfach geht), dann bekomme ich im Location-Datensatz im Backend ein IRRE-Feld für die Bilder. Soweit wunderbar einfach für den Redakteur, wenn es sich um ein paar Bilder handelt. Was aber, wenn es mehrere hundert Bilder sind? IRRE mit hunderten von Datensätzen macht keinen Spaß. 

Nun liegt der Gedanke nahe, einfach anders herum zu gehen: Wir legen einfach eine n:1-Verbindung von Model B (Image) zu Model A (Location) an. Im Backend ist das Ergebnis perfekt: Im Location-Datensatz sind die IRRE-Relationen zu den Bildern weg, während jetzt ein DropDown im Image-Datensatz erscheint, in dem die Location ausgewählt werden kann. Aber leider wird jetzt das Objekt auch anders herum gemappt: Model A (Location) enthält keinen Bezug mehr zu Modul B (Image) und die Locationliste zeigt somit keine Bilder mehr. Dagegen funktioniert es jetzt anders herum: die Bildliste enthält jetzt die Locations, was ich nicht brauche. 

Was ich erreichen will: 

Das Backend soll sich verhalten wie oben beschrieben, es soll also ein DropDown in den Bilderdatensätzen erscheinen, in dem ich die Location auswähle. Im Extensionbuilder erhalte ich das über eine n:1-Relation in Model B (Image). Für die Frontendausgabe brauche ich jedoch eine Liste der Locations mit den Bildern, was ich bekomme, wenn ich im Extensionbuilder eine 1:n-Relation in Model A (Locations) anlege. 

Wie bekomme ich das aufeinander? 

Datenbank

ich lege in der Datenbank zwei Felder an: in der Location-Tabelle das Feld "images" und in der Image-Tabelle das Feld "locations". Beide bekommen int(11) als Format. 

TCA

Im TCA der Location-Tabelle erstelle ich eine Definition für das Feld "images" in dieser Art: 

'type' => 'inline'
'foreign_table' => '….…._image',
'foreign_field' => 'locations',

damit erhalte ich das IRRE-Feld im Location-Datensatz. Im TCA der Image-Tabelle wird das Feld "locations" so definiert: 

'type' => 'select',
'foreign_table' => 'tx_camplist_domain_model_location',

wobei ich als Typ angeben kann, was ich benötige, hier ein Select, also je nach den weiteren Definitionen entweder ein Auswahlfeld oder ein DropDown. 

Objektmapping in beiden Models

Beide Models erweitere ich nun um die Objekt-Attribute $images im Location-Model (die Kommentare nicht vergessen!) und $locations im Image-Model. Dazu natürlich in beiden Models die passenden Getter und Setter ergänzen. 

Abschluss

Man kann jetzt im Backend die Bilder auf zwei Arten hinzufügen: entweder direkt als Datensatz und dort die Location in einem Dropdown auswählen, oder über IRRE im Location-Datensatz. Wenn ich die IRRE-Felder im Location-Datensatz verstecken will, so lösche ich im TCA der Location-Tabelle unter "types.1.showitem" den Eintrag "images". 

Kategorien: API  Kommentare 6
Besuchen Sie mich auf Google+