WebRex - Open Source CMS

Im Entwickler-Forum können Implementierungsdetails sowie Alternativen der Umsetzung diskutiert werden. // Here, developers can discuss implementation details of features of their projects.
sammy8806
Beiträge: 13
Registriert: 22.07.2011, 20:18:58
Wohnort: Lemmitown
Kontaktdaten:

Re: WebRex - Open Source CMS

Beitrag von sammy8806 » 31.03.2012, 00:24:55

dave hat geschrieben:[...] Jeder hat eben so seine eigene Vorgehensweise.
Finde ich auch ;-)

Aber ansonsten habe ich es auch schon gesehen, dass in Klammern dahinter (oder direkt) entweder der Name der Sprache in der von dir ausgewählten Sprache steht oder aus englischer Sicht, also

Code: Alles auswählen

Deutsch (German)
Grüße
Steven

TipTop
Beiträge: 193
Registriert: 25.08.2011, 22:37:08
Wohnort: Klagenfurt, Österreich
Kontaktdaten:

Re: WebRex - Open Source CMS

Beitrag von TipTop » 29.07.2012, 18:19:21

Ich suche derzeit einen Namen für eine Klasse. Diese Klasse muss folgendes interface implementieren (wobei auch der Name des Interfaces von dem Namen der Klasse abhängt):

Code: Alles auswählen

interface i<Name-der-Klasse> {
    public function install();
    public function uninstall();
    public function add($moduleID);
    public function remove($moduleID);
} 
Diese Klasse muss in jedem Modul, welches man im CMS installieren möchte, vorhanden sein. Die install()-Methode wird aufgerufen, nachdem Modul-Daten in der Datenbank gespeichert wurden. Die install() Methode könnte man nun bspw. dazu nutzen, um in der Pager-Konfiguration einen Bereich fürs Modul zu erstellen oder um die Konfigurations-Dateien des GORMS um eigene Domain-Objekte zu erweitern. Die uninstall() Methode ist logischerweise da, um Dinge, die man in der install()-Methode erstellt hat, wieder zu entfernen. add() wird immer dann aufgerufen, wenn eine neue Instanz eines Moduls erstellt wurde und remove() wenn eine Modul-Instanz gelöscht wurde. Wenn Ihr schonmal für Joomla! oder WebsiteBaker ein Modul erstellt habt, seid ihr mit dieser bzw. einer ähnlichen API sicher vertraut.

Nun suche ich jedenfalls einen Namen für diese Klasse und wäre dankbar für Vorschläge. :)
Mir ist bisher iModuleHandler und ModuleHandler in den Sinn gekommen, nur bin ich mir unsicher, ob diese Bezeichnung semantisch korrekt ist.

Grüße
Nico

Benutzeravatar
dr.e.
Administrator
Beiträge: 4527
Registriert: 04.11.2007, 16:13:53

Re: WebRex - Open Source CMS

Beitrag von dr.e. » 29.07.2012, 19:48:17

Nachdem es sich um ein Modul handelt, sollte diese Tatsache schon mal im Namen berücksichtigt werden. Hinsichtlich eines konkreten Namens bin ich mir noch nicht ganz sicher, da die ersten beiden Methoden auf "ModuleConfiguration" oder "ModuleInstaller" hinweisen, die beiden letzten eher in die Richtung einer Persistenz-Implementierung wie "ModulePersistence" oder "ModuleManager" deuten.

Ich vermute daher, dass die Schwierigkeit einen Namen zu finden genau darin begründet ist, das hier mehrere Bereiche vermischt werden.
Viele Grüße,
Christian

Megger
Beiträge: 1233
Registriert: 04.11.2008, 10:57:37

Re: WebRex - Open Source CMS

Beitrag von Megger » 29.07.2012, 20:18:56

Für mich ist es einfach ein ModulInterface! Simpel und doch aussagekräftig!
ModuleConfiguration
Es ist ja keine Konfiguration oder etwas was auch die Konfiguration zugreift, es könnte auf die Konfiguration zugreifen
ModuleInstaller
Es installiert meiner Meinung nach auch keine Module, der ModuleInstaller prüft eher, ob das zu installierende Modul vom diesem Interface abhängt
ModulePersistence
Ist es meiner Meinung nach auch nicht, denn es ist nicht dafür verantwortlich die Module bekannt zu machen bzw. die bekannten Module zu speichern
ModuleManager
Es werden meiner Meinung nach auch keine Module "gemanaged", sondern nur vorgegeben, was die entsprechenden Module berücksichtigen müssen

Deswegen passt meiner Meinung nach am besten ein simples ModulInterface, dass sagt eigentlich alles aus was es aussagen soll!
Tutorial: Browsergame mit dem APF (Die ersten Parts handeln von Installation und Inbetriebnahme des APFs, deswegen sicherlich auch für alle Nicht-Browsergame-Programmierer interessant)

APF-Version
  • Entwicklung: 2.0
  • Produktiv: 1.15

TipTop
Beiträge: 193
Registriert: 25.08.2011, 22:37:08
Wohnort: Klagenfurt, Österreich
Kontaktdaten:

Re: WebRex - Open Source CMS

Beitrag von TipTop » 29.07.2012, 20:42:55

Deswegen passt meiner Meinung nach am besten ein simples ModulInterface, dass sagt eigentlich alles aus was es aussagen soll!
Perfekt. Danke. :)

Benutzeravatar
dr.e.
Administrator
Beiträge: 4527
Registriert: 04.11.2007, 16:13:53

Re: WebRex - Open Source CMS

Beitrag von dr.e. » 29.07.2012, 21:45:58

Da kann ich mitgehen. :D
Viele Grüße,
Christian

TipTop
Beiträge: 193
Registriert: 25.08.2011, 22:37:08
Wohnort: Klagenfurt, Österreich
Kontaktdaten:

Re: WebRex - Open Source CMS

Beitrag von TipTop » 03.08.2012, 10:56:49

So sieht momentan die DB-Struktur aus: http://www.webrex.org/webrex.jpg

Rechts oben im Bild sieht man die Entität PageNode. Diese hat es vorher nicht gegeben - deren Spalten waren in der ent_page-Tabelle zu finden, nun habe ich Sie in eine seperate Tabelle ausgelagert und mit den Page-Entitäten in eine Verbindung gebracht. In ent_pagenode wird die Hierarchie der Seiten abgebildet - in ent_page befinden sich allerdings Daten wie Menu-Title. Für das Menü-Modul muss ich nun zum einen die Seiten-Hierarchie abfragen (das klappt problemlos - hab eine kleine Nested-Sets Klasse geschrieben, die den GORM verwendet), zum anderen muss ich nun aber zu jeder PageNode-Entität die dazugehörige Page-Entität abfragen, damit ich eben an Daten wie Menu-Title kommen. Jetzt könnte ich bei jedem PageNode-Objekt loadRelatedObject('PageNode2Page') anwenden, wodurch aber pro Menü-Link ein DB-Query gesendet wird -> No Go. Ich werde für das Menü daher erstmal auf ein selbstgebautes SQL-Statement setzen, damit ich Seitestruktur inklusive Seitendaten auch in einem einzigen Query abfragen kann.

Vielleicht könnte man aber den GORM um eine Methode erweitern, mit welcher man zu einem Objekt / zu einer Objekt Liste in Beziehung stehende Objekte abfragen kann!?

Irgendwas in diese Richtung:

Code: Alles auswählen

<?php
$myObjectList = $gorm->loadObjectListWithRelatedObjects('MyObject', 'MyObject2AnotherObject');

foreach ($myObjectList as $myObject) {
    $anotherObject = $myObject->getRelatedObjects('MyObject2AnotherObject');
} 
In loadObjectListWithRelatedObjects() sollte dann in einem enzigen Query mittels Join die in Beziehung stehenden Objekte mitabgefragt und über addRelatedObject() den "Haup"-Objekten übergeben werden.


Grüße
Nico

Benutzeravatar
dr.e.
Administrator
Beiträge: 4527
Registriert: 04.11.2007, 16:13:53

Re: WebRex - Open Source CMS

Beitrag von dr.e. » 03.08.2012, 20:02:40

Hi Nico,

das ist mit dem GORM prinzipiell möglich. Vielleicht könnte man diese Parametrisierung sorag mit dem GenericCreterionObject abdecken. Magst du dich mal dran versuchen?
Viele Grüße,
Christian

TipTop
Beiträge: 193
Registriert: 25.08.2011, 22:37:08
Wohnort: Klagenfurt, Österreich
Kontaktdaten:

Re: WebRex - Open Source CMS

Beitrag von TipTop » 05.08.2012, 13:32:43

Hallo Christian,
dr.e. hat geschrieben:Hi Nico,

das ist mit dem GORM prinzipiell möglich. Vielleicht könnte man diese Parametrisierung sorag mit dem GenericCreterionObject abdecken. Magst du dich mal dran versuchen?
Ich müsste eine Abfrage bilden können, die ca. so aufgebaut ist:

Code: Alles auswählen

  SELECT pn.*,
         p.PageID, 
         p.PageTitle, 
         p.MenuTitle, 
         p.ShowInMenu 
    FROM ent_pagenode AS pn,
         ent_page AS p,
         ent_language AS l,
         ass_pagenode2page AS pn2p,
         ass_language2page AS l2p
   WHERE pn2p.Source_PageNodeID = pn.PageNodeID
     AND pn2p.Target_PageID = p.PageID
     AND pn.Lft < $LFT_OF_ROOT_NODE
     AND pn.Rgt < $RGT_OF_ROOT_NODE
     AND pn.Level >= $END_LEVEL
     AND l2p.Source_LanguageID = l.LanguageID
     AND l2p.Target_PageID = p.PageID
     AND l.IsoCode = 'de'
ORDER BY pn.Lft;
Ich muss also zu jeder Page-Node-Entität eine Page-Entität abfragen, die mit der aktuellen Language-Entität in Beziehung steht. Ich denke kaum, dass sich das mit dem GORM - ohne große Änderungen am bestehenden Code - umsetzen lässt, oder?


Grüße
Nico

Benutzeravatar
dr.e.
Administrator
Beiträge: 4527
Registriert: 04.11.2007, 16:13:53

Re: WebRex - Open Source CMS

Beitrag von dr.e. » 07.08.2012, 22:25:53

Hi Nico,

auf den ersten Blick ist das vermutlich nicht ohne Weiteres möglich, da der GORM nicht dafür designed wurde, direkt weitere Objekte nachzuladen. Allerdings ist es mit dem Domänen-Objekt-Feature möglich ist, dieses Verhalten zumindest durch eine Implementierung eines oder mehrere DO's zu mimen.

Eine weitere Möglichkeit ist das Baum-Objekt-Feature. Hast du dir das schon angesehen?
Viele Grüße,
Christian

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast