Új hozzászólás Aktív témák

• #15503 mallee tag DNReNTi #15495

  Új Válasz 2014-04-13 23:20:07 #15503

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  mallee

  tag

  válasz DNReNTi #15495 üzenetére

  Upsz, erről megfeledkeztem Majd holnap megkapod

• #15488 mallee tag Speeedfire #15486

  Új Válasz 2014-04-08 13:18:50 #15488

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  mallee

  tag

  válasz Speeedfire #15486 üzenetére

  Tudsz mondani olyan esetet, ahol az addslashes jó?

• #15485 mallee tag Speeedfire #15484

  Új Válasz 2014-04-08 13:00:20 #15485

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  mallee

  tag

  válasz Speeedfire #15484 üzenetére

  Adatbázisos escapeléshez a prepared statement-ek valóak, de jó még a mysql_real_escape_string() is. Cookienál nincs mit escapelni. XSS támadás szűréséhez pedig megint más megoldások vannak.

• #15483 mallee tag DNReNTi #15478

  Új Válasz 2014-04-08 11:39:10 #15483

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  mallee

  tag

  válasz DNReNTi #15478 üzenetére

  Egy kicsit kritizálok, ha nem baj

  Configuration
  Az osztálynak van konstruktora, amely az általad linkelt kódokban sehol sem kerül meghívásra. Ezenfelül csak statikus változót és metódust tartalmaz, nem értem a szándékodat. Vagy legyen statikus osztály (inkább ne) vagy ne legyen az (inkább ez).

  Database_Connection
  Továbbra is végez felesleges dolgokat, lásd ini_set. És hiába nem akarod, hogy belekössünk, bele fogunk A display_errors amúgy is legyen kikapcsolva, a hibákat nem kiíratni kell, hanem loggolni.
  A die() helyett hagyd az exception-t "felbuborékozni" és egy másik szinten kezeld le a hibaoldalt.

  Database
  őőő, ez így nem az igazi szerintem. De majd később kifejtem.

  Amúgy összességében jó irányban halad a dolog, de még sokat kell ezen dolgozni

• #15482 mallee tag Speeedfire #15462

  Új Válasz 2014-04-08 11:23:26 #15482

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  mallee

  tag

  válasz Speeedfire #15462 üzenetére

  addslashes? Semmi értelme, haszontalan.

• #15445 mallee tag PumpkinSeed #15444

  Új Válasz 2014-04-05 13:52:44 #15445

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  mallee

  tag

  válasz PumpkinSeed #15444 üzenetére

  Mit értesz biztonságos alatt? Amúgy bármilyen webről jövő adatot nem biztonságosnak kell tekinteni.

• #15439 mallee tag DNReNTi #15427

  Új Válasz 2014-04-04 12:36:50 #15439

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  mallee

  tag

  válasz DNReNTi #15427 üzenetére

  de ha ez az osztály nem a root-ban hanem egy almappában kerül meghívásra
  Hirtelen ezek a megoldások jutottak eszembe erre:
  1. Használj autoload-ot és a konfigurációs beállításokat egy osztályba tedd, pl Config_Database. Ez még mindig nem szép megoldás, de a problémát feloldja.
  2. Biztos van valamilyen inicializáló, közös része az alkalmazásodnak, ahol be tudod olvasni a konfigurációt és be tudod állítani a Database_Connection statikus mezőit. Ehhez azonban a láthatóságot át kell állítanod. Ez már egy egészen jópofa megoldás kezd lenni, viszont ebben az esetben koncepcionálisan rossz a Database_Connection osztályod.
  3. Van egy osztályod, ami a konfigurációt kezeli (beolvassa a megfelelő helyről) és tőle lekérdezi a Database_Connection osztály a megfelelő értékeket. Ez már szép megoldás is lehet, megvalósítástól függ.
  4. Van valamilyen osztályod, amely a függőségeket kezeli, pl eltárolja a Database objektum referenciáját és ahol adatbázissal akarsz foglalkozni, ott ettől az osztálytól kérdezed le a Database objektum referenciáját. Ennek egy nagy hibája, hogy eléggé központosított lesz a kód, túlzottan erős lesz a szerepe ennek az osztálynak, minden tőle fog függeni.

  Úgy gondoltam egy osztály marad a lekérdezések kezelésére, csak több metódus lesz. Lesz egy private, ami ellenőrzi a lekérdezés helyességét, a paramétereket, stb, valamint query típusonként 1-1 metódus.
  Ez elég szép megoldásnak hangzik

  A többit már elmondták előttem, várjuk az új verziót

• #15423 mallee tag fordfairlane #15420

  Új Válasz 2014-04-03 22:40:17 #15423

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  mallee

  tag

  válasz fordfairlane #15420 üzenetére

  Helyesen az ilyen kreátor objektumoknak az általad felvázolt módon sem lenne szabadna létezniük, helyette minden objektum kívülről várná a függőségeinek "kielégítését": bővebben.

• #15418 mallee tag csabyka666 #15417

  Új Válasz 2014-04-03 22:08:39 #15418

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  mallee

  tag

  válasz csabyka666 #15417 üzenetére

  Érzésem szerint az index.php minden újratöltéskor lefut.

  Ha mindig lefut, akkor elég ennek az egy fájlnak a tetején létrehozni a kapcsolatot.

• #15416 mallee tag DNReNTi #15412

  Új Válasz 2014-04-03 21:35:56 #15416

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  mallee

  tag

  válasz DNReNTi #15412 üzenetére

  Gondolatébresztők:

  Database_Connection

  private static $DB_Host = ........: Ennek a helye egy config fájlban lenne és valamilyen okosság mentén kéne beadni az osztályodnak.

  error_reporting(0);: Miért kezel az adatbázis osztályod error reportolást? Mi köze van a kettőnek egymáshoz? (azon túl, hogy az adatbázis-kapcsolat felépítése esetén is jöhet hiba). Ennek inkább egy inicializáló, környezetet beállító, stb php-ben kellene lennie

  echo 'Database connection failed. Code : ' . $DB_Connect->....; Ha csak kiírsz egy üzenetet a képernyőre, attól az alkalmazásod még fut tovább, noha ő arra számított, hogy lesz adatbázis-hozzáférése. Ehelyett használj exception-t

  Mi volt ezzel az osztállyal a célod? Hány helyen és hol hívod meg?

  Database
  Hát ez így nagyon nem jó. Több kisebb osztályba kéne szétvágni az executeSQL-t az SQL parancs típusok alapján, pl Database_Select_SQL valósítaná meg a selectes logikákat, Database_Insert_SQL az inserteset, stb. Ezzel elkerülhetnéd azt a csúnya és nehezen értelmezhető switch-case szerkezetet. Egyébként bár látom, hogy mi akar az osztály célja lenni, mégis nagyon rosszul olvasható a kód. A sok egymásba ágyazott if-else throw exception megoldás helyett inkább azt kéne vizsgálnod a feltételben, hogy sikertelen volt-e a végrehajtás: ha így van, akkor exception, egyébként fusson tovább a kód, pl:
  $stmt = $this->_DB_Connect->prepare($SQL_command);
  if ($stmt === false) { throw new Exception("blablabla"); }
  $parameter_type_list = '';
  foreach($SQL_parameters as $parameter) {
  és nincs utána else!

  Ez sem tökéletes megoldás, de átláthatóbb a kevesebb egymásba ágyazott szerkezet miatt.

• #15406 mallee tag mallee #15405

  Új Válasz 2014-04-03 15:25:48 #15406

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  mallee

  tag

  válasz mallee #15405 üzenetére

  A legjobb az egészben, hogy több egymásnak ellentmondó infót is találtam

  Limitations
  Please note that final, private and static methods cannot be stubbed or mocked. They are ignored by PHPUnit's test double functionality and retain their original behavior.

  Forrás: http://phpunit.de/manual/3.7/en/test-doubles.html

  Úgy tűnik, hogy 3.5 alatt támogatott volt: http://sebastian-bergmann.de/archives/883-Stubbing-and-Mocking-Static-Methods.html

• #15405 mallee tag DNReNTi #15403

  Új Válasz 2014-04-03 15:18:25 #15405

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  mallee

  tag

  válasz DNReNTi #15403 üzenetére

  Próbálj meg statikus metódust kimockolni.

  Szerk: OK, az "újabb" PHPUnit már tudja

Új hozzászólás Aktív témák