Grundlegende Verständnisfrage zu MetaModels - Fremdschlüssel -

Hi,

ich stoße bei jedem Projekt - aber wirklich bei jedem - an Folgendes Problem, und würde mal gerne ohne viel SQL und so wenig Eingriff in den Quellcode wie möglich zurecht kommen.
Entweder verstehe ich einen Zusammenhang in MM nicht oder .. naja egal es kann es halt nicht.

Also zu meinem Problem(en)...

Es gibt die MM:
- Bereiche (alias, Name)
- Kategorien (alias, Name,Fremdschlüssel-Bereiche)
- Eigenschaften (alias, Name, Bild)

- Produkte (alias, Name, Fremdschlüssel-Kategorie, Fremdschlüssel-Eigenschaften [Tags])

So sieht zumindest für mich strukturierte Datenhalten aus.


Nun "möchte ich" z. B. das im Frontend ein Kategorien-Filter erscheint, der nur die Kategorien eines Bereiches anzeigt, respektive somit natürlich auch nur die Produkte aus einem Bereich. Dazu benutze ich immer viel SQL ...

Genauso sollen natürlich bei der Produktansicht die Bilder der Eigenschaften in der Detailansicht angezeigt werden.


Verstehe ich das richtig, das MM das Prinzip vom "Fremdschlüsseln" nicht wirklich versteht bzw durchgängig verarbeiten kann?

VG&Danke
Christian

Hallo,

da Du die Sachen in SQL lösen kannst, gehe ich mal davon aus, dass Du soweit in die DB Einblick hast...

MM kann mit Relationen - das meinst Du sicher mit den "Femdschlüsseln" - in mehreren Ebenen umgehen und anlegen. Die letzte Frage würde ich mal (vorsichtig) verneinen.


Zur "mittleren Frage": wenn Du Deinen Produkten per Tags Eigenschaften zugewiesen hast, kannst Du die Bilder der Eigenschaften beim Produkt anzeigen - alle Attribute eines MMs, welches per Auswahl [select] oder Mehfachauswahl [tags] verbunden wurde, sind im raw-Knoten des Templates abgreifbar - ggf. mal http://metamodels.readthedocs.io/de/...templates.html ansehen


Wenn ich das richtig verstehe, möchtest Du einen FE-Filter, der Kategorien anzeigt, die zu einem bestimmten Bereich gehören?

Also Du hast 20 Kategorien wovon 15 zu Bereich A und 5 zu Bereich B gehören und möchtest nun einen FE-Filter, der z.B. nur die 15 Kategorien anzeigt, die zu Bereich A gehören? Warum kannst Du die Produkte nicht einem Bereich zuordnen und danach filtern? Bzw. wenn Du die Einstellung hast "Nur zugeordnete", dann werden Dir doch nur die Kategorien angezeigt, die mit den entsprechenden Produkten auch verknüpft sind - was spielt der Bereich da für eine Rolle?


Gibt es einen Link zur Webseite, um das nachvollziehen zu können?

Hi,

danke - puh - hatte schon angst das "Versteht" keiner. Das mit dem RAW werde ich testen.

Genau auf die Idee mit der User wählt beim Produkt, den zugehörigen Bereich und dann aus einem 2. Subfeld eine dem zugehörigen Bereich zugeordnete Kategorie aus bin ich gerade am Testen.

Denn dann hätte man im Tupel zum Produkt sowohl den Bereich und Kategorie und die Auswahl wäre für den User logisch.

Leider bekomme ich es nicht (oder noch nicht) hin das in der Produktpflege im Backend die Werte von Kategorie nach Bereich gefiltert werden.

Mein aktueller Ansatz ist wie folgt:

- Der Benutzer wählt im select einen Bereich, das Formular "läd" neu.
- Ich erstelle einen Filter im Kategorie MM für Produkte der die Kategorie nach dem zum Produkt gespeicherten Bereich (dessen id) filtert.

Da bin ich gerade am rumbasteln.


// Update: Also Aktuell habe ich folgendes "Hinbekommen":

Im "Produkte" Formular wird bei der Auswahl eines Produkt-Bereichs das Formular abgesendet. Auf der Auswahl "Kategorie" liegt dieser SQL Filter:

Code:

---

SELECT * FROM `mm_category` WHERE `idtype` = {{param::post?name=type&default=1}}

---

Das funktioniert auch tadellos die Kategorien passen sich automatisch an.

Nur in einem Fall habe ich ein Problem:

Beim initialen Laden des Formulars passt natürlich "param::post?name=type" nicht und er zieht default. Da kracht es natürlich, wenn der User vorher eine Kategorie aus Bereich 2 gewählt hatte.

Man müsste wohl im SQL Abfangen:
- Enthält der bearbeitet Datensatz eine schon eine Kategorie. Nur wie komme ich an die Werte des geöffneten Datensatzes? Gibt es dafür auch Parameter?




-- Aktuell habe ich nur einen Zugang zum Backend durch Änderungen und versuche ist das Frontend unbrauchbar.





VG&Danke

Zitat:

---

Zitat von Diakon

Mein aktueller Ansatz ist wie folgt:

- Der Benutzer wählt im select einen Bereich, das Formular "läd" neu.
- Ich erstelle einen Filter im Kategorie MM für Produkte der die Kategorie nach dem zum Produkt gespeicherten Bereich (dessen id) filtert.

---

m.E. der richtige (oder ein richtiger) Ansatz... zu dem Thema Splitten der URL und Filterung gibt es ein, zwei Threads hier im Forum - leider gab es für die Lösung kein "Snippet" für das "Kochbuch" vom Handbuch... aber ggf. kannst Du das bei Erfolg zusammenstellen ;-)

Hi,

ich für mich pers. habe nun eine Lösug mittels

{{file::... }} und dort werte ich die Post oder entsprechend halt Get Variable aus. Pers. finde ich das unschön und würde es lieber mit SQL direkt machen.


Evtl. helfen ja irgend jemanden meine Ansätze weiter oder wir können diese hier weiterentwickeln und auf eine tragfähige Lösung für die Allgemeinheit bringen.

Ich probiere gerne aus, bin aber - wie man es neuerdings nennt - auch kein SQL Ninja...

1. Ansatz)

Ein Ansatz war im SQL über IF bzw. CASE im Statement zu gehen damit kann man aber sowie ich es gehen. Die Idee war liefert die Abfrage auf den POST Parameter nichts zurück mach eine Abfrage mittels GET.
Nur geht die FLOW CONTROL anscheinend nur auf die Auswertung der Ergebniszeilen ein also war das ein Griff in den Klo und nach 5 min verworfen.

2. Ansatz)

Mittels UNION oder DISTINCT die beiden Abfragen vereinen, das sieht dann bei mir so aus (Bereich=Type):

Code:

---

SELECT * FROM `mm_category` WHERE `idtype` = {{param::post?name=type}}
UNION
SELECT * FROM `mm_category` WHERE `idtype` = ( SELECT `type` FROM `mm_products` WHERE id = SUBSTRING_INDEX({{param::get?name=id}},'::',-1) )

---

finde ich ganz charmant, hacken bei der Sache natürlich ist der GET Parameter auch vorhanden, wenn man das Formular per "post" neu bedient nachdem man den Bereich gewechselt hat also werden in dem Fall der Fälle alle Kategorien des gespeicherten und des neu ausgewählten Bereiches angezeigt.


Da habe ich nun erst einmal "aufgeben", da mir aktuell bei dem SQL Statement und der Doku von Mysql 5.7 jeglicher Ansatz fehlt, wie ich dies verklausulieren könnte.

VG
Chris

Leider habe ich kein passendes Projekt, um hier was zu "vermitteln" - ggf. hat jemand so was auf Lager...

Alternativ kannst Du jederzeit eine Supportanfrage beim MM-Team machen https://now.metamodel.me/de/unterstuetzer/kontaktieren

Ich bin mir nicht ganz sicher, was Ziel der Übung sein soll. Den Aufbau des MM habe ich verstanden, aber was du genau wie, wo mit den Filtern erreichen willst nicht ganz. Du redest vom Backend? Oder Frontend?

Gesendet von meinem D5803 mit Tapatalk

Mittlerweile habe ich gemerkt, das "Noch mehr" dazu gehört außer das SQL fürs Backend. Daher will ich es hier noch einmal aufstellen und doch das file Posten:


> Metamodell- "Produkt-Bereich"

-------------------
| ALIAS | NAME |
-------------------


> Metamodell- "Produkt-Kategorie"

--------------------------------
| ALIAS | NAME | Breich-ID |
--------------------------------


> Metamodell- "Produkte"

-------------------------------------------------
| ALIAS | NAME | Breich-ID | Kategorie-ID |
-------------------------------------------------


Damit nun Bereichs-Abhängig Kategorien angezeigt werden gibt es auf das Feld "Kategorie-ID" in der Definition des MM Produkte folgenden SQL Filter, der im MM Produkt-Kategorie definiert werden muss:

PHP-Code:

---

<?php
$bereichPost  = \Input::post('type'); 
$bereichGet   = \Input::get('id'); 
$contaoDo      = \Input::get('do'); 
$contaoAct      = \Input::get('act'); 
$contaoMMPid  = \Input::get('pid'); 
$bereichGetId =  substr(strrchr($bereichGet, ":"), 1);
$defaultType = 1;

if ($contaoDo == "metamodel_mm_products" && !isset($contaoMMPid) && ( $contaoAct == "edit" || ($contaoAct == "create" && isset($bereichPost) ) ) ) {
if (isset($bereichPost)) {
echo "SELECT * FROM `mm_category` WHERE `idtype` = {$bereichPost}";
} else {
echo "SELECT * FROM `mm_category` WHERE `idtype` = ( SELECT `type` FROM `mm_products` WHERE id = {$bereichGetId} )";
}
} elseif ($contaoDo == "metamodel_mm_products" && $contaoAct == "create" && !isset($contaoMMPid)) { 
echo "SELECT * FROM `mm_category` WHERE `idtype` = {$defaultType} ";
} else {
echo "SELECT * FROM `mm_category`";
}    
?>

---

Erklärungen:
Das Feld "Kategorie" soll von seiner Datenherkunft (Auswahl) immer auf Bereiche reagieren und zwar im Backend bei der Bearbeitung der Produkte.

Grundlegend so stellt es sich für mich da ist in diesem Zusammenhang nun zu unterscheiden "soll der Filterüberhaupt angewendet werden/bin ich überhaupt in der Backend Bearbeitung".

Dafür werden folgende Unterscheidungen getroffen:

1. Fall ich bin im Editier- oder im Erstellmodus des MM Produkte dann soll die Auswahl der Kategorien der direkten Auswahl im select Feld Bereich oder der gespeicherten ID angepasst werden.
2. Fall man öffnet das Produkte MM zum Anlagen eines Eintrags, dann gebe alle Kategorien des default Bereiches zurück (Dem Bereich, der als 1. im Bereich selectfeld steht).
3. Fall man befindet sich im Fronted oder in der MM Konfiguration selbst hier soll der Filter einfach alle Kategorien ausgeben und nicht im Bereichs Kontext ausliefern.


Zusammenfassung:
Da wie man oben sieht es bei weitem nicht ausreicht im Filter "nur" den Zusammenhang zwischen den abhängigen Auswahlfeldern dar zu stellen, sondern auch programmiertechnische Fall-Entscheidungen getroffen werden müssen und man somit Logik in die Abfrage bringen muss, die SQL-Statements nicht liefern ist dies m.E. wirklich nur mit PHP möglich.#


FE etc. für Produkte:
Bezogen auf Frontend Filter für die Produktauswahl etc. ist es nun denkbar einfach ich habe für jeden Bereich einen Filter der mittels AND Anweisung an einen Kategorien Filter mit die Abfrage nach Published & Bereich A ... B etc. beinhaltet.

Ah, OK. Also im Backend würde ich mit mit Callbacks die Optionen der Kategorie Einschränken, mit einem reinen SQL-Filter wirst du da nicht weit kommen.

Ich schau nachher mal, wir haben mit Sicherheit ein Beispiel bei uns rumfliegen, wo wir genau so etwas schon gemacht haben.

Gesendet von meinem D5803 mit Tapatalk