__set() verhindern das erzeugen einer neuen Variablen - Seite 2

shocky · 21.10.2006, 16:02

Zitat:

Zitat von xabbuh

Abgesehen davon, dass ich __set() ebenfalls für eher schlecht halte, suchst du vermutlich get_class_vars():

PHP-Code:

  public function __set($name, $value)

{

    if(in_array($name, get_class_vars(get_class($this))) {

        $this->$name = $value;

    }

}

das ists Danke

xabbuh · 21.10.2006, 16:08

Zitat:

Zitat von Basti

...müsste array_key_exists() anstatt in_array() sein, da die Property-Namen die Schlüssel im Array sind.

Hast Recht, Code geändert...

Basti · 21.10.2006, 16:26

Zitat:

Zitat von shocky

Zitat:

Warum setzt du die Vars nicht gleich auf public?

weil ich soo besser kontrolieren kann welche werte reinkommen.
Bsp. : ein Vorname darf keine zahlen enthalten!
Dies kann ich abfangen und eine Exception aufwerfen falls jemand eine zahl speichert ! :wink:

Das stimmt natürlich. Bei meinen Datenobjekten (die übrigens auch überladen sind, aber weil die Attribute intern in Datatype-Objekten gespeichert werden, die aber nach außen nicht direkt sichtbar sein sollen) kannst du reinhauen, was du willst und erst bei einem expliziten Aufruf von isValid() oder implizit über getErrors() oder save() wird festgestellt, dass da womöglich was nicht stimmt.

Ist dort aber natürlich auch so angebracht, da die "karputten" DataObjects ja wiederum z.B. die Formulare speisen, in denen sich der Benutzer verbessern soll.

Basti

shocky · 21.10.2006, 18:17

joa das kann man natürlich soo sehen!

Ich versuche es aber immer schon bereits bevor die daten gespeichert werden dies zu überprühfen ( ne angewohnheit von c# ) obwohl das mir jetzt echt zu schaffen mach obs den sinnvoll ist bei ner scriptsprache wie PHP.
Denn das Script wird abgearbeitet und dann ists vorbei und dazwischen irgendwo kann man ja nicht einfach mal ein fenster aufgehen lassen das sagt bitte nur buchstaben eingeben

Ich muss sagen du bringst meine heille welt gerade einbischen durcheinander

shocky · 21.10.2006, 18:23

Aber warte mal soo habe ich doch ebenfalls eine gute möglichkeit die eingabe zu testen!!!

ich nehme dann ein Attribut wie $IsValid was beim jeden __set dan den entsprechenden wert krigt (true oder false ) ( muss natürlich im set ne fallunterscheidung machen zwischen den verschiedenen Vars) dann muss ich später nur noch IsValid abfragen und weis schon obs verarbeitet werden kann

Basti · 21.10.2006, 19:13

Hi.

Also zumindest, was Datenobjekte angeht, macht es in jedem Fall Sinn, auch invalide Objekte zuzulassen und ich würde das nicht in __get() eruieren, sondern ratsächlich erst dann, wenn der Wert (ob vlide oder nicht) benötigt wird.

PHP-Code:

  <?php

 
class EditPageAction extends FormAction

{

    protected $Page;

 
    public function __construct()

    {

        parent::__construct();

 
        $iId = (int) $this->Request->get('page', 'id');

        $this->Page = $this->Persistence->get('Page', $iId);

    }

 
    public function execute()

    {

        if (is_null($this->Page))

            return $this->createBadRequestResult();

 
        $this->setView('EditPageForm');

 
        return $this->success();

    }

 
    public function onPostback()

    {

        $this->Page->update($Request->get('page'));

 
        if (!this->Page->isValid()) {

 
            $this->setView('EditPageForm');

            return $this->success();

        }

 
        $this->Page->save();

        return $this->reditect(...);

    }

}

 
?>

In der View braucht dann nurnoch auf ein Objekt ($Page) zugegriffen werden, dass sowohl die Daten enthält (DB-Daten, teilweise überschrieben durch den Request), als auch z.B. auf die Fehler, die im Objekt gespeichert sind und in eine Fehlermeldung umgemüznt werden können. Andernfalls müsste in der View ja immernoch auch der Request abgefragt werden, ...

Ein anderer Grund ist der, dass ein neu gebautes Objekt (das nicht aus der Datenbank kommt, sondern gerade angelegt werden soll) zu Beginn ja definitiv nicht valide ist. Es wäre ja unvollständig, jetzt bei jedem Einfügen eines neuen Attribut-Wertes die Validität nur dieses Attributes zu prüfen und davon auf die Validität des gesamten Objektes zu schließen.

Auch wenig sinnvoll, bei jeder kleinen Veränderung das komplette Objekt zu validieren (alle Property-Objekte, sowie ggf. Fremdschlüssel etc.).

Vor dem Speichern zu prüfen ist eh ein Muss (was ja nichts mit der Programmiersprahe zu tun hat). Es geht ja nur um die Defintion, um was für ein Objekt es sich hier handelt: Ein immer valides Datenobjekt (hier bräuchte es eben noch eine weitere Klasse für unvollstänige Objekt - z.B. auch nur, um einen Wizard gut umsetzen zu können, mit dem ein Objekt in mehreren Schritten/Formularen erzeugt wird) oder eben was unvollständiges, was sich eben nur speichern läss, wenn es vollständig ist.

Basti

shocky · 30.10.2006, 12:16

Sorry für die späte antwort!

Also ich muss zugeben das ich in der OOP welt neu bin aber ich verstehe nicht warum ich den einen Wert speichern soll ( <-- hier meine ich mit speichern als ein Property setzen ) wenn ich es villeicht nicht brauchen werde?
Also wenn ich meine Propertys Setze dann brauche ich sie auch selbst wenn ich sie bei der deklaration auf null setze.
Dann ist es doch auch besser bereits beim setzen der Propertys (egal ob Datenobjekt oder nicht) zu gucken ob diese Valide sind. So habe ich doch auch eine klare trennung

Nachsehen Ob wert OK
Speichern im Property
Schreiben in eine DB oder ähnliches ...

Müsstest du den dann nicht verschiedene IsValid funktionen haben die für die unterschiedlichen Objekte sind?
Ich meine was ist wenn du ganz unterschiedliche werte hast?
So habe ich ja den unterschied bereits vorher und meine Propertys sind auf jeden fall sicher vor fehleingaben under auch fremdzugriff.

Also ich habe solche Kontrukte bis jetzt nur unter c# verwendet und da muss man für jeden Property auf den man den zugriff überwachen will ein get oder set schreiben das hat mich jetzt auch bei PHP verwirrt da hier plötzlich für alle Obejte nur eine get methode exestiert.
Mann müsste dann da drinne natürlich eine Fallunterscheidung machen um jeden Member anders verwalten zukönnen.

Oder man schreibt gleich sich methoden wie SetName(), SetAge usw... :wink:

Wie gesagt ich bin neu im OOP und das thema interesiert mich brennend dewegen sorry wen ich irgendwie undeutlich war oder ähnliches

Basti · 30.10.2006, 13:18

Wer sagt denn, dass du was speichern sollst,was du nicht brauchst? Im obigen Beispiel lade ich ein Datenobjekt Page aus der Datenbank und speichere dann, wenn das Formular zur Bearbeitug der Seite zurückgeschickt wurde, die Formularwerte in das Objekt. Entweder dieses ist jetzt valide, dann brache ich die Daten dort, um das Objekt speichern zu können ($this->Page->save()

oder es ist nicht valide, dann brauche ich die fehlerhaften Benutzereingaben ja auch, um dem Benutzer das Formular mit seinen Eingaben nochmal anzeigen zu können.

Die isValid()-Funktion der Basisklasse geht alle Property-Objekte durch. Das heißt, wenn $User ein Attribut E-Mail-Adresse hat, dann ist die Property User::EMail ein Objekt der Klasse EMail. Wenn der Wert darin falsch ist, dann gibt EMail::isValid() false zurück. Weiter lässt sich definieren, ob eine Property verlangt wird oder nicht. Hier prüft DataObject::isValid() noch, ob alle benötigten Properties auch einen Wert haben. Und, natürlich lässt sich diese Funtkion der Basisklasse im konkreten Datenobjekt erweitern, um sonstige tests durchzuführen (z.B. wenn Page vom Typ x darf Property y nicht den Wert z beinhalten).

Und ja, für jede Property explizit einen Setter und Getter (setName(), getName()) zu schreiben ist natürlich sauberer. Propel z.B. macht das - aber Propel generiert seine Klassen ja auch automatisch au XML-Files und ohne sowas ist das in meinen Augen vor allem mehr Schreibaufwand. Aber da gibts auch Verfechter, die vom Überladen in der Form sehr abraten - konnten mich aber bisher noc nicht überzeugen.

Letztlich gehts hier einfach nur um verschiedene Möglichkeiten mit unerschiedlichen Qualitäten, Vor- und Nachteilen und eben Grenzen. Was dann für dich taugt, dafür gibt es sicher keine pauschale Antwort.

In __set() die Validität zu überprüfen heißt Folgendes:

Entweder du prüfst nur den einen Wert:
Dann musst du invalide Daten abweisen, da diese ja das ganze Objekt invalide setzen würden und dieser Schritt nicht mehr Rückgängig zu machen wäre.

Oder du prüfst immer das ganze Objekt:
Hier könntest du invalide Daten aufnehmen; Allerdings wäre es unsinnig, die Validität dann bei jedem __set() zu prüfen anstatt eben nur bei der Abfrage, ob das Objektvalide ist;
Wenn du invalide Daten dennoch abweisen wolltest, bräuchtest du nicht das ganze Objekt zu überprüfen, denn die Invalidität würde sich eh nur aus der Property selbst ergeben. Regeln, die Beziehungen zwischen mehreren Properties beschrieben würden oder die Beziehung zwischen Objekt und Property (z.B. required) könntest du so ja eh nicht umsetzen.

Basti

shocky · 30.10.2006, 14:35

Aha ja das stimmt das ist echt nur dem programmierer überlassen welche methode er besser findet.
Mir macht da aber novh die sache sorgen das falls jemand anderes mit meinen Klassen arbeitet er ja immer die werte meiner Propertys setzen könnte wie er es will und villeicht baut er kein isValid ein dann hat er ein Problem wobei beim __set ich ja immer noch eine exception aufwerfen kann

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
Smarty/quickform: Variablen Namen dynamisch erzeugen ?	Toxo	HTML, Usability und Barrierefreiheit	1	31.10.2007 16:55
variablen aus textfile erzeugen (shellscript)	noskule	Server, Hosting und Workstations	2	19.07.2006 15:42
Variablen übergeben bzw. auslesen?		PHP Tipps 2005	4	30.01.2005 03:56


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

21.10.2006, 18:17
shocky Benutzer Registriert seit: 08.11.2004 Beiträge: 70	joa das kann man natürlich soo sehen! Ich versuche es aber immer schon bereits bevor die daten gespeichert werden dies zu überprühfen ( ne angewohnheit von c# ) obwohl das mir jetzt echt zu schaffen mach obs den sinnvoll ist bei ner scriptsprache wie PHP. Denn das Script wird abgearbeitet und dann ists vorbei und dazwischen irgendwo kann man ja nicht einfach mal ein fenster aufgehen lassen das sagt bitte nur buchstaben eingeben Ich muss sagen du bringst meine heille welt gerade einbischen durcheinander

21.10.2006, 18:23
shocky Benutzer Registriert seit: 08.11.2004 Beiträge: 70	Aber warte mal soo habe ich doch ebenfalls eine gute möglichkeit die eingabe zu testen!!! ich nehme dann ein Attribut wie $IsValid was beim jeden __set dan den entsprechenden wert krigt (true oder false ) ( muss natürlich im set ne fallunterscheidung machen zwischen den verschiedenen Vars) dann muss ich später nur noch IsValid abfragen und weis schon obs verarbeitet werden kann

21.10.2006, 19:13
Basti Erfahrener Benutzer Registriert seit: 18.07.2004 Beiträge: 2.162 PHP-Kenntnisse: Fortgeschritten	Hi. Also zumindest, was Datenobjekte angeht, macht es in jedem Fall Sinn, auch invalide Objekte zuzulassen und ich würde das nicht in __get() eruieren, sondern ratsächlich erst dann, wenn der Wert (ob vlide oder nicht) benötigt wird. PHP-Code: <?php class EditPageAction extends FormAction { protected $Page; public function __construct() { parent::__construct(); $iId = (int) $this->Request->get('page', 'id'); $this->Page = $this->Persistence->get('Page', $iId); } public function execute() { if (is_null($this->Page)) return $this->createBadRequestResult(); $this->setView('EditPageForm'); return $this->success(); } public function onPostback() { $this->Page->update($Request->get('page')); if (!this->Page->isValid()) { $this->setView('EditPageForm'); return $this->success(); } $this->Page->save(); return $this->reditect(...); } } ?> In der View braucht dann nurnoch auf ein Objekt ($Page) zugegriffen werden, dass sowohl die Daten enthält (DB-Daten, teilweise überschrieben durch den Request), als auch z.B. auf die Fehler, die im Objekt gespeichert sind und in eine Fehlermeldung umgemüznt werden können. Andernfalls müsste in der View ja immernoch auch der Request abgefragt werden, ... Ein anderer Grund ist der, dass ein neu gebautes Objekt (das nicht aus der Datenbank kommt, sondern gerade angelegt werden soll) zu Beginn ja definitiv nicht valide ist. Es wäre ja unvollständig, jetzt bei jedem Einfügen eines neuen Attribut-Wertes die Validität nur dieses Attributes zu prüfen und davon auf die Validität des gesamten Objektes zu schließen. Auch wenig sinnvoll, bei jeder kleinen Veränderung das komplette Objekt zu validieren (alle Property-Objekte, sowie ggf. Fremdschlüssel etc.). Vor dem Speichern zu prüfen ist eh ein Muss (was ja nichts mit der Programmiersprahe zu tun hat). Es geht ja nur um die Defintion, um was für ein Objekt es sich hier handelt: Ein immer valides Datenobjekt (hier bräuchte es eben noch eine weitere Klasse für unvollstänige Objekt - z.B. auch nur, um einen Wizard gut umsetzen zu können, mit dem ein Objekt in mehreren Schritten/Formularen erzeugt wird) oder eben was unvollständiges, was sich eben nur speichern läss, wenn es vollständig ist. Basti

30.10.2006, 12:16
shocky Benutzer Registriert seit: 08.11.2004 Beiträge: 70	Sorry für die späte antwort! Also ich muss zugeben das ich in der OOP welt neu bin aber ich verstehe nicht warum ich den einen Wert speichern soll ( <-- hier meine ich mit speichern als ein Property setzen ) wenn ich es villeicht nicht brauchen werde? Also wenn ich meine Propertys Setze dann brauche ich sie auch selbst wenn ich sie bei der deklaration auf null setze. Dann ist es doch auch besser bereits beim setzen der Propertys (egal ob Datenobjekt oder nicht) zu gucken ob diese Valide sind. So habe ich doch auch eine klare trennung Nachsehen Ob wert OK Speichern im Property Schreiben in eine DB oder ähnliches ... Müsstest du den dann nicht verschiedene IsValid funktionen haben die für die unterschiedlichen Objekte sind? Ich meine was ist wenn du ganz unterschiedliche werte hast? So habe ich ja den unterschied bereits vorher und meine Propertys sind auf jeden fall sicher vor fehleingaben under auch fremdzugriff. Also ich habe solche Kontrukte bis jetzt nur unter c# verwendet und da muss man für jeden Property auf den man den zugriff überwachen will ein get oder set schreiben das hat mich jetzt auch bei PHP verwirrt da hier plötzlich für alle Obejte nur eine get methode exestiert. Mann müsste dann da drinne natürlich eine Fallunterscheidung machen um jeden Member anders verwalten zukönnen. Oder man schreibt gleich sich methoden wie SetName(), SetAge usw... :wink: Wie gesagt ich bin neu im OOP und das thema interesiert mich brennend dewegen sorry wen ich irgendwie undeutlich war oder ähnliches

30.10.2006, 13:18
Basti Erfahrener Benutzer Registriert seit: 18.07.2004 Beiträge: 2.162 PHP-Kenntnisse: Fortgeschritten	Wer sagt denn, dass du was speichern sollst,was du nicht brauchst? Im obigen Beispiel lade ich ein Datenobjekt Page aus der Datenbank und speichere dann, wenn das Formular zur Bearbeitug der Seite zurückgeschickt wurde, die Formularwerte in das Objekt. Entweder dieses ist jetzt valide, dann brache ich die Daten dort, um das Objekt speichern zu können ($this->Page->save() oder es ist nicht valide, dann brauche ich die fehlerhaften Benutzereingaben ja auch, um dem Benutzer das Formular mit seinen Eingaben nochmal anzeigen zu können. Die isValid()-Funktion der Basisklasse geht alle Property-Objekte durch. Das heißt, wenn $User ein Attribut E-Mail-Adresse hat, dann ist die Property User::EMail ein Objekt der Klasse EMail. Wenn der Wert darin falsch ist, dann gibt EMail::isValid() false zurück. Weiter lässt sich definieren, ob eine Property verlangt wird oder nicht. Hier prüft DataObject::isValid() noch, ob alle benötigten Properties auch einen Wert haben. Und, natürlich lässt sich diese Funtkion der Basisklasse im konkreten Datenobjekt erweitern, um sonstige tests durchzuführen (z.B. wenn Page vom Typ x darf Property y nicht den Wert z beinhalten). Und ja, für jede Property explizit einen Setter und Getter (setName(), getName()) zu schreiben ist natürlich sauberer. Propel z.B. macht das - aber Propel generiert seine Klassen ja auch automatisch au XML-Files und ohne sowas ist das in meinen Augen vor allem mehr Schreibaufwand. Aber da gibts auch Verfechter, die vom Überladen in der Form sehr abraten - konnten mich aber bisher noc nicht überzeugen. Letztlich gehts hier einfach nur um verschiedene Möglichkeiten mit unerschiedlichen Qualitäten, Vor- und Nachteilen und eben Grenzen. Was dann für dich taugt, dafür gibt es sicher keine pauschale Antwort. In __set() die Validität zu überprüfen heißt Folgendes: Entweder du prüfst nur den einen Wert: Dann musst du invalide Daten abweisen, da diese ja das ganze Objekt invalide setzen würden und dieser Schritt nicht mehr Rückgängig zu machen wäre. Oder du prüfst immer das ganze Objekt: Hier könntest du invalide Daten aufnehmen; Allerdings wäre es unsinnig, die Validität dann bei jedem __set() zu prüfen anstatt eben nur bei der Abfrage, ob das Objektvalide ist; Wenn du invalide Daten dennoch abweisen wolltest, bräuchtest du nicht das ganze Objekt zu überprüfen, denn die Invalidität würde sich eh nur aus der Property selbst ergeben. Regeln, die Beziehungen zwischen mehreren Properties beschrieben würden oder die Beziehung zwischen Objekt und Property (z.B. required) könntest du so ja eh nicht umsetzen. Basti

30.10.2006, 14:35
shocky Benutzer Registriert seit: 08.11.2004 Beiträge: 70	Aha ja das stimmt das ist echt nur dem programmierer überlassen welche methode er besser findet. Mir macht da aber novh die sache sorgen das falls jemand anderes mit meinen Klassen arbeitet er ja immer die werte meiner Propertys setzen könnte wie er es will und villeicht baut er kein isValid ein dann hat er ein Problem wobei beim __set ich ja immer noch eine exception aufwerfen kann