Seite 1 von 1

Namesräume für Variabeln in Modulen

Verfasst: So 30. Jul 2006, 18:39
von MyAccount
Hallo liebe Community,

mal ein ganz anderes Thema. Ich hab mir bei meinen allerersten PHP-Projekte angewöhnt sicherzustellen, dass die Werte meiner Variabeln auch daher kommen, wo ich diese auch her haben will.

Das hab ich zumeist so gemacht:

Code: Alles auswählen

$foo = isset($_GET['foo']) ? $_GET['foo'] : false;
Warum braucht man diese Abfrage bei z.B. folgender Zeile aus dem Modul Hilfsnavigation des Demo-Mandanten nicht mehr?

Code: Alles auswählen

$catStart = "CMS_VALUE[0]";
Nach dem Motto...

Code: Alles auswählen

$catStart = isset($_WASDENNBITTE['catStart']) ? $_WASDENNBITTE['catStart'] : false; 
:D Ja, welcher Namensraum ist es denn?

Verfasst: So 30. Jul 2006, 19:11
von stese
ich verstehe dich nicht. was ist denn jetzt die frage? welche namensräume du nutzen sollst? was das beste ist? ich verstehe vor allem nicht, wie dein zweites codebeispiel mit dem dritten in zusammenhang steht.

meine namensräume der variablen setzen sich mittlerweile immer so zusammen, dass ich ein dreistelliges kürzel mit dem variablentyp habe und danach was in der variable drinnen ist. also z.b. $strContentHeadline oder $intCounter oder $objXMLObject oder $arrListRow ... das ist einer von einer handvoll quasi standards bei namensräumen, der sehr oft in projekten zu finden ist. daher passt man sich eigentlich daran an.

in einigen Modulen verwende ich auch die namensräume von contenido, vermeide es aber bei komplexen geschichten, damit meine namensräume nicht in kollision mit vorhandenen variablen kommen

Verfasst: So 30. Jul 2006, 20:40
von kummer
wenn du objektorientiert arbeitest, hast du das problem eigentlich schon gelöst. mindestens für die member (variablen) innnerhalb des objekts. du hast dann noch genau eine variable für dein objekt. da stellt sich die frage berechtigterweise. allerdings ist der schaden gering - genau genommen null - wenn du in einem anderen modul, welches früher oder später ausgeführt wird, denselben bezeichner nochmals verwendest.

Verfasst: So 30. Jul 2006, 20:54
von MyAccount
Mit Namensräumen meine ich nicht die Art und Weise wie ich meine Variablen benennen.

Die zweite Zeile ist genauso im Hilfnavigations-Modul enthalten. Meine Frage war, welcher Namensbereich das ist. Ich vermute mal, dass das eine stinknormale globale Variable ist.

OK, das mit dem $_GET war unglücklich gewählt. Nehmen wir z.B. mal ein E-Mail-Kontaktforumular. Wenn ich sichergehen will, dass die Daten wirklich aus dem Formular kommen und nicht etwa in die URL eingegeben wurden (form.php?name=fritz&mail=nuss@hallo.com), dann prüfe ich halt nach $_POST.

Es geht mir darum, ob jemand von außen (also über HTTP) meine Variable $catStart überschreiben kann. Bei PHP hat jede function() ihren eigenen Namensraum. Wie ist es mit der $catStart?

Verfasst: So 30. Jul 2006, 20:59
von kummer
das kommt darauf an, ob du register globals auf on gesetzt hast. wenn ja, dann wird jemand das über get oder post setzen können, sofern es durch den code nicht wieder überschrieben wird. das ist ja dann wohl unvermeidlich.

häufiger allerdings dürfte sein, dass ein zuvor ausgeführtes modul die variable verändert hat. das kommt je nach modul halt schon mal vor.

Verfasst: So 30. Jul 2006, 21:03
von MyAccount
register globals ist on und safe mode ist off :cry: und nu?

Verfasst: So 30. Jul 2006, 21:04
von stese
... daher werden variablen, bei denen man sicherstellen muss, dass die inhalte verifiziert sind, am anfang des moduls neu initialisiert.

und auch hier lässt sich das versehentliche überschreiben (ob von außen oder innen) zumindestens teilweise sicherstellen, in dem man, wie kummer schon sagte, objektorientiert arbeitet.

Verfasst: So 30. Jul 2006, 21:42
von MyAccount
Objektorientiert?

Aus dem hier:

Code: Alles auswählen

$catStart = "CMS_VALUE[0]";
Dann das hier machen.

Code: Alles auswählen

class catStart {
  var $catStart = "CMS_VALUE[0]";
}


$objCatStart = new catStart;
Ist das nicht mit Kanonen auf Spatzen geschossen?

Verfasst: So 30. Jul 2006, 21:55
von stese
wenn du NUR ein CMS_TEXT oder CMS_HTML ausgeben willst, brauchst du das alles nicht.

da reicht ja ein

Code: Alles auswählen

echo "CMS_HTML[0]";
auch das initialisieren funktioniert ähnlich:

Code: Alles auswählen

$strText = "CMS_HTML[0]";
damit wird $strText auf den wert aus der Datenbank des CMS_HTML[0] Typs zurückgesetzt. alle vorher evtl. in der variablen $strText gespeicherten inhalte sind damit überschrieben.

wenn du jetzt noch andere funktionen oder umfangreichere befehle abzuarbeiten hast über den inhalt, werden die am besten objektorientiert, also in einer klasse abgearbeitet.

(PHP4 Stil:)

Code: Alles auswählen

class meineKlasse {
   var $meineVar;

   /* constructor */
   function meineKlasse($strInhalt) {
       $this->meineVar = $strInhalt;
   }

   function macheIrgendwas() {
       // hier sind irgendwelche geschichten drinnen, die was ändern. z.b. preg_replace befehle
      return $this->meineVar;
   }
}
und der aufruf:

Code: Alles auswählen

$strText = "CMS_HTML[0]";
$objMeineKlasse = new meineKlasse($strText);
print $objMeineKlasse->macheIrgendwas();
damit kann man die module auch klein halten, und die klassen in seperaten dateien ablegen, die man bequemer bearbeiten kann.

Verfasst: So 30. Jul 2006, 22:21
von MyAccount
Alles klar. Das hab ich bisher auch so gemacht. In der Hauptnavigation z.B. sind das überwiegend Funktionen. Das sollte aber wegen des eigenen Namensraums auch OK sein?!

Danke und Gute Nacht
MyAccount