PowerPortalus

Ein richtiges Portal besteht aus mehreren Teilen:

Im Backend:

Adminbereich
Useradminbereich

Im Frontend:

Normaler Besucherbereich
Interaktive Besucherbereiche (ohne User zu sein)
Interaktive Userbereiche (erweiterte Möglichkeiten für eingetragene User)

Annahme:

Es besteht ein ungeheurer Bedarf an Portalsystemen, die einen individuellen Bedarf decken.

Problem und Ansatz:

Bei der Analyse bekannter bestehender Portalsysteme offenbarten sich erhebliche Schwächen.
Es gibt erhebliche Schnittmengen zwischen Lib's und Klassen aller Art und dem Front- wie auch den Backends. Damit werden jeweils Teile die nur im Frontend bzw. nur im Backend benötigt werden miteinander und untrennbar vermixt. Das aber bedeutet - alles wird deswegen schlechter wartbar und noch schlechter individuell anpassbar.
Eben Modulesysteme haben diese Schwächen und der wesentliche Schwachpunkt eines solchen Systems ist der Umstand das entweder Teile mitgeschleppt werden die man nicht benötigt oder es fehlen Teile die nur schwer "anzuflicken" sind.

Kein einziges System verwendet wirklich einen Dispatcher, der zentral die Aufgaben annimmt und verteilt.
Die meisten Systeme rufen ihrerseits eine komplette Aussenlogik auf die wirderum jeweils alles was benötigt wird lädt, statt vom Dispatcher diese Teile laden zu lassen und die externe Funktion zu includen.

Externe eigenständige Scripte zu laden heisst ja das man diese eigenständig mit Parametern und Request's versorgen muss.
Kein einziges System hat da eine zentrale Versorgung wie sie beim Einsatz eines Dispatchers und include das Aktionsscriptes möglich wäre, dabei ist das eine ganz einfache Sache wenn man sich eine Normierung einfallen lassen würde.
Eine realisierte Normierung besteht tatsächlich nur aus vier Scriptzeilen, liegt völlig zentral und fängt alles und das auch noch gefiltert (XSS!) auf und weist sie direkt an Variable zu, die von den include Scripten direkt verwendet werden kann. Da entfällt also jeglicher Overhead für solche Dinge.

Die Schnittmengen Frontend/Backend zu Libs in einem Testsystem besteht lediglich in den Teilen PiDatabase, Sessions,TPLE und der config.
Sprachdateien werden über TPLE und XML direkt angesteuert. Die Sprachdateien im Frontend wie auch Backend sind getrennt.
Die Scriptlänge des Dispatchers im Adminbereich beträgt nur 80 Zeilen und erledigt komplett die Login- und Rechteabprüfung, die Zuweisung von Variablen, die Steuerung von Sprachdateien und den notwendigen Aufruf der Headers - die aus praktischen Gründen geteilt sind um nach Usereinstellungen und Rechten z.B. Javascript ein-oder ausblenden zu können, das Menü in Abhängigkeit von Rechten, den Aufruf des Aktionsscriptes und der Footer, die  ebenfalls geteilt sind um z.B. Javascripte die vor </body> einzusetzen wären schalten zu können.

Die Aktionsscripte können nicht direkt aufgerufen werden.
Die Aktionssteuerung für die Menüs und den dazu notwendigen Rechten liegen extern und sind somit extrem einfach ergänzbar.

Tatsächlich hat sich ein solches System, das ich bei mir unter dem Bastelnamen PowerPortalus laufen habe, als enorm effizient heraus gestellt.
Standardkomponenten können - wenn man sich an das Normierungssystem hält, einfachst verändert werden und Sonderkomponenten nach Bedarf ebenso einfach erstellt werden.

Ziel der Übung ist es ein System zu schaffen mit dessen Hilfe ein komplettes und vor allem  individuelles Portalsystem in wenigen Arbeitstagen zu schaffen ist.
Gewerblichen Anwendern (und damit meine ich mehr jene die einen solchen Job ausführen sollen) sollte ein Werkzeug zur Verfügung gestellt werden, das ihnen wirtschaftliche Vorteile wie auch Vorteile im Wettbewerb bietet.

Die Grundsätzliche Struktur von Portalus ist fertig.

Nun werde ich das erste Portal damit aufsetzen, was auch produktiv werden soll um zu sehen wie es in der Wirkung ist.
Dieses Portal hat ein mehrfaches an Tabellen und Bearbeitungsmöglichkeuten im Backend als z.B. PCMS im Standard und eine ziemliche Anzahl von Aktionsplugins im  Frontend.

Die Basis - Funktion ist verblüffend, weil ein Aktionspunkt so etwas von direkt durchschlägt, also ohne große Umwege zur Auslösung kommt, das man nicht nur extrem wenig RAM verballert (nachgebautes PMS Menü weniger als 500 KB) sondern auch ausgesprochen flott zur Sache kommt (Dabei rede ich vom Backend - im Frontend erwarte ich eine POwer a la PCMS 2).

Das Dispatcherscript erledigt mit sehr kurzen Schritten schon alles wo wir bei PCMS Standard mit diversen Klassen arbeiten bin ich  beim "Basteln" auf gerade mal aktuell 90 Zeilen gekommen.
Included wird dazu nur noch
include ($root_dir.'config.php');
include($lib_dir.'PiDatabase4.php');
include($lib_dir.'sessions.php');
include ($lib_dir.'TPLE.php');
und das Actionscript selbst.

Bislang wurde zusätzlich keine einzige Klasse ausserhalb der o.a. benötigt und vom Konzept her werden wahrscheinlich auch keine mehr in der Praxis benötigt - das garantiert schellste Abwicklung einer Aktion.

DB Abfragen nach erfolgtem Login ganze 2, mit neuem Login ganze 4 inklusive dem Sessionhandling. welche über Mysql läuft und selbstverständlich dem kompletten abklappen des Rechtesystems.

Ziel der ganzen Übung nach Fertigstellung ist es ein komplett neues Portal von Null auf Hundert in maximal fünf Tagen - sprich 36 Arbeitsstunden  machen zu können.

Das würde einen Kundenkreis öffnen der sich gewaschen hat, da  auf einmal Aufträge zu vorher unmöglichen Preisen angenommen werden können und man verdient sich dann auch noch dumm und dämlich und genau diese abwickelnden Firmen sollen Portalus kaufen können.

Es wird eine Anzahl von "workern" geben, die stupide Arbeiten übernehmen.

Z.B. das Script welches aus den Daten einer Tabelle eine Rohform erstellt und das auch noch Template gesteuert oder jenes, das ähnliches macht, das eine Roh-Auslistung mit Blätterfunktion fabriziert.

Diese muss man nur aufgreifen, nicht benötigte Felder löschen und Individualsenf eintragen, was aber erheblich weniger Arbeit ist als wenn man alles zu Fuß macht.

Bei der Formgenererierung gibt es neben der Dateausgabe auch zur Kontrolle eine Bildschirmausgabe.

Es sind übrigens die Sprachzugriffe zu TPLE enthalten, im fertigen Produkt würde dann statt der Feldname die Bezeichnung aus der Sprachdatei kommen.

Solche Workers gibt es übrigens auch z.B. für die Auslistung inkl. Blätterfunktion und für andere Dinge.

Die Workers sind nur für die Entwicklungsphase gedacht die lokal also ohne Publikumszugriff abläuft, nach Fertigstellung kann und sollte das Verzeichnis gelöscht werden.