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.
TipTop
Beiträge: 193
Registriert: 25.08.2011, 22:37:08
Wohnort: Klagenfurt, Österreich
Kontaktdaten:

Re: WebRex - Open Source CMS

Beitrag von TipTop » 15.12.2011, 09:29:37

Ja, danke, das klappt. In der Doku stoße ich öfters auf TagLib-Attribute die mit eckigen Klammern eingeklammert sind. Was genau hat das zu bedeuten? Sind das optionale oder veraltete Attribute? In der Formular-Doku wird das button-Attribut für die verschiedenen Textfelder gar nicht angeführt - gibt es dieses überhaupt noch? Falls nicht, könnte man vielleicht mal das Kontakt-Tutorial ein wenig überarbeiten und diese Attribute entfernen -> http://adventure-php-framework.org/Seit ... 2-formular

Grüße


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

Re: WebRex - Open Source CMS

Beitrag von dr.e. » 15.12.2011, 09:48:31

Falls nicht, könnte man vielleicht mal das Kontakt-Tutorial ein wenig überarbeiten und diese Attribute entfernen -> http://adventure-php-framework.org/Seit ... 2-formular
Das wird in Zukunft passieren. Aktuell steht dort jedoch bereits der Hinweis, dass das Tutorial nicht für die aktuelle Version gilt. Am Besten orientierst du dich am verlinkten Tutorial im Wiki und dem Code des Moduls selbst.
Viele Grüße,
Christian

jprangenberg
Beiträge: 410
Registriert: 16.08.2010, 22:14:54

Re: WebRex - Open Source CMS

Beitrag von jprangenberg » 15.12.2011, 10:21:12

Ich wäre dafür, dass wir die Dokumentation entweder komplett ins Wiki heben, oder komplett auf die Seite. So ein mischmasch finde ich nicht besonders toll. Man sucht erst auf der Webseite - findet nichts - und erhofft das es im Wiki ist. Ich bitte darum das Thema Dokumentation komplett zu überdenken.

I'm sorry for offtopic! :-)

Benutzeravatar
ma2604121
Beiträge: 349
Registriert: 24.01.2011, 23:42:18

Re: WebRex - Open Source CMS

Beitrag von ma2604121 » 15.12.2011, 11:37:15

Muss mich auch noch kurz einklinken. Das wurde schon einmal thematisiert: viewtopic.php?f=1&t=815

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

Re: WebRex - Open Source CMS

Beitrag von TipTop » 15.12.2011, 13:52:23

Ich versuche gerade anhand des Kommentar-Funktion-Tutorials die erste Komponente meines CMS zu vervollständigen. Um was handet es sich bei der Klasse commenBaseController? Beide Dokument Controller werden von dieser Klasse abgeleitet, allerdings wird diese im Tutorial nicht definiert? Christian, kannst Du den Code dieser Klasse vielleicht noch ins Tut aufnehmen? Oder zumindest ein UML Diagramm?

Grüße,
Nico

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

Re: WebRex - Open Source CMS

Beitrag von Megger » 15.12.2011, 14:01:55

Da diese Funktion in beiden Document-Controllern (Erzeugen der Liste, Eintragen eines Kommentars) genutzt wird, findet sich diese Funktion in einmn gemeinsamen Basis-Document-Controller wieder. Dieser wird in der Datei /apps/modules/coments/pres/documentcontroller/commentBaseController.php abgelegt und trägt den Namen commentBaseController.
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

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

Re: WebRex - Open Source CMS

Beitrag von dr.e. » 15.12.2011, 22:42:34

@Nico: ist mit Tobi's Post deine Frage beantwortet?

@all: ich habe verstanden, dass das Thema Doku nicht schön ist, nur aktuell sehe ich das Wiki immer noch als Ergänzung zur "offiziellen" Doku. Wer mithelfen möchte, kann entweder im SVN neue Inhalte hinzufügen oder im Wiki schreiben. Sofern es Themen gibt, die behoben werden müssen, lade ich zur Mithilfe ein. Alleine ist es immer etwas schwierig viele Dinge gleichzeitig zu tun. Im verlinkten Thread hatte ich ja bereits aufgerufen, Missstände zu benennen, damit wir kurzfristig entscheiden können, wie wir diese beheben. Dies möchte ich auch jetzt nochmal bekräftigen.

Aus meiner Sicht sind folgende Themen offen:
  • Kontakt-Formular-Tutorial bzw. alle veralteten Tutorials updaten
  • UMGT-Doku schreiben
  • Wiki nach unvollständigen Inhalten durchsuchen und ergänzen
Mit dem zweiten Punkt beschäftige ich mich aktuell und hatte zum ersten Punkt bereits im 1.14er Release einige Arbeiten abgeschlossen. Sofern jemand aktuell etwas Zeit mitbringt (ich weiß, jeder hat viel am Hut), bitte ich um Mithilfe für die beiden Punkte. Nur wenn mehrere mit anpacken, wird sich der Zustand nachhaltig bessern.

Ich möchte nicht den Eindruck erwecken, dass ich mich des Themas nicht annehmen möchte, jedoch ist das Tool nicht Schuld an falschen oder veralteten Inhalten.
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 » 30.12.2011, 11:50:09

Was mich derzeit interessiert: wo seht Ihr die Vor- & Nachteile bei einem einfachen Command-Object (wie Documentcontroller im APF) und einem Action-Cotroller (wie in Zend-FW)? Die Action-Controller kann man in Aktionen unterteilen. Den Vorteil den ich hier sehe: Ich habe zwei oder mehrere verschiedene Aktionen, welche aber mit dem ein und den Selben View-Script/Template verbunden sein können. Wenn ich jetzt die Layout-Komponente meines CMS hernehme, dann hab ich da unteranderem eine Liste mit allen installierten Layouts. Nun können diese Layouts deinstalliert werden - dafür ist in einer Spalte in der Tabelle, wo die Layouts aufgelistet sind, ein Lösch-Link. Dieser verweist z.B. auf eine deleteAction vom Action-Controller. Dadurch wird beim klicken des Links diese Action/Methode ausgeführt. In der deleteAction-Methode kann ich am Ende die Action aufrufen, die für das Anzeigen der Layouts verantwortlich ist.
Wie würde man Dies am geschicktesten im APF lösen? Ich könnte in der transformContent() prüfen, ob zB ein task/action-Parameter übergeben wurde. Ist das der Fall und beträgt dessen Value "delete", so rufe ich in der transformContent()-Methode eine delete-Methode von einem LayoutManager (biz) auf, der sich dann um den Rest kümmert. Nur muss ich bei dieser Variante eben prüfen, ob ein task-Parameter übergeben wird und in meinem CMS wären das ein Haufen von tasks. Gibts da eventuell eine dynamischere Variante? Also so ähnlich wie beim Action-Controller, wo man über die URL eine Task/Action-Methode aufrufen kann?

Grüße
Nico

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

Re: WebRex - Open Source CMS

Beitrag von dr.e. » 30.12.2011, 20:59:50

Hallo Nico,
Was mich derzeit interessiert: wo seht Ihr die Vor- & Nachteile bei einem einfachen Command-Object (wie Documentcontroller im APF) und einem Action-Cotroller (wie in Zend-FW)?
Der Unterschied liegt für mich zunächst in den Möglichkeiten der Frameworks selbst. Das ZF kennt beispielsweise kein HMVC und muss sich daher mit den Möglichkeiten von einem einfachen MVC begnügen. Dort gibt es sicher Workarounds oder Vorgehensweise, die ebenso zum Ziel führen, jedoch - aus meiner Sicht und Erfahrung - nicht so elegant und flexibel. Das ist wie ein Gelände-Parkours, den ich mit einem Hummer und mit einem Porsche 911er fahren soll. Mit dem Porsche geht das sicher auch irgendwie, mit dem Hummer aber deutlich eleganter und vor allem Unfall-freier.

Zurück zum konkreten Problem: mit dem APF hast du sowohl die Mechanismen, um eine statisches MVC zu implementieren als auch ein mehrschichtiges, dynamisches Modell. Vorteil eines statischen Modells ist, dass die Implementierung sehr schnell verstanden ist - mit den wenigen Freiheitsgraden ist das auch kein Problem. Nachteil ist ganz klar die Beschränkung auf einen Controller, keine Möglichkeit zur generischen und wiederverwendbaren Gestaltung von Modulen etc. Hierzu hatte ich kürzlich unter http://www.php.de/php-fortgeschrittene/ ... post639003 einige Beiträge zu MVC vs. HMVC verfasst, die dir sicher einige Antworten geben kann. Sofern nicht, sag einfach Bescheid.
Wie würde man Dies am geschicktesten im APF lösen?
Die Frage ist doch, welche Module/Bereiche/Komponenten du in deiner Admin-UI anbieten möchtest. Hierzu gehören sicher die Ansicht für die Verwaltung von Layout-Komponenten, eine "Seite" für die Verwaltung von Seiten, Komponenten, Navigationsknoten u.s.w. Für alle diese - und vor allem für deren Unter-Funktionalitäten - schneidest du eigene HMVC-Elemente. Diese bilden jeweils die Funktionalitäten an, de der aktuelle View wirklich braucht. Sofern du von Use Cases ausgehst, kannst du mit dem APF für jeden Use Case eine View erzeugen und dich an Hand dieser durch die Implementierung hangeln. Hierzu kann ich dir das Dokument http://media.adventure-php-framework.or ... arbeit.pdf ans Herz legen. Dort beschreibe ich die Vorgehensweise für den Entwurf einer Anwendung basierend auf einer detaillierten Anforderungsanalyse.
Den Vorteil den ich hier sehe: Ich habe zwei oder mehrere verschiedene Aktionen, welche aber mit dem ein und den Selben View-Script/Template verbunden sein können. Wenn ich jetzt die Layout-Komponente meines CMS hernehme, dann hab ich da unteranderem eine Liste mit allen installierten Layouts. Nun können diese Layouts deinstalliert werden - dafür ist in einer Spalte in der Tabelle, wo die Layouts aufgelistet sind, ein Lösch-Link. Dieser verweist z.B. auf eine deleteAction vom Action-Controller. Dadurch wird beim klicken des Links diese Action/Methode ausgeführt. In der deleteAction-Methode kann ich am Ende die Action aufrufen, die für das Anzeigen der Layouts verantwortlich ist.
Setzt du HMVC ein, ist die Philosophie etwas anders: du setzt nicht auf Multi-Action-MVC-Controller sondern auf mehrfache Single-Action-MVC-Controller. Das bedeutet, dass du die Funktionen (z.B. show, delete, ...) jeweils auf mehrere Controller verteilst und die gemeinsame Logik entweder in einen Basis-Controller auslagerst oder einen gemeinsamen Service nutzt, der die eigentliche Business- und Peristenz-Logik ausführt. Hast du gemeinsame Template-Elemente, so lagerst du diese einfach zur gemeinsamen Nutzung aus und importierst diese per <core:appendnode /> an der richtigen Stelle.

Wenn du diese Denkweise nicht anwenden möchtest, kannst du dir mit einem generischen Document-Controller behelfen, der Multi-Actions einfach auf Basis eines Url-Parameters ermöglicht. Effektiv bedeutet dies jedoch weiterehin eine Einschränkung deiner Freiheiten was den Schnitt der Komponenten angeht. HMVC hat u.a. den Vorteil, dass du Komponenten deutlich natürlicher schneiden kannst und Funktionalitäten innerhalb einer Klasse tatsächlich nur einem Use Case bzw. Business-Prozess zugehörig sind. Je mehr Funktionalität in einem Controller steckt - das mag zunächst ja charmant klingen - desto weniger genügt es dem OO-Ansatz (siehe "single responsibility"-Prinzip).
Ich könnte in der transformContent() prüfen, ob zB ein task/action-Parameter übergeben wurde. Ist das der Fall und beträgt dessen Value "delete", so rufe ich in der transformContent()-Methode eine delete-Methode von einem LayoutManager (biz) auf, der sich dann um den Rest kümmert. Nur muss ich bei dieser Variante eben prüfen, ob ein task-Parameter übergeben wird und in meinem CMS wären das ein Haufen von tasks. Gibts da eventuell eine dynamischere Variante? Also so ähnlich wie beim Action-Controller, wo man über die URL eine Task/Action-Methode aufrufen kann?
Wie oben beschrieben kannst du das schon so implementieren, jedoch geht dir dabei ein Stück Flexibilität verloren, da du nur einen Action-Controller hast und nicht beliebig viele Front-Controller-Actions und Document-Controller.

Kannst du mal ein konkretes Beispiel geben, dann kann ich dir auch einen konkreten Vorschlag unterbreiten, wie ich es mit Hilfe des APF implementieren würde?
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 » 30.12.2011, 22:52:24

Kannst du mal ein konkretes Beispiel geben
Im Prinzip wäre das Beispiel mit dem Löschen von Layouts schon konkret genug.

http://www.webrex.org/test/acp/
Bentuzername: Admin
Passowrt: demo

Dann auf Layouts - dort ist die Übersicht der installierten Layouts. Auf was sollen die Lösch-Links verweisen? index.php?component=layouts&page=deleteLayout wäre ne Möglichkeit - den dazugehörigen Controller dann damit beauftragen, das Layout zu löschen. Aber ne Front-Controll-Action wäre da eher angebracht, oder, würde ja auch etwas Code sparen?

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

Re: WebRex - Open Source CMS

Beitrag von dr.e. » 31.12.2011, 11:55:58

Hallo Nico,

habe mir das Demo ACP angesehen, daher ganz konkret die Antworten auf deine Fragen:
Dann auf Layouts - dort ist die Übersicht der installierten Layouts. Auf was sollen die Lösch-Links verweisen?
Hinsichtlich der Url ist das egal, im Sinne der Struktur entweder auf die Layout-Komponente selbst mit einem entsprechenden Action/Page-Parameter oder auf einen anderen Bereich mit Hilfe eines ebenso gearteten Url-Parameters. Damit kannst du die o.g. Vorgehensweise entsprechend abbilden. Hier kommt es allerdings noch darauf an, ob die GUI mit fancy stuff ausgestattet werden soll und bsp. per AJAX ein Löschen getriggert werden soll. Ich gehe im Weiteren mal davon aus, dass es keine AJAX-Requests geben soll.

Ich gehe nochmal näher auf das hierarchische Modell an Hand dieses Beispiels ein, da ich noch nicht den Eindruck habe, dass das Modell bei dir angekommen ist (kann natürlich auch an mir liegen). Da du zwei Url-Parameter verwendest, können diese dazu genutzt werden, unterschiedliche Hierarchien zu steuern. Der erste (component) liefert dir eine Entscheidung, welcher Haupt-Inhalt angezeigt wird, der zweite, welche Aktion und damit welcher Controller genutzt wird. Ich zeichne das mal auf:

Code: Alles auswählen

# Root (Haupt-Template, das den Rahmen vorgibt)
## Header (statisch im Haupt-Template eingebunden)
## Navigation (statisch im Haupt-Template eingebunden, allerdings mit eigenem Controller für dynamische Anzeige)
## Content-Bereich (dynamisch mit Hilfe des Url-Parameters "component" eingebunden)
### Header des Layout-Bereichs (statisch in der Layout-Komponente eingebunden, allerdings mit eigenem Controller für dynamische Anzeige von z.B. Benutzer-abhängigen Aktionen)
### Content der Layout Komponente (dynamisch mit Hilfe des Url-Parameters "page"/"action" eingebunden)
### Footer des Layout-Bereichs (statisch in der Layout-Komponente eingebunden)
## Footer (statisch im Haupt-Template eingebunden)
So kannst du sehr flexibel auf den unterschiedlichen Ebenen - es könnte ausgehend von Ebene 3 auch eine Ebene 4 geben - die Ausgaben steuern. Hierzu braucht du dann nicht alles in einen Controller zu implementieren, sondern kannst jede Komponente einzeln und separat abfassen und zum Schluss in dein ACP integrieren. Du könntest sie sogar alleine laufen lassen, wenn du magst.
index.php?component=layouts&page=deleteLayout wäre ne Möglichkeit - den dazugehörigen Controller dann damit beauftragen, das Layout zu löschen. Aber ne Front-Controll-Action wäre da eher angebracht, oder, würde ja auch etwas Code sparen?
Ich würde hier einen MVC-Document-Controller erstellen, der den Request entgegen nimmt, vielleicht noch eine Sicherheits-Abfrage anzeigt und dann die Löschung vornimmt. Dies ist in sich eine abgeschlossene Aktion, die einen eigen Controller und ein eigenes Template (nicht zwingendermaßen) rechtfertig. Eine Front-Controller-Action würde ich nicht schreiben, da du ja u.U. eine Sicherheitsabfrage platzieren möchtest. Diese ist View-bezogen und damit Aufgabe eines Document-Controllers.

Technisch gesehen könntest auch eine FC-Action schreiben, die einfach ohne zu Fragen die Löschung vornimmt und dann die Seite selbst wieder anzeigt. Die Url hierzu wäre dann beispielsweise

Code: Alles auswählen

index.php?component=layouts&webrex_cms_components-action:deleteLayout=id:5
Wichtig bei der ganzen Diskussion ist mir, dass der Unterschied zwischen einem klassischen MVC-Ansatz und dem Funktionsumfang des APF ankommt. Mit dem APF hast du eine ganze Menge an Mehr-Möglichkeiten, die du klassisch oder so wie sie gedacht sind benutzen kannst. Bei letzteren ist vielleicht etwas Umdenken notwendig, aber es lohnt sich.

Noch ein Wort zu Url-Generierung: da das APF hierzu eine Url-Abstraktion mitliefert, die die meisten Anwendungsfälle abdeckt, kannst du die Separation der Komponenten sogar auf Url-Ebene weitertreiben. Keine der Komponenten muss Parameter der anderen kennen. Du kannst einfach per

Code: Alles auswählen

Url::fromCurrent() 
die aktuelle Url erzeugen lassen und anschließend die Parameter "deines" Moduls dort hinein mappen. Damit bleiben alle anderen bestehen und die Komponenten funktionieren zusammen auf einer Seite.
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 » 31.12.2011, 13:40:18

Erstmal werde ich den page Parameter in option umbenennen, das wirkt sich zwar nicht auf die Funktionalität aus, aber page wäre bei deleteLayout oder deleteModul ein etwas unlogischer Bezeichner.

Nun zum Aufbau (korrigiere mich falls ich was falsch verstanden hab):

Ich erstelle ein neues Template auf den Namen deleteLayout.html, in welches ich mittels <core:importdesign /> (sollte doch genügen, oder aus welchen Gründen würde ich hier appendnode benötigen?) das layouts.html-Template einbinde, welches ja nach dem Löschen des Layouts angezeigt werden soll. Zudem erhält deleteLayout.html noch einen Document-Controller, der dann die biz-Schicht kontaktiert, welche wiederum über einen Data Mapper das Layout löschen kann. Ist die Reihenfogle der Schritte korrekt?

Grüße,
Nico

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

Re: WebRex - Open Source CMS

Beitrag von dr.e. » 31.12.2011, 14:39:48

Soweit korrekt. Beim <core:appendnode /> ging es mir mehr um die Auslagerung von gleichen View-Elementen (z.B. einen Iterator oder ein Template), nicht um den Aufbau der Views allgemein. Hier reicht - wie du schon sagst - ein <core:importdesign /> mit inparam-Option absolut aus.
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 » 08.01.2012, 15:47:34

Ich überlege derzeit wie man am Besten folgendes umsetzten kann:

Tritt ein bestimmer fall ein, soll eine Tabellen-Zeile mit 2 Spalten ausgegeben werden, also:

Code: Alles auswählen

<tr><td>Foo</td> <td>Bar</td></tr> 
Die Frage ist, wo überprüfe ich diesen Fall? Mit sind da 2 Möglichkeiten bekannt:

1. neuen TagLib erstellen
2. im Document-Controller den HTML-Code durch einen Platzhalter ersetzen

1. ist doch etwas aufwendig, wenn man bedenkt, dass nur ein Zeile Code ausgegeben werden soll. Und 2. - naja, HTML Code Im Controller, auch nicht das Wahre ;)
Was wäre denn hier die "richtige" Lösung?

Grüße,
Nico

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast