Delphi-PRAXiS
Seite 7 von 8   « Erste     567 8      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Programmieren allgemein (https://www.delphipraxis.net/40-programmieren-allgemein/)
-   -   PHP - sind hier "Sicherheitsexperten" an Board? (https://www.delphipraxis.net/152621-php-sind-hier-sicherheitsexperten-board.html)

Mithrandir 7. Jul 2010 13:44

AW: PHP - sind hier "Sicherheitsexperten" an Board?
 
Kleines OT:

Himi,

mit [CODE=PHP] kannst du deinen PHP-Code entsprechend highlighten. Das sieht dann deutlich besser aus... Aber das nur am Rande. :stupid:

himitsu 16. Jul 2010 23:25

AW: PHP - sind hier "Sicherheitsexperten" an Board?
 
Bin ich nur zu doof, oder steht wirklich nirgends, daß man von MultiQuerys (mysqli) unbedingt die Results auslesen muß, damit die nächste Query nicht mit 'nem Fehler abbricht?

Zitat:

Commands out of sync; you can't run this command now
Hab 'ne ganze Weile gebraucht, bis ich rausbekam, daß es daran liegt und nicht an der nachfolgenden Query. :wall:

Denn, wenn ich jetzt
PHP-Quellcode:
while ($this->more_results() && $this->next_result());
nach der MultiQuery einfüge (mich interessieren die Einzelergebnisse eigentlich nicht), dann funktioniert es plötzlich.

wicht 16. Jul 2010 23:58

AW: PHP - sind hier "Sicherheitsexperten" an Board?
 
Ich werde jetzt vermutlich von einigen Menschen auf den Deckel bekommen und einiges an Reputation verlieren, sofern vorhanden, aber ich kann es mir nach der Fadenlänge nicht mehr verkneifen...

http://www.steike.com/code/php-must-die/

Aber um wenigstens ein bisschen was beizutragen, man sollte vielleicht das nächste mal ein paar Frameworks evaluieren, bevor man ein Projekt startet. Ich mag PHP nicht (mehr) und nutze für meine Webseiten nur noch Python und Django, aber ich denke, dass es Frameworks für PHP gibt, die einem diese ganzen Probleme, die von dir hier in diesem Thread beschrieben wurden, wenigstens teilweise schon vorher abnehmen.
Versteh mich nicht falsch, ich habe auch lange mit PHP entwickelt und möchte hier nicht rumpöbeln oder so, aber ich kam dabei am Ende auch auf ein selbst gebautes Framework, womit ich drei Webseiten betrieben habe, quasi aus den selben Quellen, und weil es solche Frameworks schon gibt, denke ich, dass man sich da sehr viel Arbeit hätte ersparen können...

Gutes Nächtle..

Mithrandir 17. Jul 2010 07:25

AW: PHP - sind hier "Sicherheitsexperten" an Board?
 
Zitat:

Zitat von wicht (Beitrag 1035783)
[..] und einiges an Reputation verlieren [..]

Welche Reputation? :mrgreen:


Der Inhalt des Artikels ist natürlich nicht verkehrt, aber der Titel klingt doch sehr - polemisch. ;)

himitsu 20. Jul 2010 12:50

AW: PHP - sind hier "Sicherheitsexperten" an Board?
 
Hätte da noch eine Verständnisfrage.

Ich weiß zwar, daß es so richtig ist, aber ich versteh nicht ganz warum.
Es steht auch überall erklart, daß man es so macht ... nur halt immer ohne Begründung.

Es geht um überschriebene Methoden und den Aufruf der Originals (quasi delphis Inherited)
PHP-Quellcode:
function MyMethod() {
  ...
  parent::MyMethod();
}
Im Grunde ist es ja so:
PHP-Quellcode:
Class::StaticMethod();
Object->Method();
, also müßte ich doch theoretisch eigentlich parent->MyMethod(); aufrufen? :gruebel:

Für die eigene Klasse gibt es ja auch
PHP-Quellcode:
self::StaticMethod();
und
PHP-Quellcode:
$this->Method();
,
aber für parent:: scheint es kein $parent-> oder Ähnliches zu geben.

Nja, es funktioniert ja, egal ob die Methode nun statisch ist oder nicht,
aber ich find's einfach nicht logisch.

alcaeus 20. Jul 2010 17:40

AW: PHP - sind hier "Sicherheitsexperten" an Board?
 
Willkommen in der Welt von PHP. Da ist schon mehr unlogisch.
Aber ja, der Aufruf einer Funktion der Parent-Klasse wird mit parent::foo() erledigt. Dies gilt allerdings nur, wenn du foo() ueberschrieben hast und das Original aufrufen willst. Alle anderen Faelle kannst du mit $this->foo() abdecken.

Greetz
alcaeus

PS: ich weiss nicht was passiert wenn du parent::foo() ausserhalb von foo() aufrufst. Wenn du das machen musst, solltest du schleunigst den Code schreddern und von vorne anfangen.

himitsu 20. Jul 2010 18:37

AW: PHP - sind hier "Sicherheitsexperten" an Board?
 
Zitat:

Zitat von alcaeus (Beitrag 1036448)
Aber ja, der Aufruf einer Funktion der Parent-Klasse wird mit parent::foo() erledigt. Dies gilt allerdings nur, wenn du foo() ueberschrieben hast und das Original aufrufen willst. Alle anderen Faelle kannst du mit $this->foo() abdecken.

Das ist schon klar und für genau für solche Fälle nutze ich es auch.

hab ja nun 'ne Menge OOP-Zeugs und vorallem Vererbung verbaut,
da ist sowas ja wohl nützlich/angebracht :angel:

Zitat:

Zitat von alcaeus (Beitrag 1036448)
PS: ich weiss nicht was passiert wenn du parent::foo() ausserhalb von foo() aufrufst.

also ich kann auch in "bar" parent::foo() aufrufen (wenn Beide oder mindestens foo überschrieben sind)

schon komisch, daß alle Foo/Bar für ihre Beispiele nutzen :lol:

himitsu 21. Jul 2010 10:46

AW: PHP - sind hier "Sicherheitsexperten" an Board?
 
Liste der Anhänge anzeigen (Anzahl: 1)
Wie gesagt, extrem schnelle Ausführungsgeschwindigkeiten werd ich wohl eh nicht, für meine Zwecke, benötigen.

Ich glaub ich hab jetzt meine MySQL-Klasse soweit umgestellt, so daß jetzt MySQLi verwendet wird und dazu auch noch die prepared Statements (oder wie auch immer die nochmal heißen) verwendet werden.

In meinem Query sind jetzt prepare+bind_param+execute, multi_query und das normale query gekapselt und werden automatisch ausgewählt.
Wobei query hierbei ein real_query mit einem speziellem store_result sind, damit die Result-Klasse ausgetauscht werden kann,
welche dann das free_result automatisch aufruft, wenn das Result-Objekt freigegeben wird.

Hab nun auch mal angefangen dieses PHPDoc zu verwenden.
(das macht sich, z.B. bei der Autovervolständigung in NetBeans, richtig gut :-D)

also mir gefällt's so schon irgendwie
und aus diesem
PHP-Quellcode:
$Var1 = 'abc';
$Var2 = 123;
//$Result = $DB->Query('INSERT INTO `#PrefixMyTable` (`Field1`, `Field2`) VALUES (?, ?)',
//  array($Var1, $Var2), array('#Prefix' => 'xxx'));
# das #Prefix ist schon vordefiniert enthalten
$Result = $DB->Query('INSERT INTO `#PrefixMyTable` (`Field1`, `Field2`) VALUES (?, ?)', array($Var1, $Var2));
wird dann intern das gemacht
PHP-Quellcode:
$Var1 = 'abc';
$Var2 = 123;
$State = $DB->prepare('INSERT INTO `xxxMyTable` (`Field1`, `Field2`) VALUES (?, ?)');
$State->bind_param('si', $Var1, $Var2);
$Result = $State->execute();
wobei es auch so ginge :angel:
PHP-Quellcode:
$Var1 = 'abc';
$Result = $DB->Insert('MyTable', array('Field1' => $Var1, 'Field2' => 123));
Bei diesem Preparedzeugs fehlte mir etwas, womit man auch mal normalen Text einfügen kann und nicht nur ganze Parameter.



Auch wenn's böse aussieht, fand es so letztendlich aber einfacher ... im __construct hol ich die Configuration nun direkt aus einem Config-Objekt, anstatt diese weiterhin via Parameter zu übergeben.

generic 21. Jul 2010 12:49

AW: PHP - sind hier "Sicherheitsexperten" an Board?
 
Warum nimmst du nicht einfach ein fertiges Framework wie z.B. Zend.
Bei Zend kann man auch nur einzelne Klassen nutzen, wie die ZendDB.

himitsu 21. Jul 2010 13:09

AW: PHP - sind hier "Sicherheitsexperten" an Board?
 
Hatte damals (ist bestimmt schon 2 Jahre her) mal in Zend reingeguckt ... und dachte das kann man nur komplett nutzen, bzw daß es nicht so einfach wäre, da auch mal nur eine einzelne Klasse rauszunehmen.

nja, muß jetzt nur noch ein paar "Kleinigkeiten" in meinen Basisklassen (also meinem Framework) an die neue DB-Klasse anpassen,
dann fehlt noch die Umstellung der Cache und der Templatte-Klasse, dann das Grundsystem/Framework hoffentlich fertig :)

Und nebenbei hab ich dadurch auch noch vieles Neues (mehr OOP, Vererbung, Autoloader, PHPDoc) gelernt. :stupid:

'nen "kleines" Framework, welches mir gefällt und vorallem womit ich auch zurechtkomme fand ich auch nicht.


Alle Zeitangaben in WEZ +1. Es ist jetzt 17:06 Uhr.
Seite 7 von 8   « Erste     567 8      

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz