Angeber...

[Andreas Korthaus]

Hi Christian,

alter Angeber, mit welchem Hintertürchen kannst Du bitte 15 KB posten??? Unverschämtheit, und unsereins darf seinen Beitrag ggfs. bis zur Unkenntlichkeit verstümmeln ;-)

ich mache das zur Zeit so, dass ich global eine Datei in
alle Scripte einbeziehe, in der die DB-Verbindung
hergestellt wird, die Funktionen einmalig stehen, die ich
dann in den Scripten nutze. Noch ein paar .ini Änderungen,
sonst nichts. Ist das schon eine Schnittstelle?

Ja, allerdings eine relativ primitive. Damit forderst du
Inkonsistenzen geradezu heraus.

wo denn? Meinst Du dass jedes Modul seine eigenen Funktionen... haben soll? Aber das mache ich gerade _weil_ in absehbarer Zeit niemals jemand anderer als ich ein Modul hierfür schreiben wird. Zumindest ist es nicht vorgesehen, falls das doch mal notwendig werden sollte muß ich das halt dokumentieren. Oder meinst Du noch was anderes?

Dann benutze Klassen und Objekte. Oder setze den Funktions-Namen aus Modul-Name.'_menu' zusammen. Oder mach es
sonstwie :) Du weisst doch, wie Referenzen in PHP
funktionieren.

weiß ich nicht, hab das gerade mal nachgelesen, interessante Variante! Nur brauche ich im Prinzip das genaue Gegenteil, hier kann ich mehrere Variablen definieren, mit dem glichen Inhalt, und dafür bräuchte ich nichtmal Referenzen, aber ich brauche irgendwie eine Variable mit verschiedenem Inhalt je nach Modul. Das kann nicht funktionieren. Und einen Rückgabewert, ob Klasse oder nicht, ich kann definitiv keien Funktion in das Modul schreiben, außer ich überlege mit einen zusammengesetzen Namen. Daher sollte man das IMHO besser in eine conf-File schreiebn und die parsen, das geht doch auch recht schnell. _Dann_ kann ich das in eine Klasse schreiben... warum auch immer das Sinn machen sollte.

Und warum soll ich das als Funktion speichern?

Damit du dort ausfuehrbaren Code hast.

vermutlich sind includes auch nicht so viel schneller als ein fopen, und das parsen von ein paar Zeilen, nur damit hätte ich direkt _alle_ Werte in einer saubereren Struktur als Funktionen mit zusammengesetzten Namen. Ich würde ja evtl. das ganze bei jeder Änderung als ausführbaren Array hardcoden, aber da bist Du ja dagegen. Wobei man IMHO fast genauso leicht einen Array auch manuell verändern kann, wie eine csv-Datei!?

menu[]=array(menü-struktur...);

Klar, koenntest du machen. Damit machst du dich aber von dem
Array abhaengig. Was ist, wenn du den mal umbenennst?
Ausserdem widerspricht es dem Prinzip der Datentrennung. Ein
externes Code-Stueck hat an internen Variablen einfach nix
zu suchen, basta.

Aber ist das denn mit Funktionen so viel anders? Da bin ich auch davon abhängig das ich die Funktion oder die Zusammensetzen dessen Namen nicht ändere. Einfache Datendatei wäre mir bisher eigentlich am liebsten.

Was hälst Du von der Funktion parse_ini_file() für sowas?

Wäre es denn nicht besser die komplette Menüstruktur in
eine DB-Tabelle oder eigene conf_datei zu schreiben, und
dann bei der Installation des Moduls eine neue PHP Datei
zu erstellen, die den kompletten, aktuellen Menü-Array
hardcoded enthält?

Ansichtssache. Ich halte das fuer zu inflexibel. Ich moechte
meine Menues dynamisch aendern, abhaengig vom
Programm-Ablauf.

reicht es da nicht einen kompletten Array zu haben und ggfs. nur einen Teil dessen auszugeben? Die komplette Navigation ändert sich doch nur wenn ich das sage, also wenn ein Modul oder Update dazu kommt. Das wird installiert und der Array wird wieder aktualisiert.

was ist bei einem Kontakt-Formular, das enthält eine
Funktionalität, das menü wird dynamsich eingebunden, was
solte hier noch dynamisch sein?

Das Kontakt-Formular selber ist ein Modul. Das Modul hat ein
Template, das bei Bedarf angepasst werden kann. Das Template
bindet das Menue per include() oder etwas aehnlichem ein. Wo
ist das Problem?

Jaja! Ein Problem habe ich nicht, nur dass ich nicht weiß was noch dynamisch sein soll, da Du sagst _alles_ soll dynamsich sein. Nochwas dazu:
Sollte man denn das Modul Kontaktformular so frei machen könnten, das man die Navigation... selbst einbinden kann? Ich binde eigentlich immer 4 Dateien ein:
1. global.inc (PHP-Funktionen...)
2. header.inc
3. footer.inc
4. menu.inc

Könnte man dei Struktur nicht auch noch aulagern, so dass man wirklich  als Template nur noch mit dem wirklichen body des Dokuments zu tun hat, und keine includes?

LOAD usermanagement.inc.php:UserManagement

Was ist das für eine Syntax? Oder parst Du das noch selbst?

Und woher weiß ich dann wieviele Module das sind...?
Zaehlen? :)

genau da lag das Problem - was zählen... aber mit einer conf-File sieht das ganze ja schon etwas besser aus, jetzt komme ich an die Werte, deren Anzahl...

Nur ich weiß weder wie ich an diese beiden Informationen
kommen soll, noch was das ganze mit Klassen zu tun haben
soll.

Du hast eine Basis-Klasse, nennen wir sie mal
'KorthausPlugin'. Die definiert verschiedene Methoden, unter
anderem z. B. die Methode 'menu_hook'. Rueckgabewert und
Parameter sind definiert. Nun gehst du, wenn du das Menue
generierst, alle in der Konfigurations-Datei angegebenen
Plugins durch, instanzierst sie und rufst dann die Methode
menu_hook auf. Aus den so gewonnen Funktionen kannst du dann
Problemlos das Menue generieren.

Da kann ich Dir leider nicht folgen. OK, in der conf-File stehen die Module. Nur wie komme ich dann an die Werte? So wie ich das verstanden  habe hat jedes Modul eine Funktion menu, das bekomme ich nur durch include, also müßte ich hier wieder zusammengesetze Funktionsnamen haben - setzt Du das hier voraus?

Referenzen worauf?
Auf Funktionen.

das geht doch? Aber was bringts? Sobald ich mehr als 1 Funktion mit demselben Namen einfüge, per include, ist Ende!

Definiert und bekannt
sollten nur die wichtigsten sein: User-, Gruppen- und
Rechte-Strukturen.

Ah, das hatte ich noch gar nicht bedacht. Bisher habe 2 Ebenen, von denen die eine mehr sieht als die andere. Diese Information müßte ich auch in das Menü mit einarbeiten. Sonst verwene ich als Login-Mechanismus Basic Authentification mit .htaccess und habe user und gruppen dort definiert. Aber das ist nicht so wield, denn die eine Gruppe darf nur in das Verzeichnis X, die andere nur in Y, und die dritte in Z. Die Module gelten aber immer nur in einem Verzeichnis. Das heißt ich muß nur die Hirarchie-Ebenen mit einbauen.

also muss noch eine Aufgabe in
das Rahmenwerk: der Zugriff auf die Kern-Daten muss
abstrahiert werden.

was heißt das praktisch? Zugriff auf die Kerndaten über eine Klasse oder was?

Beispiel: ein
Webmail-Tool koennte mit dem Adressbuch-Tool arbeiten, um
E-Mail-Adressen herauszusuchen.

Aber wieso muß ich hier auf Routinen(Funktionen) des anderen Moduls zurückgreifen? Ich prüfe ob das Modul vrohanden ist und greife dann direkt auf die DB zu! Obwohl, was wenn sich die Tabele da ändert... also brauche ich speziell hierfür eine eigene Klasse die den Zugriff auf die Adressdaten regelt, oder wie würdest Du das jetzt machen?

So, jetzt geh ich erstmal baden :)

wenigstens schön mit gelbem Quitscheentchen?

Was ist aber, wenn ein Plugin Eingabedaten vom User braucht?
Prinzipiell muesste also ein Plugin, dass mit einem anderen
kommuniziert, die GUIs des anderen nachbauen. Das ist aber
nicht sinnvoll, also muss es eine Moeglichkeit geben, die
Kontrolle ueber mehrere Requests hinweg an ein Plugin zu
geben. Nach den Ablaeufen muss die Kontrolle wieder zurueck
gegeben werden an das 'alte' Plugin.

Das kommt ja nicht oft vor. Wenn das vorkommt, könnte man da nicht eine extra Schnittstelle in das Telefonbuch-Plugin einbauen, die das Telefonbuch als html-Tabelle zurückgibt, die sich ggfs. in ein anderes Plugin einbetten ließe?

Der Zugriff auf die Daten geschieht ueber die Methode
'db_query'. Der wird als Parameter die Query als String
uebergeben und dazu, optional, der Datenbank-Name. Wird kein
Datenbanks-Name uebergeben, so wird die Default-Datenbank
genommen. Jede Datenbank muss vorher in der
Konfigurations-Datei dem System bekannt gemacht werden.
Besteht eine Verbindung zu dem Datenbank-Server, so wird (bei
Bedarf) nur die Datenbank gewechselt und dann die Query
ausgefuehrt. Besteht keine Verbindung, so wird eine neue
Verbindung aufgebaut und dann die Query abgesetzt. Die
Rueckgabe ist eine DBResult-Klasse. Doch zu der spaeter.

Ich plane hierfür die PEAR::DB Klasse zu verwenden. Das solte mir doch genügend Möglichkeiten geben, oder?

Najut. Der Zugriff auf die Kern-Daten. Was genau muessen wir
ueber den User wissen? Eigentlich nur den Usernamen und
vielleicht noch die Sprache. Ach ja, die User-ID waere noch
ganz angenehm. Dazu noch, welche Rechte der User hat... gut,
also gibt es eine Methode 'user_infos', die einen Array
zurueck gibt, dessen erstes Argument die User-ID ist und
dessen zweites Argument der Username ist. Die Sprache kann
ueber die Methode 'lang' abgefragt werden. Die Rueckgabe ist
die aktuelle User-Sprache.

Ich habe zur Zeit keine UserIDs. Wollte ich erst, aber das wäre dann wieder ein Join mehr geworden und ich hatte meist schon genug. Also Basis für meine userdaten habe ich die htpasswrd Datei, in der nur unique-User stehen dürfen. Die User stehen auch alle in einer Tabelle Users, da stehn dann  mehr Daten, da ich für Mails... auch deren Tel, email, Position, vollst. Namen... brauche. Und da steht auch die Hierarchie-Ebene und Sprache. Ich mache das so da ich keine Sessions verwende. Mit Session wäre das ganze vielleicht anders besser zu lösen, aber so will ich pro Seite möglichst wenig neu Abfragen, wobei, langsam werden es immer mehr Daten, vielleicht böte sich hier doch langsam ein Session-Mechanismus zum Speichern der Daten an.

Mit dem oben abgebildeten Konzept sollte man eigentlich so
ziemlich alles abbilden und einbauen koennen. Mir ist kein
Fall eingefallen, der nicht moeglich ist. Jedes Plugin hat
seinen eigenen Namespace und jedes Plugin hat seinen eigenen
Tablespace. Kollisionen sind also nicht unmoeglich, aber sehr
unwahrscheinlich.

Das ist für die Anforderungen und vor allem für meien aktuellen Kenntnisstand noch etwas zu hoch ;-) Verstehe das zwar grob, könnte es aber so ohne weiteres nicht umsetzen. Ein paar Ideen konnte ich aber gewinnen, und spätestens bei meinem nächten Projekt werde ich das Posting noch(ein paar) mal lesen und dann vielleicht noch mehr davon einbringen können. Ich brauche einfach keine so ausgereifte Möglichkeit, es sollen wie gesagt nur 3 oder 4 von mir programmierte Plugins nachträglich eingebaut werden können, wenn ich Schnittstellen dazwischen brauche schreibe ich mir hierfür eine eigene Klasse und es sollte erstmal reichen.

Jetzt faellt mir aber auch nicht mehr viel ein.

Vielen, vielen Dank, hast mir sehr geholfen!

Viele Grüße
Andreas