Brainstorming zu verschachtelten Listen

[D23]

Eine Frage hierzu:
Funktioniert das genauso bei Kind-Kind-Tabellen oder muss man da zusätzlich etwas beachten?

Also:
Catalog A (Elterntabelle)
Catalog B (Kind von Catalog A)
Catalog C (Kind von Catalog B)

[Tim]

Funktioniert genauso. Ausschlaggebend ist die PID und die Tabelle. Das geht unendlich tief Wie es halt im Backend angelegt ist.

[D23]

Okay, dann nur nochmal zum korrekten Verständnis:

<?php
    \Input::setGet('pid',$entry->get('id'));
    \Input::setGet('table','cc_myChildTable');
    echo $this->replaceInsertTags('{{insert_module::18}}');
?>

In diesem Abschnitt muss man doch nur das 'cc_myChildTable' und die Module-ID ändern, der Rest bleibt bestehen, oder? Also 'pid' und 'id' in der ersten Zeile, sowie 'table' in der zweiten Zeile bleiben unverändert.

[Tim]

Der neue GET-Wert "table" muss passend sein zum nachfolgenden Liste-Modul. Sprich, es muss das List-Modul für "cc_myChildTable" sein. Sonst gibts nen wirrwarr

Der Aufbau ist im Backend. cc_parent.id = cc_child.pid

Darum set PID = entry ID

Lässt man CC einfach mal eine Liste mit Kinder-Links ausgeben sieht man es auch gut im Detail-Link. Das Liste-Modul reagiert auf ?pid=XXX&table=XXX

(könnte man also auch einen Hyperlink direkt setzen oder aus der Seitenstruktur direkt auf ne Kind-Liste verlinken usw. usw., brachten wir es als Filter )

[D23]

Sorry, verstehe ich leider gar nicht.
Jetzt mal konkret an meinem Beispiel, was muss da jetzt genau wohin?

Catalog A = cc_catalog_a
Catalog B = cc_catalog_b
Catalog C = cc_catalog_c

Ich bin im Listentemplate von Catalog B:

<?php
     \Input::setGet('pid',$entry->get('id'));
     \Input::setGet('table','cc_catalog_c');
     echo $this->replaceInsertTags('{{insert_module::18}}');
?>

Muss ich noch mehr ändern? Denn egal was ich mache, die Ausgabe ist irgendwie nie korrekt.

[D23]

Hab jetzt mal zur Problemeingrenzung hardcoded IDs vergeben:

<?php
     \Input::setGet('pid','35');
     \Input::setGet('table','cc_catalog_c');
     echo $this->replaceInsertTags('{{insert_module::18}}');

     \Input::setGet('pid','36');
     \Input::setGet('table','cc_catalog_c');
     echo $this->replaceInsertTags('{{insert_module::18}}');
?>

Dabei fällt dann auf, dass scheinbar das replaceInsertTags Probleme macht. Sieht so aus als würde beim zweiten Lauf die ID schlichtweg ignoriert werden, da als Ergebnis immer nur die erste ID (also 35) ausgegeben wird.

[Tim]

Das, was du hier machst ist ist gar nicht nötig! Das macht CC ja für einen out of the box sobald ein Eintrag eine Kindtabelle hat. Siehe Handerverzeichnis-Demo.
Dieses Beispiel von mir ist primär für Detailseiten gedacht.
Um auf einer Detailseite quasi die verwandten Kindeinträge zu listen.

[D23]

Ok, hab nicht alle Infos geliefert. Wir befinden uns ja in einer Detailseite.
Catalog A -> Detailseite beinhaltet Catalog B (Produktvarianten, via Listenmodul ausgegeben mit dem Code aus deiner Vorlage). Und die angezeigten Produktvarianten beinhalten wiederum Einträge aus Catalog C.

Wenn ich hier auch diesen Code verwende, werden aber bei ALLEN Varianten die Einträge aus der ersten Produktvariante ausgegeben.

[Tim]

Ok, hab nicht alle Infos geliefert. Wir befinden uns ja in einer Detailseite.
Catalog A -> Detailseite beinhaltet Catalog B (Produktvarianten, via Listenmodul ausgegeben mit dem Code aus deiner Vorlage). Und die angezeigten Produktvarianten beinhalten wiederum Einträge aus Catalog C.

Wenn ich hier auch diesen Code verwende, werden aber bei ALLEN Varianten die Einträge aus der ersten Produktvariante ausgegeben.

Ja, das geht natürlich nicht. Du müsstest dich zusätzlich ja auf Detailseite von Catalog B befinden, um dort wiederum das Schema anzuwenden.

Können wir all diese Einträge löschen oder verschieben? Es macht die Tutorial unübersichtlich.

[D23]

Können wir all diese Einträge löschen oder verschieben? Es macht die Tutorial unübersichtlich.

Aber selbstverständlich. Verschieben wäre gut, damit die Infos nicht flöten gehen.

Ja, das geht natürlich nicht. Du müsstest dich zusätzlich ja auf Detailseite von Catalog B befinden, um dort wiederum das Schema anzuwenden.

Wie müsste das dann gehandhabt werden?

[Tim]

Das sollte man aufbauen wie das Händlerverzeichnis. Oder du gibts zusätzlich zu PID, TABLE noch den ALIAS-ODER-ID der nächsten Detailseite mit. Der Parameter ist standardmäßig ITEMS

so wäre eine url: .html?pid=10&table=cc_myChild&items=myEntryAlias+

-> damit reagiert jetzt auch ein Leser Modul wieder. Man kann jetzt direkt wieder Leser und Liste direkt einsetzen.

[D23]

Das Händlerverzeichnis hab ich mir ja schon angesehen. Das ist ja in einzelnen Detailansichten aufgebaut. Ich bräuchte das alles aber in der Detailansicht des Elternelements.

[Tim]

wenn deine erste kindliste, wiederum ein template enthält was von dort auf die zweite kindliste verweist. nach dem schema dieses tutorial sollte das klappen.

- Detailseite
-- Kindliste 1 (Schema Tutorial mit Daten aus Detailseite Template
--- Kindliste 2 (Schema Tutorial mit Daten aus Liste-Template Kindliste 1 -> ist wahrscheinlich sogar das gleiche Template möglich )

usw. usw.

(klingt jetzt schon strukturell verbaut )

Aber so sollte alles ausgegeben werden auf einer Eltern-Detailseite

Ganz programmiertechnisch gesprochen, wäre das eine rekursive Anwendung. Vergleichbar mit dem Navigations-Modul in Contao, was die Seiten abhangelt. So muss man denken.

[D23]

Hätte ich auch gedacht... Funktioniert aber leider nicht. Wie gesagt, da werden dann bei den allen Einträgen von Kindliste 1 die Ergebnisse von Eintrag 1 aus Kindliste 2 ausgegeben... schwer zu erklären.

[Tim]

In einer freien Minute bau ich mir mal eine kleine foreach Schleife Bin mir 99%ig sicher das geht