WebRex CMS

Dieser Bereich dient dazu, eure Tricks und Erweiterungen vorzustellen, damit diese auch andere Anwender nutzen können. // This area can be used to publish your tricks and extensions to the APF to be used by other developers.
darksider3
Beiträge: 1
Registriert: 18.02.2012, 00:45:40

Re: WebRex CMS

Beitrag von darksider3 » 18.02.2012, 00:54:09

Was ist jetzt mit diesem CMS?
Projekt abgebrochen, oder wird noch entwickelt?

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

Re: WebRex CMS

Beitrag von TipTop » 18.02.2012, 10:14:15

Nein, es wird noch entwickelt. Dauert nur alles etwas lange, da ich nebenbei noch ein 2., größeres Projekt mit APF und Dojo umsetze.

Grüße
Nico

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

Re: WebRex CMS

Beitrag von TipTop » 11.03.2012, 12:47:29

Ich bin gerade dabei, die Modul-Komponente des CMS umzusetzen. Ein Modul für WebRex kann nach aktuellen Stand folgend aussehen:
  • config
  • backend
    • pres
      • css
      • images
      • templates
      • documentcontrollers
    • data
    • biz
  • frontend
    • pres
      • css
      • images
      • templates
        • main.html
      • documentcontrollers
    • data
    • biz
  • moduleDatas.xml
Die Ordner frontend und backend sowie deren Unterordner können beliebig viele Dateien beinhalten.

Die oben gezeigt Verzeichnisstruktur muss aber nicht jedes Modul erfüllen. Der minimalste Aufbau eines Moduls sieht so aus:
  • frontend
    • pres
      • templates
        • main.html
  • moduleDatas.xml
Die moduleDatas.xml sieht momenat z.B. so aus:

Code: Alles auswählen

<?xml version="1.0" encoding="UTF-8"?>
<module>
    <name>Gästebuch</name>
    <author>Nicolas Pecher</author>
    <version>1.0.0</version>
    <description>Ein Gästebuchmodul für das WebRex-CMS</description>
    <foldername>guestbook</foldername>
    <multipleusage>true</multipleusage>
</module>
Der multipleusage-Tag sagt dabei aus, ob ein Modul auf einer Seite mehrfach verwendet werden darf. Mit Seite meine ich aber nicht die gesamte Website, sondern nur eine Seite der Website. Enthält der multipleusage-Tag den Wert false, kann das Modul auf einer Website beliebig oft verwendet werden, auf einer Seite allerdings maximal einmal.

Installiere ich das Modul mit der oben stehenden moduleDatas.xml, dann wird in wwwroot/apps/webrex/modules ein Verzeichnis namens guestbook angelegt. Dort werden dann die Verzeichnisse backend und frontend der Modul-ZIP-Datei hineingeladen. Wichtig ist, dass der foldername, in dem das Modul landet, vom Entwickler über die moduleDatas.xml bestimmt werden kann - würde der foldername nämlich vom CMS generiert werden, würden wahrscheinlich die namespace-Angaben in den Modul-Dateien nicht mehr passen und das Modul wäre damit fehlerhaft.

In der minmalen Verzeichnisstruktur eines Moduls sieht man, dass das backend Verzeichnis nicht umbedingt notwendig ist - das heißt aber nicht, dass das Modul nicht über eine Admin-GUI verfügen kann. In der ersten Verzeichnisstruktur hab ich ein Verzeichnis namens config angeführt. Dieses kann über 2 optionale Dateien verfügen:
- module_config.ini
- content_vars.ini

Werden diese beiden Dateien eines Modules vom System gefunden, werden in der Admin-GUI des Moduls zwei Menüpunkt generiert, über die man die Inhalt dieser .ini-Dateien modifizieren kann.



Nun muss ich noch für ein Problem eine Lösung finden. Ich möchte, dass WebRex-Module die Funktionalität der APF-Module nutzen (können). Die APF-Module benötigen ja so gut wie immer eine Konfigurationsdatei. Möchte ich in einem Gästebuch-Modul also bspw. den GORM und den Pager verwenden, dann muss ich für die beiden Module auch i-wie ne Config mitliefern. Ich habe dabei an folgendes gedacht:

Im Verzeichnis config des Moduls können beliebig viele config Dateien angelegt werden. Will ich in meinen Modul den GORM verwenden, dann pack ich also DEFAULT_{nameaffix}_objects.ini und DEFAULT_{nameaffix}_relations.ini in den config-Ordner rein. Damit diese beiden Dateien auch mit hochgeladen werden, muss im config-Ordner des Moduls eine weitere Datei vorhanden sein -> service_configs.ini

Wenn ich jetzt beim Beispiel mit dem GORM bleibe, sollte die service_configs.ini folgendermaßen aussehen:

Code: Alles auswählen

[ServiceConfigs]
source.gorm.objects = "config/gorm/DEFAULT_guestbook_objects.ini"
target.gorm.objects = "irgendwo"

source.gorm.relations = "config/gorm/DEFAULT_guestbook_relations.ini"
target.gorm.relations = "irgendwo" 
Die Verzeichnisstruktur des Moduls müsste nun mind. so aufgebaut sein:
  • config
    • service_configs.ini
    • gorm
      • DEFAULT_guestbook_objects.ini
      • DEFAULT_guestbook_relations.ini
  • frontend
    • pres
      • templates
        • main.html
  • moduleDatas.xml

Die beiden config Datein in config/gorm würden nach der Installation des Moduls so erreichbar sein:

wwwroot/apps/config/irgendwo/webrex/DEFAULT_guestbook_objects.ini
wwwroot/apps/config/irgendwo/webrex/DEFAULT_guestbook_relations.ini

Das Verzeichnis webrex kommt wegen dem Context zustande.
Mit diesem Lösungsansatz könnte man jedes APF-Modul konfigurieren und somit auch nutzen - nur bin ich mir nicht sicher, ob dass die optimale Lösung ist. Hättet Ihr noch andere Ideen?

Grüße
Nico

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

Re: WebRex CMS

Beitrag von dr.e. » 11.03.2012, 14:48:18

Hallo Nico,

dein Konzept gefällt mir bisher sehr gut. Was die Konfiguration von APF-Modulen angeht, so kannst du entweder eine Konfiguration direkt in deinem WebRex-Modul-Config-Ordner ablegen und bei der Installation kopieren (wie du es beschrieben hast) oder aber während der Konfiguration die Datei auf Basis der beschriebenen Vorlage mit dem ConfigurationManager dynamisch erzeugen. Beide Varianten sind für mich eine saubere Lösung.

Mit letzterer - also laden der Vorlage über den ConfigurationManager und anschließendes Schreiben der Konfiguration - wäre jedoch ein eigener ConfigurationProvider notwendig, der das Pfad-Layout der Vorlage-Datei kennt. Diese könnte dann man z.B. auf die Endung .webrex-template registrieren und einfach per

Code: Alles auswählen

$template = $this->getConfiguration('...pfad des webrex moduls...', '...webrex-template');
$this->saveConfiguration(...); 
speichern/schreiben.
Viele Grüße,
Christian

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

Re: WebRex CMS

Beitrag von TipTop » 17.03.2012, 13:09:05

dr.e. hat geschrieben:dein Konzept gefällt mir bisher sehr gut.
Danke :oops:


Ich habe mir das nochmal durch den Kopf gehen lassen. Das Konfigurations-Thema werde ich nun wohl so lösen:

Während der Installation eines Moduls, wird in wwwroot/apps/config/webrex/modules ein Verzeichnis erstellt, welches nach dem <foldername>-Tag (moduleDatas.xml) benannt wird. Gib ich in der moduleDatas.xml also <foldername>guestbook</foldername> an, dann wird für das Modul folgendes Config-Verzeichnis angelegt: wwwroot/apps/config/webrex/modules/guestbook

Als nächstes wird überprüft, ob in der Module-ZIP-Datei das config-Verzeichnis vorhanden ist - falls ja, werden alle darin befindlichen Konfigurationsdateien und Verzeichnisse in wwwroot/apps/config/webrex/modules/guestbook reinkopiert.
Besonders für DIServiceManager und GORM ist diese Vorgehenesweise sinnvoll.

Nehemen wir an die Modul-Config-Verzeichnisstruktur sieht folgendermaßen aus:
  • config
    • biz
      • DEFAULT_serviceobjects.ini
    • data
      • DEFAULT_{nameaffix}_objects.ini
      • DEFAULT_{nameaffix}_relations.ini
...dann wird genau diese Verzeichnisstruktur auch in das APF-Config-Verzeichnis integriert:
- wwwroot/apps/config/webrex/modules/guestbook/biz/DEFAULT_serviceobjects.ini
- wwwroot/apps/config/webrex/modules/guestbook/data/DEFAULT_{nameaffix}_objects.ini
- wwwroot/apps/config/webrex/modules/guestbook/data/DEFAULT_{nameaffix}_relations.ini

Die Template- und PHP-Dateien des Moduls liegen in einer sehr ähnlichen Verzeichnisstruktur:
- wwwroot/apps/webrex/modules/guestbook/pres/documentcontroller
- wwwroot/apps/webrex/modules/guestbook/pres/templates
- wwwroot/apps/webrex/modules/guestbook/biz
- wwwroot/apps/webrex/modules/guestbook/data


Gibt es nun Konfigurationsdateien, die aber in einem bestimmten Modul- oder Extension-Config-Verzeichnis untergebracht werden müssen (bspw. Pager-Modul oder News-Extension), besteht die Möglichkeit, im config-Verzeichnis der Module-ZIP-Datei ein Verzeichnis namens movable zu erstellen. In diesem Verzeichnis erwartet das System eine Datei namens DEFAULT_moveable.ini. Möchte ich nun Pager-Modul und News-Extension für ein WebRex-Modul verwenden, sollte die Struktur des config-Verzeichnisses so aussehen:
  • config
    • biz
      • DEFAULT_serviceobjects.ini
    • data
      • DEFAULT_{nameaffix}_objects.ini
      • DEFAULT_{nameaffix}_relations.ini
    • movable
      • DEFAULT_movable.ini
      • DEFAULT_pager.ini
      • news
        • DEFAULT_news.ini
        • DEFAULT_serviceobjects.ini
Die DEFAULT_movable.ini sollte ca. so aussehen:

Code: Alles auswählen

[IrgendEinName]
filename = "DEFAULT_pager.ini"
source = "config/movable"
target = "modules/pager"

[NewsIni]
filename = "DEFAULT_news.ini"
source = "config/movable/news"
target = "extensions/news"

[NewsServiceobjects]
filename = "DEFAULT_serviceobjects.ini"
source = "config/movable/news"
target = "extensions/news" 

Es gibt in wwwroot/apps/config/modules/pager bereits eine DEFAULT_pager.ini - damit diese nicht überschrieben wird, das Modul aber dennoch seine Config erhält, passiert foglendes: Die config/movable/DEFAULT_pager.ini Datei wird ausgelesen. Im ausgelesenen Code wird eine Sektion namens [guestbook] erwartet. Diese Sektion inklusive dessen Inhalt wird in die bereits existente wwwroot/apps/config/modules/pager/DEFAULT_pager.ini hineingeschrieben.

Existiert am target-Ort noch keine so benannte Config-Datei, dann wird Sie auch an den target-Ort hin kopiert.



Ich denke, damit habe ich alle Config-Möglichkeiten abgedeckt, oder?

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

Re: WebRex CMS

Beitrag von dr.e. » 17.03.2012, 15:14:53

Hi,
Ich denke, damit habe ich alle Config-Möglichkeiten abgedeckt, oder?
Ich denke ja.
Viele Grüße,
Christian

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

Re: WebRex CMS

Beitrag von TipTop » 02.04.2012, 10:00:57

Ich wollte das CMS bzw. den Admin Control Panel des CMS von Anfang an komplett auf AJAX aufbauen - jetzt habe ich mir überlegt, dass doch ein RIA-JS-Framework ala Dojo/ExtJS/jQWidgets in Verbindung mit APF ideal dafür wäre. Diese RIA-JS-Frameworks sind echt top modern, einziger kleiner Nachteil: es gibt beinahe keinen HTML-Code (zumindest keinen manuell geschriebenen), da nun mal beinah alles auf JS und AJAX-Request basiert.

Was denkt Ihr - APF und ExtJS, harmonieren die beiden? Die TagLib-Funktionalität des APF wäre im Backend des CMS nicht verwendbar - dafür würde ExtJS sich um die Formular-Prüfungen und -Generierungen kümmern.
Das APF würde im Backend-Bereich bis auf 3 Templates dann ausschließlich aus Front-Controller-Actions und Business-Komponenten bestehen.


Bisher habe ich mit ExtJS in Verbindung mit APF keine Probleme feststellen können. Die Objekte, die der GORM liefert, müsste ich zwar in XML bzw. JSON umwandeln, aber ansonsten kann man denk ich die APF-Funktionalität ganz normal verwenden.


Habt Ihr schon mal mit APF und einem RIA-JS-Framework ein Projekt umgesetzt? Was für Vor- und Nachteil ergaben sich dabei?

Grüße

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

Re: WebRex CMS

Beitrag von dr.e. » 09.04.2012, 17:42:29

Hallo Nico,
Was denkt Ihr - APF und ExtJS, harmonieren die beiden?
Grundsätzlich auf jeden Fall. Das APF erzeugt HTML- und - bei Bedarf - JS- und CSS-Code und ist somit für jede Art von Web-Anwendung geeignet.
Die TagLib-Funktionalität des APF wäre im Backend des CMS nicht verwendbar - dafür würde ExtJS sich um die Formular-Prüfungen und -Generierungen kümmern.
Das APF würde im Backend-Bereich bis auf 3 Templates dann ausschließlich aus Front-Controller-Actions und Business-Komponenten bestehen.
Das ist meiner Ansicht nach ein gangbarer Weg, allerdings solltest du eine Mögllichkeit vorsehen, die für den Anwender und Entwickler eine Erweiterung der Funktionalität zulässt. Konkret geht es mir da um die Möglichkeit, eigene Masken zu erstellen und mit den mitgelieferten Mitteln eigene Funktionalität einbauen zu können. Möchtest du beispielweise eine Oberfläche zur Verwaltung eines Gästebuchs anbieten, so musst du als Entwickler auf Basis deiner API in der Lage sein, ein eigenes Interface samt Installer und Konfigurator ohne 5 Jahre Einarbeitung zu schreiben. Sofern das alles auf ExjtJS und einer sauberen AJAX-API basiert, die die Basis-Funktionalitäten wie z.B. Benutzer-Verwaltung bereitstellt, sollte das funktionieren. Ist jeweils nur der Teil so bereitgestellt, den die mitelieferten Funktionen nutzen, stößt der Entwickler schon seht bald an die Grenzen und wird entweder andauernd um Support bitten oder auf ein anderes Produkt umsteigen.

In der letzten Zeit habe ich einige Stunden mit Joomla verbracht, das auch eine solche Schnittstelle für eigene Komponenten anbietet. Im Fall von Joomla sogar mit einer eigenen XML-API zur Erstellung von Editoren. Das klingt zunächst nett, die Doku und die Anpassung der UI sind jedoch alles andere als smooth und damit verliert der Anwender sehr schnell die Lust oder bastelt sich von Grund auf etwas eigenes.
Bisher habe ich mit ExtJS in Verbindung mit APF keine Probleme feststellen können. Die Objekte, die der GORM liefert, müsste ich zwar in XML bzw. JSON umwandeln, aber ansonsten kann man denk ich die APF-Funktionalität ganz normal verwenden.
Sofern du das Domänen-Objekt-Feature nutzt, könntest du die Serialisierung/Deserialisierung auch sehr elegant mit der Implementierung von __toString() erledigen.
Habt Ihr schon mal mit APF und einem RIA-JS-Framework ein Projekt umgesetzt? Was für Vor- und Nachteil ergaben sich dabei?
Nein, nicht in größeren Anwendungen. Aus meiner Sicht:

Vorteile: Business-Logik kann sehr schnell mit einer AJAX-API nach aussen repräsentiert werden
Nachteil: Funktionalität des APF für GUI-Anwendungen (z.B. Formular-Validierung) kann nicht komplett genutzt werden.
Viele Grüße,
Christian

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

Re: WebRex CMS

Beitrag von TipTop » 17.05.2012, 09:07:13

http://www.webrex.org/test/acp/index.php
Benutzername: Admin
Passwort: demo

Ich hatte vor, Mehrsprachigkeit direkt im CMS zu implementieren. In der linken Spalte im Admin Control Panel sieht man Sprachen (in Form von Verzeichnissen), welche Seiten beinhalten können. Mit Rechtsklick auf ein Sprach-Verzeichnis kann ich eine neue Seite zu dieser Sprache hizufügen, mit Rechtsklick auf eine Seite kann ich dieser eine Unterseite hinzufügen.
In der linken Spalte werden aber nur die Sprachen angezeigt, die man "aktiviert" hat. Bei der Installation und auch später, unter Einstellungen im ACP, kann man für die eigene Website festlegen, in welchen Sprachen sie vorhanden sein soll. In dieser Demo habe ich, wie man sehen kann, German und English/American aktiviert. Mehrsprachigkeit wird nun so realisiert: ich erstelle bspw. im German-Verzeichnis eine Seite mit dem Anzeigenamen Home. Wenn ich nun diese Seite auch in Englisch anbieten möchte, dann füge ich dem English/American-Verzeichnis ebenfalls eine Seite mit dem Anzeigenamen Home hinzu. Das wars dann eigentlich auch schon - um eine Seite in mehreren Sprachen anbieten zu können, muss man nur in den Sprach-Verzeichnissen diese Seite stets mit dem selben Anzeigenamen anlegen. Der Anzeigename ist aber natürlich nicht der Seitentitel - dieser kann für jede Seite extra festgelegt werden.
Was haltet Ihr von diesem Konzept bzw. wie würdet Ihr das lösen?

Grüße

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

Re: WebRex CMS

Beitrag von dr.e. » 17.05.2012, 11:29:07

Hallo Nico,

die vorgestellte Anwendungsfall eignet sich meiner Erfahrung nach mehr für Seiten, deren unterschiedliche Sprachen sehr divergente Strukturen bieten und eine Sprachumschaltung nicht auf Seiten-ebene notwendig ist. Solltest du eine Seite in mehreren Sprachen mehr oder weniger Synchron anbieten wollen, eignet sich eine Umschaltung direkt auf dem Navigationsknoten deutlich besser. Damit wird nicht nur eine Umschaltung einfacher, der Redakteur kann auch sehr einfach sehen, wie der Punkt in den unterschiedlichen Sprachen aussieht/gepflegt ist.

Soll die Navi-Struktur in unterschiedlichen Sprachen unterschiedlich sein - wie aktuell der Fall -, dann kann der Redakteur ja die Struktur nur in der Sprache "vertiefen" (also anlegen), in der sie gewünscht ist. Möchtest du zwei sehr unterschiedliche Bäume anlegen, ist das ebenfalls möglich.
Viele Grüße,
Christian

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

Re: WebRex CMS

Beitrag von TipTop » 06.06.2012, 07:41:53

Header
- Haupt-Menü
- Breadcrumb-Menü

Sidebar
- Sub-Menü

Content
- Normaler Inhalt (WYSIWYG-Modul)
- Kommentar-Funktion (Comment-Modul)
- Normaler Inhalt (WYSIWYG-Modul)

Footer
- Normaler Inhalt (WYSIWYG-Modul)


Bei so einer einfachen Website-Struktur würden 11 MySQL-Queries abgesendet werden. Wobei ich die vom UMGT erzeugten Queries (bspw. um per Rollen zu prüfen, wer was sehen darf) noch nicht mit einberechnet habe. Wenn man statt der Kommentar-Funktion jetzt noch ein Forum-Modul einbindet, steigt die Query-Anzahl gleich auf 20+.

Das ist ja relativ viel oder? Wisst Ihr wo bei anderen CMSs die Query-Anzahl in etwa liegt?

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

Re: WebRex CMS

Beitrag von dr.e. » 06.06.2012, 15:07:51

Hallo Nico,

bei der aktuell genutzten Joomla-Installation bewegt sich das auch in diesem Rahmen. Je mehr Module auf der Seite eingebunden sind, desto mehr Queries werden das. Dieser Umstand sollte dich nicht weiter stören, solange die Performance darunter nicht leidet.
Viele Grüße,
Christian

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

Re: WebRex CMS

Beitrag von Megger » 06.06.2012, 15:39:19

Wenn du PDO nutzt, dann könntest du gleiche Statements vorbereiten und dann ausführen! Dadurch sparst du dir einiges an Performance! Funktioniert allerdings nicht per GORM
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

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast