php Variablen in anderen Skripten nutzen: Global / public Method?
0 0 0 0 0 0 0 -1 0 0 1 0 0 0 
Matthias Apsel
0
0
1 
dedlfix
php Variablen in anderen Skripten nutzen: Global / public Method?
Hallo,
Zugriff auf eine Information soll ziehmlich "global" in allen inkludierten PHP Skripten zu verfügung stehen. Es muss veränderbar sein.
ich würde einfach auf der PHP Oberfläche mit variablen arbeiten die wie gesagt nach include verfügbar sind. Aber veränderung der Variable in irgend einem Skript führt zu Unübersichtlichkeit.
Daher mein Frage ob es sinnvoller Wäre ne öffentliche Methode zu wählenoder n array.
Ein konkretes Beispiel. im index.php ist ein leere string Variable $title für den Titel einer Seite im <head>-Bereich. Je nach Seitefragment das im index.php geladen wird verändert sich der Titel über die Variable $title = "home" oder so.
Ich höffe uch hab den Sachverhalt ausreichend erläutert. Kann man dieses aufkommende Problem nicht eleganter lösen? Für lösungsansätz wätre ich sehr dankbar.
Herzlichste Grüße,
MB
-
Moin!
Daher mein Frage ob es sinnvoller Wäre ne öffentliche Methode zu wählenoder n array.
Ob nun öffentliche Methode oder Array (meinst Du $GLOBALS? nimmst - das macht keinen Unterschied, weil das selbe Problem dann nur an anderer Stell entsteht. Es sei denn Du willst im Objekt registrieren, was wodurch verändert wurde.
Ich höffe uch hab den Sachverhalt ausreichend erläutert. Kann man dieses aufkommende Problem nicht eleganter lösen?
Ein einfaches if in der Templateengine oder vor deren Aufruf.
Wenn $template['title'] nicht gesetzt oder leer ist wird $GLOBALS['config']['title'] genommen. Das kann man in einer foreach-Schleife auch für alle andere Elemente von $GLOBALS['config'] machen.
Jörg Reinholz
-
Jo, besten Dank. Gruß MB
-
-
Ein konkretes Beispiel. im index.php ist ein leere string Variable $title für den Titel einer Seite im <head>-Bereich. Je nach Seitefragment das im index.php geladen wird verändert sich der Titel über die Variable $title = "home" oder so.
Betrachte eine Seite als Object mit Attributen (title, descr,...):
<!-- title=Eine unglaubliche UFO Beobachtung am Himmel --> <!-- descr=Ein astronomisches Ereignis was bis heute ungeklärt ist --> <!-- parent=/tunguska --> <!-- interface=xmonth --> <!-- year=1969 --> <!-- month=6 --> <p> Text text....Dieser Seite ist in der Routing Table ein URL zugeordnet und dieser ist an eine Subklasse gebunden. Damit ist der URL valide und die Seite wird ausgeliefert. Title und Descr werden an der richtigen Stelle ins Template gepflanzt, dafür sorgt das in der Basisklasse aufgebaute Rahmenwerk, was Methoden aufruft.
Über das Attribut interface=xmonth kriegt die Seite einen Monat als Tabelle mit Links zum nächsten Monat oder vorherigen Monat. Beim Klick haben wir einen Parameter im Request und was in dem Fall passieren soll, wird in einer Methode geregelt, welche ebenfalls das Interface mitbringt (vereinfacht):
sub control{ my $self = shift; $self->eav('title', 'Neuer Titel wird vergeben'); }Interessant ist hier die Methode eav() welche die Basisklasse definiert. Der Funktionsname steht für Entity, Attribute, Value und diese Methode ist der Accessor (get/set) für jedes beliebige Attribut einer Response-Seite.
Fazit: Nimm Dein Anliegen zum Anlass über den Sinn und Zweck einer objektorientierten Herangehensweise nachzudenken.
-
Hallo pl,
Betrachte eine Seite als Object mit Attributen (title, descr,...):
Wie meinst du das?
Dieser Seite ist in der Routing Table ein URL zugeordnet und dieser ist an eine Subklasse gebunden. Damit ist der URL valide und die Seite wird ausgeliefert.
Ich dachte Routingtabellen gibt es nur auf Hardwarebasis. Es ist mir neu das das auch bei Softwaretechnik den begriff verwendet.
Ich woll die Index-Veweise (Routing-Tabelle?) tatsächlich OOP konstruieren und nicht prozedual.
momentan habe ich nur eine Globale variable $title eben was im <header>- sowie im <title>-Bereich geladen wird.
Schreib konkret was du meinst.
Herzlichste Grüße MB
-
momentan habe ich nur eine Globale variable $title eben was im <header>- sowie im <title>-Bereich geladen wird.
Schreib konkret was du meinst.
Konkret: $title nicht als globale Variable halten, sondern als ein Attribut welches nur zu derjenigen Seite gehört, die ausgeliefert werden soll. Konkret ist für die Auslieferung der Seite eine Instanz derjenigen Subklasse zuständig, welche an den URL der Seite gebunden ist. Somit hat diese Instanz Zugriff auf das Title-Attribut und kann dieses auch ändern.
-
Ok, Dank. ne Idee, muss ich n konzept entwickeln und ausführen. Bin noch anfänger in PHP.
Herzlichste Grüße MB
-
Du könntest ein globales Array anlegen anstelle mehrer globler Variablen. Diesem Array gibst Du eine Struktur, z.B. so, dass unter dem URL für jede Seite die Attribute title, descr, usw. greifbar sind.
Alternative zum URL wäre eine numerische ID, beides ergibt einen eindeutigen Schlüssel in deinem Array. Dieses Array wird bei jedem Request, egal welche ID oder URL requestet wurde, komplett in den Hauptspeicher geladen. Danach wird es wieder eingefroren in einer Datei, z.b. in einer ini-Datei, da ist das alles editierbar.
Alles in Einem hat einige Vorteile. Einzelseiten können per Attribut einen Parent haben, so baust Du hierarchische Strukturen und kannst daraus Menus und Breadcrumbs erzeugen. Auf diese Art und Weise kann für einen virtuellen Ordner dein Script die title's auslesen und für die im virtuellen Ordner vorhanden Seite eine Übersicht erzeugen.
Das heißt, mit dem globalen Array ist schon alleine die Navigation kein Thema mehr und diesen Ansatz kannst Du beliebig erweitern.
Deine Seiten haben nun per Konfigurationsdatei Attribute, das ist der erste Schritt in Richtung OOP. Neben title, descr, usw. konfiguriert eines der Attribute den Pfad im Dateisystem zur Template-Datei. Hier bist Du unabhängig vom Document-Root und kannst die Quelle später ändern. Z.B. die ganze Konfiguration in einer Datenbank halten anstelle einer ini-Datei....
-
Du könntest ein globales Array anlegen anstelle mehrer globler Variablen. Diesem Array gibst Du eine Struktur, z.B. so, dass unter dem URL für jede Seite die Attribute title, descr, usw. greifbar sind.
Ich habe eine Verzichnis klasse gebastelt die spezifische beliebig viele dateien in einem kontainer(verzeichnis) ausließt und in nem Array abspeichert. Und zur zeit an einer Navigations Klasse die über extends die liste aufgreift die die erste klasse liefert mit errors, defaul werten usw.
ich bevorzuge kleine viele klassen die dann eingebunden werden können oder nicht. finde ich übersichtlicher.
Deine Seiten haben nun per Konfigurationsdatei Attribute, das ist der erste Schritt in Richtung OOP. Neben title, descr, usw. konfiguriert eines der Attribute den Pfad im Dateisystem zur Template-Datei. Hier bist Du unabhängig vom Document-Root und kannst die Quelle später ändern. Z.B. die ganze Konfiguration in einer Datenbank halten anstelle einer ini-Datei....
Hört sich gut an. aber mir ist nicht soganz klar was du mir vorschlägst. Sry bin schwer von begriff.
Wo kann ich Quellcode hochladen so dass ein geschultes auge - z.b. du - insizieren kann?
Grüß MB
-
Code ist uninteressant, je mehr nachdenken, desto weniger COde ;)
Deine Idee: Verzeichnis auslesen ist ein guter Anfang. Da hst Du aber nur die Dateinamen, Du brauchst mehr wie Titel, Beschreibung u.a. Attribute.
ich bevorzuge kleine viele klassen die dann eingebunden werden können oder nicht. finde ich übersichtlicher.
Es ist genau umgekehrt.
-
habs ja verwirklicht. Und ja natürlich, je mehr Meditation desto weniger code.
Titel und Beschreibum sind uninteressant, die Sprachen sind noch uninteressant. Es wrid später für mich interessant, ich hab Zeitdruck. Zwar ist es relativ schnell gemacht aber nicht angefordert. Ich will übrigens nachher zusätzlich mit xml arbeiten und die info daraus ziehen.
Gruß MB
-
Ich will übrigens nachher zusätzlich mit xml arbeiten und die info daraus ziehen.
Daten in XML persistent zu machen, ist die allerschlechteste Form der Datenhaltung. Deswegen ja mein Vorschlag mit der ini-Datei, die ist zum einen sehr viel schneller eingelesen und andererseits viel komfortabler zum Bearbeiten.
Btw., ca 250 Unterseiten kompakt in einer Datei mit ca 800 kB. Da sind auch die Body-Templates mit drin. In XML ist sowas nicht zu machen.
-
Hallo pl,
Btw., ca 250 Unterseiten kompakt in einer Datei mit ca 800 kB. Da sind auch die Body-Templates mit drin. In XML ist sowas nicht zu machen.
Selbstverständlich ist sowas auch in XML zu machen.
LG,
CK-
Btw., ca 250 Unterseiten kompakt in einer Datei mit ca 800 kB. Da sind auch die Body-Templates mit drin. In XML ist sowas nicht zu machen.
Selbstverständlich ist sowas auch in XML zu machen.
Ok. Nehmen wir 500 HTML-Seiten, das ergibt einen Hash mit 500 URls als Schlüssel. Zu diesem Schlüssel gehören die Attribute:
- Title
- Descr
- class
- Body
- Kurztitel
und ggf. weitere Attribute. Natürlich kannst Du diesen Hash als XML einfrieren, es dürfte eine 3 MB Datei werden. Nicht besonders schön zu editieren und nicht besonders performant beim Einlesen.
Gerne gucke ich mir ein diesbezügliches Beispiel an:
-
Tach,
Gerne gucke ich mir ein diesbezügliches Beispiel an:
soweit ich mich entsinne, hat die vorherige Version des CForum seine Daten als XML persistiert.
mfg
Woodfighter-
Hallo woodfighter,
Tach,
Gerne gucke ich mir ein diesbezügliches Beispiel an:
soweit ich mich entsinne, hat die vorherige Version des CForum seine Daten als XML persistiert.
Und imo auch die Mediawikis. Da bin ich aber nicht sicher.
Bis demnächst
Matthias--
Das Geheimnis des Könnens liegt im Wollen. (Giuseppe Mazzini)-
Hallo Matthias,
Gerne gucke ich mir ein diesbezügliches Beispiel an:
soweit ich mich entsinne, hat die vorherige Version des CForum seine Daten als XML persistiert.
Wusste gar nicht, dass ich das Repo noch habe. Sollte ich mal löschen. Das war der Anfang eines Rewrites in C++. Was du suchst findest du hier: https://github.com/ckruse/cforum-upto-3.4
Und imo auch die Mediawikis. Da bin ich aber nicht sicher.
Nein, MediaWiki nutzt MySQL für den Content. Aber es gibt eine Extension, vielleicht meinst du die.
LG,
CK
-
-
Gerne gucke ich mir ein diesbezügliches Beispiel an:
soweit ich mich entsinne, hat die vorherige Version des CForum seine Daten als XML persistiert.
Wenn nicht bei jedem Request serialisiert werden muss ist die Datenhaltung egal, obwohl es in Perl zumindest noch nie einen Grund gab, Daten in XML persistent zu machen. Mein erstes Forum hab ich 2001 programmiert und in DB_File gespeichert, ein Kommentar an den ich mich gerne erinnere: Es ist affenartig schnell.
-
-
-
Soviel will ich nich machen. Wennssehr komplex wird würde ich Tatsächlich PDO für DB nehmen. Aber es sind ja nur ein zwei Seitenfragmente, die als Fragment statisch sind und die man bequem aus XML einlesen und als HTML Fragment reinladen kann
Grüße MB
-
Moin!
Aber es sind ja nur ein zwei Seitenfragmente, die als Fragment statisch sind und die man bequem aus XML einlesen und als HTML Fragment reinladen kann
- Alternativen
- Und wenn Du schon dabei bist, dann denke bei quasistatischen Inhalten über das Cachen nach.
Jörg Reinholz
-
-
-
-
-
-
-
-
-
-
-
Tach!
Zugriff auf eine Information soll ziehmlich "global" in allen inkludierten PHP Skripten zu verfügung stehen. Es muss veränderbar sein.
Du suchst eine Lösung für eine Herangehensweise, die an sich schon nicht unproblematisch ist.
ich würde einfach auf der PHP Oberfläche mit variablen arbeiten die wie gesagt nach include verfügbar sind. Aber veränderung der Variable in irgend einem Skript führt zu Unübersichtlichkeit.
Wenn du irgendwo globale Werte hinlegst und an ganz anderen Stellen im Programm darauf zugreifst, hast du mehrere Stellen im Code verteilt, die alle koordiniert werden müssen. Das hast du ja bereits erkannt. Es ist besser, wenn man die Parameter explizit an die verarbeitenden Stellen gibt, das Ergebnis von ihnen entgegennimmt und dem nächsten Schritt weitergibt. Dazu muss man strukturiert arbeiten. Die einfachste Variante ist das EVA-Prinzip: Eingabe - Verarbeitung - Ausgabe. Der Eingabeteil ist bei PHP oftmals recht kurz oder gar nicht nötig, weil ja schon alles zugriffsbereit in $_POST/$_GET und Konsorten zur Verfügung gestellt wurden. Die Verarbeitung ermittelt die Werte, die die Ausgabe benötigt und übergibt diese idealerweise gebündelt. Das sind nur die reinen Werte, ohne HTML oder andere ausgabespezifische Geschichten. Die kommen erst im Ausgabeteil hinzu.
Daher mein Frage ob es sinnvoller Wäre ne öffentliche Methode zu wählenoder n array.
Oder. Wenn es sich um ein kleines Geradeaus-Script handelt, lohnen sich Funktionen kaum. Aber wenn es komplexer wird, wären sie ein erster Schritt. Für sehr große Anwendungen gibt es weitere Vorgehensweisen, die bekannteste wird MVC genannt (obwohl das technisch nicht ganz stimmt, aber egal).
dedlfix.
-
Hallo Delfix
Wie kann ich den unvolständigen Code in seiner ganzen Pracht vorstellen, damit du einblick in meine Lösungsansätze bekommst?
Gruß MB
-