MetaModels grupieren

Hallo MMler,

ich arbeite mich langsam in MM ein.... meine Anerkennung pur!

Eine Frage zur Organisation der MMs:

Ein MM stellt ja in der Datenbank eine Tabelle dar - wenn ich ein abzubildendes "Modell" normiert habe, werde ich verschiedene Tabellen haben, die untereinander in Beziehung stehen und als Gesamtheit die gewünschten Daten speichern und für eine Ausgabe bereit halten.

Das Modell ergibt sich meistens aus einer bestimmten Anforderung bzw. Projekt.

Was mache ich, wenn ich mehrere unterschiedliche Projekte habe - in einer Contao-Installation? O.k., die Tabellen an sich stören sich nicht, aber es fehlt eine Gruppierung was zusammen gehört.

Ich könnte mir vorstellen, dass man eine Hierarchieebene "Projekt" über die Metamodels setzt und bestimmte MetaModels darin bindet. Mit der Projektebene könnte man auch eine Gruppe in der BE-Navigation erzeugen und die Tabellennamen unterscheinden. z.B. Projekt 1 hat Kürzel pr1 => alle Tabellen haben die Form mm_pr1_*; Projekt 2 dann pr2 und die Tabellen mm_pr2_*

Für das Projekt MM-Import/Export hätte das den Vorteil einer (automatischen) Gruppierung der zugehörigen Tabellen.


Gruss

Das kannst du doch benennen wie du magst. Es muss halt nur ein mm_ davor stehen. Aber wie schon bei der Ordnerstruktur, alles was darüber hinaus geht ist nicht Bestandteil von Contao und daher auch nicht von MetaModels. Und im Backend kannst du sie ja gruppieren. Das ist doch das wichtigste oder?

o.k.... gibt es für die Gruppierung bzw. Anzeige ein "Tool" oder wird das "zu Fuß" per DCA gemacht?

Welche Gruppierung meinst du genau? Die der Navigationspunkte im Backend?

Ich bin auch eben beim Einarbeiten und hab' das folgendermaßen gemacht.
Ich bin das Tutoriel durchgegangen:
http://de.contaowiki.org/MetaModels
Und wenn man das auf einer Website bis zum Ende nachbildet, versteht man, wie man "Ordnung" da rein bekommt.
Ganz allgemein schon mal: Wenn Du eine Tabelle benennst, z.B. ersatzteile, benennt das System die Tabelle beim Abspeichern automatisch in mm_ersatzteile um.
Damit ist schon mal ein Zusammenhalt gewährleistet. Die Namensgebung aller Elemente wie Eingabe, Anzeige, Filter, etc. ist ja Dir überlassen, und da kannst Du selber eine Hirarchie erstellen. Prj_Ersatzteile_BE_Eingabe, Prj_Ersatzteile_FE_Anzeige_Liste, Prj_Ersatzteile_FE_Anzeige_Liste_Detail, usw.

Zitat:

---

Zitat von andreasisaak

Welche Gruppierung meinst du genau? Die der Navigationspunkte im Backend?

---

ja, wie bei der Movi-DB-Demo

Zitat:

---

Zitat von KlausGrenoble

Die Namensgebung aller Elemente wie Eingabe, Anzeige, Filter, etc. ist ja Dir überlassen, und da kannst Du selber eine Hirarchie erstellen. Prj_Ersatzteile_BE_Eingabe, Prj_Ersatzteile_FE_Anzeige_Liste, Prj_Ersatzteile_FE_Anzeige_Liste_Detail, usw.

---

... korrekt - ich kann natürlich für jedes Projekt noch einen eigenen "Präfix" einsetzen...

Bei der MM-Erstellung werde ich z.B. bei Tabellen-Verknüpfungen auch Tabellen aus anderen Projekten sehen/zur Auswahl haben - z.B. bei Select-Auswahl aus einer anderen Tabelle. Aber das ist ja nur bei der Erstellung interessant.

Ich bin der Ansicht, mit der "Projekt-Klammer" wird es an eigen Stellen übersichtlicher...

Hallo,

ich möchte das Thema nochmal aufgreifen...

Mit unserem MM-Workshop in Berlin sind mir einige Erkenntnisse zuteil geworden ;-)

u.a. dass die 1:n-Relationen nicht als serialisiertes Array abgelegt wird sondern vernünftiger Weise per Relations-Tabelle - sehr schön!

Mit Blick auf den Export/Import sehe ich da aber Probleme. Wie soll der Export laufen? kann man nur alle MMs exportieren oder muss man die zu exportierenden MMs anwählen? Da die Relationen zwischen den eigenen Tabellen in einer Relationstabelle abgelegt wird, muss die auch mit.

Weiterhin sehe ich Probleme beim Export/Import mit den IDs - da diese normale auto_increment Integer sind, müsste bei einem Export geprüft werden wie die ggf. vorhandene Struktur aussieht und alle IDs angepasst werden. Möglich wäre aber bei den IDs auf einen Hashwert zu wechseln, wie das z.B bei Oxid-Shop gemacht wird.

Warum alle Relationen in eine Tabelle kommen ist mir ad hoc nicht einleuchtend - ich hätte die Tabellen dynamisch generiert als mm_rel_<Tabellenname1>_<Tabellenname2>


Gruss

Zitat:

---

Warum alle Relationen in eine Tabelle kommen ist mir ad hoc nicht einleuchtend - ich hätte die Tabellen dynamisch generiert als mm_rel_<Tabellenname1>_<Tabellenname2>

---

Eine Tabelle hat, wenn die Felder ausreichend Informationen bereitstellen, eine Menge Vorteile. Neben dem zentralen Suchen und Finden von Verknüpfungen, ist auch dein Export/Import wensentlich einfacher. Spätestens mit dem nachträgen Umbennenen von einer MM-Tabelle, wäre ein rekursives Verknüpfen nötig. Ich würde es weiterhin so halten - wie bei den Kommentaren in Contao. Alle in eine Tabelle, sind ja alles Kommentare und anhand des Feldes "source" wird die Quelle bestimmt.

ps. Du wirst bei einem Export eines MetaModels eh alle core MetaModel-Tabellen mitnehmen müssen. Sonst fliegen dir gleich alle Attribute ins leere und deine Tabelle ist leer bzw. sofort gelöscht.

Zitat:

---

Weiterhin sehe ich Probleme beim Export/Import mit den IDs - da diese normale auto_increment Integer sind, müsste bei einem Export geprüft werden wie die ggf. vorhandene Struktur aussieht und alle IDs angepasst werden. Möglich wäre aber bei den IDs auf einen Hashwert zu wechseln, wie das z.B bei Oxid-Shop gemacht wird.

---

Da haste recht. Aber schlimm ist das nicht, weil die IDs deiner MMs sich eh nicht ändern dürfen im Nachgang. Sonst sind es andere MMs. (vergleichbar mit z.B. News-Archiven. Sobald da eine andere ID genutzt wird, kannst Du von einem anderen Archiv sprechen)
-> eine Art Synchronisierung geht damit nicht, das stimmt.

Zitat:

---

Zitat von Tim G

Da haste recht. Aber schlimm ist das nicht, weil die IDs deiner MMs sich eh nicht ändern dürfen im Nachgang. Sonst sind es andere MMs. (vergleichbar mit z.B. News-Archiven. Sobald da eine andere ID genutzt wird, kannst Du von einem anderen Archiv sprechen)
-> eine Art Synchronisierung geht damit nicht, das stimmt.

---

=> das würde demnach bedeuten, dass man nur _alle_ MMs als "Komplettpaket" exportieren respektive importieren kann. Wenn ich z.B. einen "Block" MMs habe um Filialen zu managen und einen "Block" MMs für Seminare, wird es schwer nur den Block Seminare zu exportieren bzw. ein vorgefertigtes Set an MMs in eine andere, bestehende MM-Umgebung einzubauen.

ergo: "Alles oder nichts" :-(

Edit: die IDs bei Oxid sind über den Hash eben nicht nur Unique in der einen Umgebung, sondern überall - jede ID (mit gewisser Wahrscheinlichkeit der Hash-Erzeugung) - ist überall eindeutig! Daher wäre ein Umzug kein Problem!!

Ich, für meinen Teil, würde die ganze Import/Export Geschichte nur auf Felder/Attribute auslegen bzw. würde meine Projekte nur daraufhin auslegen.

Das wird ganz schnell eine riesen Baustelle, wenn man ganze MetaModels versucht ineinander und hin-und-her zu importieren etc.
Wenn ich ein MM füttern will per Backend, dann lieber nur mit strikten Werten für die Felder. Wenn ich mir vorstelle wie da ein Redakteur locker CSV Files reinschießen kann, wird mir Angst und Bange.
Sobald da Referenzen, Querverweise etc. auftauchen, würde ich den TabImporter oder so nutzen und mit Hilfe eines eigenem Scripts die Sachen verknüpfen. Wenn da mal was schief läuft, weisste wenigstens, wo du suchen musst bzw. wie man es ausbessern kann. :)

Ich würde mir auch nicht die Mühe machen einen Katalog-Import als allgemeines Tool bereitzustellen. (ich weiss darüber wird nachgedacht). Da gibt es wesentlich wichtigere Baustellen und Features.

Wer nen Katalog umziehen will nach MM kriegt das hin, auch ohne eigenständiges Tool. Am Ende sind es alles Tabellen und so strikt muss man die auch behandeln. :)

Zitat:

---

Zitat von Tim G

Das wird ganz schnell eine riesen Baustelle, wenn man ganze MetaModels versucht ineinander und hin-und-her zu importieren etc.

---

Ich hatte schon mal ein Post speziell zum Export/Import gemacht - genau mit der Anregung wie ich hier den Text http://now.metamodel.me/en/fundraising#exportimport übersetzen und verstehen würde:

Es geht um die Sicherung und Bereitstellung des gesamten Modells (in meinem Sinne der Modell-Gruppe). Z.B. wenn jemand eine schicke Fahrzeugverwaltung oder Kundenkartei gebaut hat und das Modell als Struktur ohne Daten anderen zur Verfügung stellen möchte. Man muss ja nicht alles 2x erfinden...

Ich bin der Meinung, damit würde sich die Verbreitung und der Einsatz der MMs stark erhöhen!

Zitat:

---

Zitat von Tim G

Wenn ich ein MM füttern will per Backend, dann lieber nur mit strikten Werten für die Felder.

---

Der Import/Export der Werte würde ich sicher auch nur als "Backup" + "Re-Import" ansehen und nicht zum Transfer zwischen verschiedenen Installationen

Zitat:

---

Zitat von zonky

Ich hatte schon mal ein Post speziell zum Export/Import gemacht - genau mit der Anregung wie ich hier den Text http://now.metamodel.me/en/fundraising#exportimport übersetzen und verstehen würde:

Es geht um die Sicherung und Bereitstellung des gesamten Modells (in meinem Sinne der Modell-Gruppe). Z.B. wenn jemand eine schicke Fahrzeugverwaltung oder Kundenkartei gebaut hat und das Modell als Struktur ohne Daten anderen zur Verfügung stellen möchte. Man muss ja nicht alles 2x erfinden...

Ich bin der Meinung, damit würde sich die Verbreitung und der Einsatz der MMs stark erhöhen!




Der Import/Export der Werte würde ich sicher auch nur als "Backup" + "Re-Import" ansehen und nicht zum Transfer zwischen verschiedenen Installationen

---

Erstell nen Installations-Template und fertig. So wie es der webshop seiner Zeit gemacht hat.

Zitat:

---

Zitat von Tim G

Erstell nen Installations-Template und fertig. So wie es der webshop seiner Zeit gemacht hat.

---

o.k. - das wäre dann die "Highlander-Variante": es kann nur Einen geben...