Superglobale Arrays

[Tom]

Hello,

könnte man in PHP eigentlich weitere (eigene) superglobale Arrays definieren?

Das müsste dann ja in der Konfiguration passieren. Und eine Zuweisungsvorschrift für den (Start-)Inhalt müsste man ja auch unterbringen können.

Wo müsste man im Source-Code eventuell eingreifen?

Bisher behelfe ich mir mit einem Auto-Prepend-File. Aber die Arrays sind dann nicht superglobal.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[SELFHTMLer]

Hallo,

könnte man in PHP eigentlich weitere (eigene) superglobale Arrays definieren?

Was waren Deine Schritte um diese Frage selbständig zu beantworten? Woran bist Du gescheitert?

Hat Dir bspw. diese Antwort nicht weitergeholfen?

Viele Grüße

[Vinzenz Mai]

Hallo Tom,

könnte man in PHP eigentlich weitere (eigene) superglobale Arrays definieren?
Wo müsste man im Source-Code eventuell eingreifen?

das willst Du nicht. Ganz bestimmt nicht.

Was wolltest Du mit einer "Tom-PHP-special-Edition"? Ständig pflegen und auf dem aktuellen Stand halten? Auf allen Installationen, die Du damit betreust? Auf den normalen Paketmanager für's Update verzichten? Das kann nicht Dein Ernst sein.

Bisher behelfe ich mir mit einem Auto-Prepend-File. Aber die Arrays sind dann nicht superglobal.

Was willst Du überhaupt erreichen? Ganz bestimmt gibt es für das, was Du bewirken willst, das eine oder andere Muster, das Du verwenden kannst. Jeder Weg (gegebenenfalls der Umstieg auf eine andere Programmiersprache) ist vermutlich sinnvoller als der von Dir in diesem Thread ins Auge gefasste ...

Abratende Grüße

Vinzenz

[Tom]

Hello,

Was willst Du überhaupt erreichen? Ganz bestimmt gibt es für das, was Du bewirken willst, das eine oder andere Muster, das Du verwenden kannst. Jeder Weg (gegebenenfalls der Umstieg auf eine andere Programmiersprache) ist vermutlich sinnvoller als der von Dir in diesem Thread ins Auge gefasste ...

Eben nicht wirklich. Dann wäre ich wirlich gezwungen, OOP anzuwenden. Das will ich aber gar nicht.

HTTP mit PHP ist schon ein "requestbasiertes OOP", da muss man nicht noch in jedem Fall eins draufsetzen. Jeder Request ist ein Objekt. Wenn PHP es endlich ermöglichen würde, auch Startobjekte zu deklarieren und ggf. auch zu definieren, dann hätte ich gegen OOP nichts mehr einzuwenden.

Diese Objekte müssten aber bereits in der Konfiguration deklariert werden können.

Die rudimentärste Version davon wäre, PHP-"superglobale Arrays" bereits in der Konfiguration zu deklarieren.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[hotti]

hi,

HTTP mit PHP ist schon ein "requestbasiertes OOP", da muss man nicht noch in jedem Fall eins draufsetzen. Jeder Request ist ein Objekt. Wenn PHP es endlich ermöglichen würde, auch Startobjekte zu deklarieren und ggf. auch zu definieren, dann hätte ich gegen OOP nichts mehr einzuwenden.

Was meinst Du mit 'Startobjekt'?

Hmm, was Du schreibst, klingt für mich interessant, weil ich z.Z. auch mal wieder am bauen bin: Jeder Request erzeugt ein Responseobjekt, genau wie bei Dir. Meine Responseobjekte bekommen jetzt per Konfiguration jeweils eine Klasse zugewiesen, jede dieser Klassen ist eine Subklasse und erbt die Methoden einer Basisklasse.

Overload gibt mir nun die Möglichkeit, bestimmte Methoden der Basisklasse zu überschreiben, das sind bei mir namentlich diese beiden hier:

browse():  Wird aufgerufen, wenn keine Parameter vorhanden sind
control(): Wird aufgerufen, wenn es POST oder GET Parameter gibt

Ohne Overload werden browse() oder control() der Basisklasse aufgerufen, sofern es die angeforderte Ressource (Responseklasse) gibt, wird die ausgeliefert, ansonsten erzeugen browse() oder control() den HTTP-Status 404.

Mit Overload (browse, control sind in der Responseklasse vorhanden) können diese Methoden alles mögliche tun, hauptsächlich werden die Platzhalter im Response-Template mit Werten bestückt, insbesondere control() ist zum Verarbeiten der Benutzereingaben zuständig und es sind auch Exceptions erlaubt.

Meine Methode response(), in der Basisklasse definiert, gibt schließlich Header und Content beliebiger Content-Types aus, in Methode response() werden auch die Berechtigungen geprüft, diese Prüfung und die Prüfung auf Exceptions in der Responseklasse ist alles ein Aufwasch ;)

Es hört sich anfangs ein bischen kompliziert an, aber was dabei herauskommt, ist an Einfachkeit nicht mehr zu übertreffen, der Code wird außerordentlich überschaubar und egal ob in Einzel- oder Teamarbeit sind komplexe Webanwendungen ratz-fatz programmiert.

Hotti

[Tom]

Hello,

HTTP mit PHP ist schon ein "requestbasiertes OOP", da muss man nicht noch in jedem Fall eins draufsetzen. Jeder Request ist ein Objekt. Wenn PHP es endlich ermöglichen würde, auch Startobjekte zu deklarieren und ggf. auch zu definieren, dann hätte ich gegen OOP nichts mehr einzuwenden.

Was meinst Du mit 'Startobjekt'?

Hmm, was Du schreibst, klingt für mich interessant, weil ich z.Z. auch mal wieder am bauen bin: Jeder Request erzeugt ein Responseobjekt, genau wie bei Dir. Meine Responseobjekte bekommen jetzt per Konfiguration jeweils eine Klasse zugewiesen, jede dieser Klassen ist eine Subklasse und erbt die Methoden einer Basisklasse.

Zuerst erzeugt ein Request ja mal ein Request-Objekt. Dieses entscheidet dann darüber, welche Art von Response-Objekt erzeugt werden muss und ob es parrallel dazu auf dem Server irgendwelche Aktionen/Persistenzen geben muss.

In PHP geht es mir nun darum, das Environment des Reequest-Objektes gezielt zu beieinflussen.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[hotti]

hi,

Dein ursprünglicher POST hat mich dazu veranlasst, eine Alternative zu einem vermeintlichen 'Startobjekt' aufzuzeigen (Vererbung vs. Globalvars).

In PHP geht es mir nun darum, das Environment des Reequest-Objektes gezielt zu beieinflussen.

Overload: Die Erbschaft (Attribute, Methoden) in der Responseklasse überschreiben.

Hotti

[Steffen]

Hi,

und wie wäre es mit einer Request-Klasse als ein Singleton?

8<--

Request::getInstance(); // gibt immer das selbe Objekt zurück  

8<--

Grüße

• Steffen

[jobo]

Hallo,

8<--

Request::getInstance(); // gibt immer das selbe Objekt zurück

> 8<--  
  
<http://framework.zend.com/manual/de/zend.controller.front.html>  
  
Gruß  
  
jobo

[dedlfix]

Tach!

Was willst Du überhaupt erreichen? Ganz bestimmt gibt es für das, was Du bewirken willst, das eine oder andere Muster, das Du verwenden kannst. Jeder Weg (gegebenenfalls der Umstieg auf eine andere Programmiersprache) ist vermutlich sinnvoller als der von Dir in diesem Thread ins Auge gefasste ...

Eben nicht wirklich. Dann wäre ich wirlich gezwungen, OOP anzuwenden. Das will ich aber gar nicht.

Beantworte doch bitte Vinzenz' Frage nach dem eigentlichen Ziel. Es besteht derzeit noch gar kein ersichtlicher Grund, die OOP ins Spiel zu bringen. Über $GLOBALS jedenfalls hast du superglobalen Zugriff auf alle gloable Variablen. Aber globales Zeug will man eigentlich nicht, außer in sehr übersichtlichen kleinen Scripten.

dedlfix.

[Multi]

Wenn du das unbedingt willst und mit $GLOBALS, Konstanten oder mit statischen Funktionen nicht hinkommst, empfehle ich dir, eine Erweiterung für PHP zu schreiben. Dann muss aber dl()auf dem Server erlaubt sein oder du brauchst Zugriff auf die php.ini

Direkt im PHP-Source würde ich das nicht verankern, da, wie angesprochen, massive Nachteile dabei sind (Paketmanager, manuelles kompilieren).

Allerdings halte ich dein Vorhaben für einen Rückschritt, immerhin ist es ein grosser Vorteil, dass Namespaces und lokale Variablen eingeführt wurden. Du maschst mit deinem Vorhaben programmiertechnisch einen Rückschritt von ca. 10 Jahrenwürd ich schätzen.

[jobo]

Hallo,

Hello,

könnte man in PHP eigentlich weitere (eigene) superglobale Arrays definieren?

???

  
<?php  
class MyGlobal {  
	public static $myVar = array();  
}  
MyGlobal::$myVar["foo"] = "fooval";  
function globalUse() {  
	var_dump(MyGlobal::$myVar);  
}	  
globalUse();  

Naja, und neuerdings gibts ja auch Namespaces, was die Angelegenheit noch einfacher machen sollte ...;

Gruß

jobo