Angeber...

[Christian Kruse]

Hallo Andreas,

alter Angeber, mit welchem Hintertürchen kannst Du bitte
15 KB posten???

vi fo_post.conf... ;)

Unverschämtheit, und unsereins darf seinen Beitrag ggfs.
bis zur Unkenntlichkeit verstümmeln ;-)

Das sind die Vorrechte des Administrators *fg*

Ja, allerdings eine relativ primitive. Damit forderst du
Inkonsistenzen geradezu heraus.
wo denn? Meinst Du dass jedes Modul seine eigenen
Funktionen... haben soll?

Nein, ich meine, was ist, wenn irgendwann mal die Struktur
aenderst? Oder wenn du den Array-namen aenderst? Oder
sonstwas? Wuerdest du das abstrahieren, sprich, Methoden
definieren, die aufgerufen werden, koenntest du deren
Rueckgabe evntl. transformieren. So muesstest du jedes Plugin
umschreiben.

Aber das mache ich gerade _weil_ in absehbarer Zeit
niemals jemand anderer als ich ein Modul hierfür schreiben
wird.

Das kannst du nie wissen. *Jedes* Code-Stueck, und sei es
noch so sehr dahingerotzt, kann an beliebiger Stelle wieder
auftauchen.

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.

*seufz*
$funcname       = $modul."_menu_hook";
$menu_entries[] = $funcname($arg1,$arg2);

Und einen Rückgabewert, ob Klasse oder nicht, ich kann
definitiv keien Funktion in das Modul schreiben,

Natuerlich kannst du.
$classname = $modul."Class";
$obj &= new $classname($arg1,$arg2);
$menu_entries[] = $obj->menu_hook();

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.

Hae? Du muesstest schon eine Script-Sprache nachbauen, wenn
du das erreichen willst, was mir vorschwebt (bedingtes ein-
und ausblenden von Teil-Menues, highlighten von
Menue-Eintraegen, etc, pp).

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!?

Hae?

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 *verarbeitest* du Rueckgabewerte. Das ist eine
Schnittstellen-Definition, du hast einen definierten
Rueckgabewert, das wird sich nicht aendern. Aber wie du das
intern weiterverwertest, ist voellig schnuppe.

Da bin ich auch davon abhängig das ich die Funktion oder
die Zusammensetzen dessen Namen nicht ändere.

Warum?

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

Nichts. Zu inflexibel.

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?

Dazu muss die Ausgabe-Routine aber von den Stati des Plugin
wissen. Und das tut sie nicht (oder sollte sie zumindest
nicht, dann ist sie nicht mehr modular). Nein, welcher Teil
des Menues von der Ausgabe-Routine benutzt wird, sollte
schon das Plugin entscheiden.

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?

Hae?

LOAD usermanagement.inc.php:UserManagement
Was ist das für eine Syntax? Oder parst Du das noch selbst?

Sicher.

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

Hier muss 'Informationen' statt 'Funktionen' hin.

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?

Indem du die Callback-Routinen aufrufst. Die Rueckgabe sind
dann die benoetigten 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?

Es muss keine Funktion sein. Es kann eine Methode sein.

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!

Was hat das eine mit dem anderen zu tun?
Deshalb bin ich btw. bei sowas dafuer, Plugins als Klassen
zu implementieren. Dann hat man die Probleme der Namensgebung
nur bedingt.

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?

Ja. Ueber definierte Methoden.

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?

Warum sollte ich etwas doppelt implementieren? Meide
Redundanzen!

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?

Du benutzt das Plugin 'Adressbuch', um an die Daten zu
kommen.

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?

Warum zum Teufel willst du Sachen zweimal implementieren?

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?

PEAR::DB ist maechtig, aber teilweise ziemlich idiotisch
umgesetzt. Deshalb habe ich mich dagegen entschieden.

Gruesse,
 CK