CakePHP a hype mögött
Mostanában elég sokszor szóbakerült a CakePHP itt a fórumban, ezért gondoltam, hogy a mai napot arra szánom, hogy egy kicsit ismerkedem vele, addig csak felületes ismereteim voltak vele kapcsolatban. Szépen nekiálltam végigolvasni a projekt kézikönyvét, de már a konfig fájlok kapcsán találtam pár furcsaságot a kódokban, ezért gondoltam, hogy elkezdem gyűjtögetni ezeket. A következő blogbejegyzés ezen lista alapján készült.
A bejegyzés alapvetően egy felsorolás lesz, az érdekesebb témák esetén kicsit kibővítve, és mint a címből is feltűnhet alapvetően a keretrendszer kódjának negatívumairól lesz szó. Elöljáróban elmondhatom, hogy eléggé csalódás volt ebből a szempontból a Cake, korántsem lehet elmondani róla, hogy progamozás-technikai szempontból maradandót alkottak volna a készítői, egyáltalán nincs a kódnak profi kisugárzása.
Előre kiemelném, hogy nem volt semmilyen elenérzésem a Cake-kel kapcsolatban ezelőtt (leszámítva, a PHP4 témakörét, de erről majd később), pont azért akartam megnézni, hogy eldöntsem, a Symfony-t vagy őt lenne érdemes szadabidőben kicsit próbálgatni. Az egész úgy kezdődött, hogy aFüggvények rövidítése: túl sok értelme nincs, szemantikailag nem ad hozzá semmit (sőt inkább rontja, nem túl kifejező egy
A
Lazy loading a tök alapvető osztályokra: ennek elvileg a hatékonyság a legfőbb oka, viszont olyan környezetben, ahol ez számít, ott használnak valamilyen opcode cache-t, ahol viszont már ez a stratégia a rossz.
Ez is itt elég bénácska, semmi értelme sincs tömböt használni.
Ez miért jó?
Egységes kódolási stílus hiánya, pl. hol van szóköz a függvény neve mögött, hol nincs. DocBlock megjegyzések is sok helyen nincsenek kitöltve, vagy nincsenek szinkronban a függvény működésvel. Az osztály és az őt definiáló állományok elnevezése is össze-vissza történik.
Munkamenet indítása előtt ennek mi értelme van (egy keretrendszerben, ahol adott, hogy ez a mechanizmus hogyan van kezelve)?
__ kezdetű metódusok, kifejezetten rossz szokás, ugyanis ez a PHP által fenntartott "névtér".
Ez az ellenőrzés vagy négyszer megtalálható egy függvényen belül, eléggé bad smell refactoring szempontból.
Elég furcsa első ránézésre ez a kód, kiderült (nem a leírásából!), hogy
Több helyen az elnevezés nem egyezik a tényleges funkcionalitással.
Miért ne lehetne a
Apróság, de például az ilyen jellegű konstansokat illene valamilyel prefixxel egy külön névtérbe zárni (mint ahogy sok esetben használja is a
Szintén apróság, de ugye alap esetben a saját nézeteimet az
A
Maga a
Ezenkívül van benne egy szerintem komoly logikai hiba, ami szintén a rossz tervezésből fakad: a
Szintén itt lehet megemlíteni, hogy rengeteg munkamenet kezeléssel kapcsolatos dolgot beállít, olyat is ami talán túlzás (csak sütiben történő tárolás), talán felesleges (
Nem egységes a hibakezelési mechanizmus, általában
Elég gyakran alkalmazott technika, hogy nincs a függvénynek paramétere, és a
A szülő konstruktorát szokás először meghívni, ez elég alap dolog.
A hibákat validáljuk?
Először használja az állandót, majd később ellenőrzi, hogy létezik-e. Érdekes megoldás.
Jellemző a kódbázisra, hogy túlzsúfolt osztályokat használ, nem igazán használja az objektum kompozíciót. Ez alapjaiban elég rossz tervezés.
Meglehetősen esetleges a setter/getter metódusok használata.
Tipikusan rossz megoldás ez a cserélgetés, lásd "
Example: Simple User Authentication
Az alap példa is tipikusan rossz megoldás abból a szempontból, hogy nem generál új munkamenet azonosítót a bejelentkezéskor.
Adatbázis kezelő réteg: manapság elég komoly hiányosság, ha egy rendszer nem támogatja a prepared statement használatát.
Ráadásul most csapdába is kerültek, hiszen egy olyan verzióban írják az egyik legnépszerűbb PHP keretrendszert, amit egy év múlva abszolút nem fognak támogatni.
UPDATE: itt rosszul emlékeztem, mert nem a Cake volt a leglassabb, hanem a Symfony, de az is kiderült, hogy ezen két rendszer estén automatikusan indul munkamenet, ami erőteljesen befolyásolhatta a teszt eredményét.
Szerintem most jött el annak az ideje, hogy egy mérleget készítsenek a fejlesztők arról, hogy mi tekintenek a Cake erősségének, és ezen szempontok figyelembevételével újratervezzék a keretrendszert PHP5 alapokon úgy, hogy bevonnak egy-két új embert, akinek több tapasztalata van karcsúbb, csinosabb, kiterjeszthetőbb core létrehozásában, OOP tervezésben (interfész orientált programozás).
Sok jó ötlet van a Cake-ben (mondjuk jó része RoR másolat), valószínűleg jól megkönnyíti a fejlesztést (munka tapasztalatom nincs vele kapcsolatban), de a jelenlegi kialakítás sok helyen elég gyengécske, messze van egy-két másik rendszer eleganciájától, és a legtöbb helyen az volt a benyomásom, hogy nem lenne könnyű megváltoztatni/kiterjeszteni az alap működést.
■ A bejegyzés alapvetően egy felsorolás lesz, az érdekesebb témák esetén kicsit kibővítve, és mint a címből is feltűnhet alapvetően a keretrendszer kódjának negatívumairól lesz szó. Elöljáróban elmondhatom, hogy eléggé csalódás volt ebből a szempontból a Cake, korántsem lehet elmondani róla, hogy progamozás-technikai szempontból maradandót alkottak volna a készítői, egyáltalán nincs a kódnak profi kisugárzása.
Előre kiemelném, hogy nem volt semmilyen elenérzésem a Cake-kel kapcsolatban ezelőtt (leszámítva, a PHP4 témakörét, de erről majd később), pont azért akartam megnézni, hogy eldöntsem, a Symfony-t vagy őt lenne érdemes szadabidőben kicsit próbálgatni. Az egész úgy kezdődött, hogy a
core.php-n belül egy-két állandó elég rosszul volt elnevezve, ezért rákerestem, hogy hol és hogyan használja őket.CakePHP furcsaságok
Gépház: időszűke miatt nem törekedtem arra, hogy a Cake-et nem ismerő olvasó is képe kerüljön az adott probémával, de szerintem a legtöbb rész ettől függetlenül érthető.<?php
function low($str) {
return strtolower($str);
}
low() nevű függvény), a rövidítésre meg megfelelő IDE-t kell használni. Ráadásul nem használja következetesen a saját rövidítéseit.A
uses() függvény: ennek sincs túl sok értelme.Lazy loading a tök alapvető osztályokra: ennek elvileg a hatékonyság a legfőbb oka, viszont olyan környezetben, ahol ez számít, ott használnak valamilyen opcode cache-t, ahol viszont már ez a stratégia a rossz.
<?php
function &getInstance() {
static $instance = array();
if (!$instance) {
$instance[0] =& new Security;
}
return $instance[0];
}
<?php
function validateAuthKey($authKey) {
$_this =& Security::getInstance();
return true;
}
Egységes kódolási stílus hiánya, pl. hol van szóköz a függvény neve mögött, hol nincs. DocBlock megjegyzések is sok helyen nincsenek kitöltve, vagy nincsenek szinkronban a függvény működésvel. Az osztály és az őt definiáló állományok elnevezése is össze-vissza történik.
<?php
if (function_exists('session_write_close')) {
session_write_close();
}
__ kezdetű metódusok, kifejezetten rossz szokás, ugyanis ez a PHP által fenntartott "névtér".
<?php
if (function_exists('ini_set')) {
...
}
<?php
if (!class_exists('AppController')) {
loadController(null);
}
null-lal meghívva betölti az AppController osztályt. Szintén rossz szokás, amikor egy függvény paraméterei "trükkösen" ki vannak használva, sokkal egyszerűbb kisebb, konkrétabb felelőséggel rendelkező függvényeket használni, tisztább, érthetőbb és könnyebben tesztelhető lesz a kód. Ráadásul statisztikailag bizonyított, hogy egy olyan rendszerben, ahol erre figyelnek, ott lényegesen kevesebb bug keletkezik.<?php
define('CAKE_SESSION_STRING', 'DYhG93b0qyJfIxfs2guVoUubWwvniR2G0FgaC9mi');
Set::extract() metódus: elvileg statikusan használja a legtöbb helyen, de használja benne a $this kulcsszót, ami szerintem rossz tervezésre utal. Ráadásul ha a hívás nem egy objektum példányon hívott tagfüggvényben van, akkor NOTICE-ol, ami szerintem elég gáz egy keretrendszertől.<?php
function __returnSessionVars() {
if (!empty($_SESSION)) {
return $_SESSION;
}
$this->__setError(2, "No Session vars set");
return false;
}
$_SESSION tömb üres?<?php
define('WEBSERVICES', 'on');
CAKE_ előtagot).Szintén apróság, de ugye alap esetben a saját nézeteimet az
app/views/{modellneve} könyvtárba kell tenni, ami azt jelenti, hogy ez esetben a saját modelljeim "névterébe" már bele szemeteltek, hiszen ebben a könyvtárban van már pár könyvtár. Erre a célra illett volna egy külön könyvtárat fenntartani, tisztább, szárazabb érzés.<?php
* @param mixed $name Name of variable
* @param string $value Value to write
* @return boolean True if the write was successful, false if the write failed
* @access public
*/
function write($name, $value) {
$var = $this->__validateKeys($name);
$name mixednek van definiálva, de utána közvetlenül ellenőrzésre kerül hogy karakterlánc-e, illetve a _validateKeys (a függvény neve sem az igazi) ellenőrzi, hogy megfelel-e egy bizonyos feltételnek. Ez a feltétel kizárja, hogy amúgy a PHP-ban megengedett kulcsokkal tegyünk le a munkamenetbe adatokat. Plusz itt is előjön némi "névtér" para, a munkamenet kezeléssel kapcsolatos metaadatok belekeverednek a "sima" munkamenet adatok közé, így a $_SESSION tömbre húzott felülettel simán hazavághatom a munkamenetet mondjuk ezzel a paranccsal: $this->Session->write("Config", 1).Maga a
CakeSession osztály sem a legszebb tervezés, egy nagy osztályba van minden belezsúfolva, ezt meg lehetet volna csinálni rendesen is. A database kezelős részben is van egy kis zavar, a __gc metódusban illene figyelembe venni a php.ini-ben beállított értéket.Ezenkívül van benne egy szerintem komoly logikai hiba, ami szintén a rossz tervezésből fakad: a
renew() tagfüggvény nem lehetne független attól a mechanizmustól, ami a munkamenetet tárolja, ugyanis a regenerate_session_id() az nem veszi ezt figyelembe, így nyugodtan kiosztásra kerülhetne egy már használatban lévő munkamenet azonosító. Kb. emiatt igazából nem is lehet korrekt módon saját munkamenet kezelővel kiegészíteni.Szintén itt lehet megemlíteni, hogy rengeteg munkamenet kezeléssel kapcsolatos dolgot beállít, olyat is ami talán túlzás (csak sütiben történő tárolás), talán felesleges (
high mód esetén referer_check), de például nem állítja be a http_only paramétert, ami biztonság szempontjából lényegesen fontosabb.<?php
if (!preg_match('/(.*)Controller/i', get_class($this), $r)) {
die (__("Controller::__construct() : Can not get or parse my own class name, exiting."));
}
trigger_error()-t használnak, de van mikor a die()-t, ami szerintem elég ciki, főleg, hogy rendelkeznek saját hibakezelővel. Szépen mutathat egy ilyen hiba egy éles oldalon. :)<?php
/**
* Returns number of errors in a submitted FORM.
*
* @return int Number of errors
*/
function validate() {
$args = func_get_args();
$errors = call_user_func_array(array(&$this, 'validateErrors'), $args);
if ($errors === false) {
return 0;
}
return count($errors);
}
func_get_args()-ot használják helyette. Ez szintén elég rossz módszer, nem lehet tudni, hogy mire szolgálnak a paraméterek (a függvény leírása nem tartalmazza). Általábban jellemző a kódbázisra, hogy nem a legjobb elnevezéseket használja, nem lehet tudni a névből és a leírásból, hogy pontosan mit is csinál egy adott függvény, bele kell nézni a kódba.<?php
function __construct($text = null) {
$this->text = $text;
parent::__construct();
}
<?php
/**
* Validates a FORM according to the rules set up in the Model.
*
* @return int Number of errors
*/
function validateErrors() {
<?php
function referer($default = null, $local = false) {
$ref = env('HTTP_REFERER');
$base = FULL_BASE_URL . $this->webroot;
if ($ref != null && defined('FULL_BASE_URL')) {
Jellemző a kódbázisra, hogy túlzsúfolt osztályokat használ, nem igazán használja az objektum kompozíciót. Ez alapjaiban elég rossz tervezés.
Meglehetősen esetleges a setter/getter metódusok használata.
<?php
function __strip($value, $message = false) {
$search = array('/%0a/i', '/%0d/i', '/Content-Type\:/i',
'/charset\=/i', '/mime-version\:/i', '/multipart\/mixed/i',
'/bcc\:/i','/to\:/i','/cc\:/i', '/\\r/i', '/\\n/i');
if($message === false) {
array_pop($search);
array_pop($search);
}
return preg_replace($search, '', $value);
}
bcbcc:c:", meg amúgy is az egész osztály elég rosszul van kialakítva (bővíthetőség, felelősségek). Mellesleg nem is értem, hogy miért nem használ valamilyen jól kiforrott megoldást, ha már nincs otthon ezen a területen.Example: Simple User Authentication
Az alap példa is tipikusan rossz megoldás abból a szempontból, hogy nem generál új munkamenet azonosítót a bejelentkezéskor.
Adatbázis kezelő réteg: manapság elég komoly hiányosság, ha egy rendszer nem támogatja a prepared statement használatát.
PHP4 támogatás
Őszintén szólva nem olyan régen tudtatosult bennem, hogy a CakePHP PHP4-en is fut, ez volt az egyetlen dolog, ami előzetesen némi rossz szájízt adott a dolognak. Eleve nem értem, hogy miért nem tisztán PHP5-ből indultak ki az alkotók, rengeteg dologtól elzárták magukat, amit így most eléggé nyakatekert módon próbálnak meg biztosítani (például elvont osztályok, láthatóság, mágikus függvények stb.).Ráadásul most csapdába is kerültek, hiszen egy olyan verzióban írják az egyik legnépszerűbb PHP keretrendszert, amit egy év múlva abszolút nem fognak támogatni.
Személyes konklúzió
Egyre több kódot átnézve az a benyomásom alakult ki, hogy a fejlesztői nem azok az igazán tapasztalt programozók, ráadásul tervezési minták terültén se nagyon vannak otthon. Hiányzik némi munkatapasztalat, nem találkoztak még bizonyos problémákkal, nem ismerik még a nyelv minden apróságát. Sok olyan kódrészletet lehet találni (felesleges ellenőrzések, függvényhívások stb.), amit egyszerűbben is meg lehetett volna oldani, most már nem csodálkozom, hogy a CakePHP lényegesen lassabb volt egy Hello World teszt esetében, mint néhány vetélytársa (Symfony, Solar, ZF).UPDATE: itt rosszul emlékeztem, mert nem a Cake volt a leglassabb, hanem a Symfony, de az is kiderült, hogy ezen két rendszer estén automatikusan indul munkamenet, ami erőteljesen befolyásolhatta a teszt eredményét.
Szerintem most jött el annak az ideje, hogy egy mérleget készítsenek a fejlesztők arról, hogy mi tekintenek a Cake erősségének, és ezen szempontok figyelembevételével újratervezzék a keretrendszert PHP5 alapokon úgy, hogy bevonnak egy-két új embert, akinek több tapasztalata van karcsúbb, csinosabb, kiterjeszthetőbb core létrehozásában, OOP tervezésben (interfész orientált programozás).
Sok jó ötlet van a Cake-ben (mondjuk jó része RoR másolat), valószínűleg jól megkönnyíti a fejlesztést (munka tapasztalatom nincs vele kapcsolatban), de a jelenlegi kialakítás sok helyen elég gyengécske, messze van egy-két másik rendszer eleganciájától, és a legtöbb helyen az volt a benyomásom, hogy nem lenne könnyű megváltoztatni/kiterjeszteni az alap működést.
érdekes
érdekes amit írsz, vagy inkább figyelemreméltó. Talán többet kellene hasonló szinvonalon kivesézni kódokat. Érdekes lenne olyan cégek CMS és egyéb rendszereinek a kódját átnézni hasonló szempontok szerint, akik sok-sok pénzért árulnak ilyen rendszereket.
Én pl. voltam olyan merész, hogy a Sharepoint-nak átnéztem azokat a generált kódjait (nem a forráskódját, mert az nem publikus) amit a böngésző meg fog kapni. Hát...nem tudtam sírjak-e vagy röhögjek... Az egyik rész csupa kisbetű volt a másik csupa nagy a harmadik keverve, össze vissza ID nevek stb. - látszott, hogy több csapat fejleszti és magasról letojja az egyik a másik szabályait.
De szerintem bármit átnéznél hasonló dolgokat lehetne találni, tekintsünk el az elfogultságtól - kinek mi a kedvence és azt védi. Ennek az egyik oka az, hogy senki nem akarja megfizetni a szép fejlesztést, legalábbis én még nem láttam olyat, hogy azt mondta volna a Pénz, hogy "jó van gyerekek, mostan kód szépsége és a tökéletessége a mérvadó". Idő, idő, kész van már?, mennyi plusz költésg? blabla... Persze ettől még a fejlesztő felelőssége, hogy ugyebár mégiscsak "programozó", akinek illő betartania a szabályokat. Csakhát ez szép elmélet.
De hátha ebből a bejegyzésből tanulunk és áldozunk magunkból plusz időt és plusz gondolkodást!
Hasznos!
más kódok, időszűke
Én pl. nagyon sok dolgot más kódokból lestem el, ha láttam valami érdekeset, akkor utánéztem, hogy jé erre is van lehetőség, na ez az, amit nem érzek a CakePHP-n. Bizonyos dolgokat biztos, hogy nem így csináltak volna meg, ha már láttak volna hasonló PHP keretrendszereket, vagy már szembesültek volna sokféle feladattal a munkájuk során. Sok mindent megcsináltak darabra, de a kódok minősége, az egész kohéziója/felépítése nem az igazi.
Más részről pedig sok esetben a korrekt megoldás nem kerül több időbe, mint az egyszerűbb. Vagy pedig először kicsit el kell bíbelődni, de utána van egy olyan megoldás a kezedben, amit bármikor be tudsz vetni. Az olyan dolgok, mint a korrekt elnevezések, legalább inline dokumentálás, szükség esetén refactoring stb. (amik "lokálisan" több időt vesznek el), tapasztalatom szerint mindig megtérülnek, mert egy kódhoz az esetek többségében hozzá kell nyúlni a későbbiek során, és ott már ezek meghálálják magukat.
Üdv,
Felhő
cakephp
Én is, sőt nyilván ilyen dokumentációhiány mellett mindenki rákényszerül a forráskód böngészésére, és nekem csak pozitív benyomásaim vannak (így van, nem, nem töltöttem még le a Symfonyt csak azért, hogy a kódját olvassam).
A poszt kiszemel néhány hibát, bár ezek egy részének inkább csak vélt szaga van, de szereti odatűzdelni a bombasztikus következtetéseket, hogy "rossz tervezésre", kiforratlan programozói bázisra, amatőrizmusra utal. A posztcím is némileg bombasztikus.
(Érdekes, Gergely, egyszer nekem is a fejemhez vágtad ezt a "rossz tervezésre utal"-dolgot, amikor olyan lapozó osztályt írtam, melynek van egy default-os callback függvénye, s hasonlóan elméletieskedő voltál, holott tudjuk, hogy a template-elésben a callback-ezés bevett gyakorlat. (És akkor meg lehet nézni, hogy a Drupal hogy callbackezik!) Ehhez képest nem kis bóknak vehetem azt az egyszer elejtett megjegyzésedet a template-vitánkban, miszerint a tankönyv beszél belőlem. -- Mindegy, az biztos, hogy azóta a "rossz tervezésre utal" megjegyzéseidet igencsak fenntartásokkal kezelem.)
Nem érzem a pontok relevanciáját sem. Nem a használat felől közelít. Így is lehet, de főleg ilyen egyoldalú módon a keretrendszer-recenziók műfajában elég szokatlan, és használat és összehasonlítás nélkül kissé hiteltelen, szubjektív is (pl. a formális paraméterek nélküli fv.-ekkel és az elnevezésekkel kapcs. megjegyzés; és akkor itt jönne a validateErrors további alátámasztás gyanánt, de használat nélkül ez is csak szőrszálhasogatás.)
Egy-két példa. A "Miért ne lehetne a $_SESSION tömb üres?" kérdés ilyen felületes ránézésre nem indokolt, és kritikának pláne nem meggyőző. Meg kell nézni, milyen mechanizmusban pontosan mit szolgál az a logika ott.
"Ez is itt elég bénácska, semmi értelme sincs tömböt használni." Ahhoz, hogy ebből jogos kritika legyen, fel kell nekik tenni IRC-en a kérdést. Nagyjából az egész kritikáról ez a légváras kapirgálás a benyomásom.
Lévén igen népszerű keretrendszerről szó, a tracjéből, a google groups listából, az irc-logból látható, hogy adott kódmennyiségre nézve igen nagy a kontroll. Éppen ezért, mielőtt elhamarkodott ítéletekbe bocsátkoznál, szerintem ismételd el magadban, hogy "nem véletlen". Abból több érvényes megállapítás fog származni. A kódmennyiségről pedig egy cikk jut eszembe, amit egyszer próbáltam feltenni a webes blogmark-felületen, de az nekem vhogy nem működik (vagy előzetes elbírálás van, nem tudom). A cikket (sőt, asszem az egy blogos párbeszéd) egy Zendhez modult író illető írta, összehasonlítja a Cake-et a Zenddel (mind2-ben járatosként), majd végül közli, hogy ezért és ezért tér át Cake-re. Elég érdekes.
Látod, mondtam én, hogy szokatlan műfajba kezdtél. Én csak azután kezdenék azzal az állítással vitatkozni, miután megtettem, amit még nem.
Meglepetés
Szubjektív véleménnyel arra merek következtetni, hogy a kód íródott, csak azután készült a dokumentáció... ami a szememben a dolgok fordított menete.
Tessék
(Készül a magyar fordítás is.)
dokumentáció
Attól függ, mit értünk dokumentáció alatt. A célközönségnek szánt dokumentáció (manuál, help) max. egyidőben készül, de mindig lépéshátrányban van. Számos keretrendszer (sőt, ezt nagyon tudnánk általánosítani, lényegében számítástechnikai produktum) úgy lát napvilágot, hogy a manuálja késik. Jó példa a prototype, amelyik ráadásul előbb futott be, minthogy bármilyen hivatalos doksija lett volna. (Mellesleg így befutnia egy keretrendszernek szerintem már önmagában bizonyít valamit.)
Pont ez az
re: cakephp
Üdv,
Felhő
re: cakephp
Nem bánom, de bennem már a cím is ezt a bonyomást keltette. Ha valami, akkor épp a Cake körül nem érzek hype-ot (ellentétben a Railszel -- a legrosszabb fajtából --, mint azt a belinkelt videó is mutatja).
Ok, sry.
Semmilyennek.
Ezt köszi, szintén sry. (De miért célszerű rendes IDE-t használni? Kereséshez?) 'die('-ra kerestem, ezért nem találtam meg, az az egy maradt ki, ebből még mindig nem tudok arra következtetni, amire ezzel kapcsolatban te. A többi die szerintem indokolt, ez van a leggyanúsabb helyen, de még így sem merném leírni. BTW, a Cake hibakezelése egyszerűen brilliáns, ahogy a kódot meg kontextust kirakják.
Köszönöm a tanácsot. Igazából nem értem, mi itt a bírálat. Lemérted a CakePHP CCN-jét? Túl sok vagy túl kevés lett? Én nem érzem úgy, hogy "nagy és túlzsúfolt osztályok" lennének benne. Lehet, hogy szomorú, de nekem az a véleményem, talán nem kéne ennyit olvasnod :) Olvastam már egyetemi tanár blogján rails-kritikát, és igazából elkeserítő... Végig arról szólnak a kommentek (túlzok biztos), hogy semmi értelme az ilyen elmélet felől közelítősdi kritikának, hogyaszongya a nagykönyvben nem úgy van leírva. A szemezgetéseidből semmilyen következtetést nem lehet levonni a Cake-re vonatkozóan. És ha a Symfonyról írtál volna, arra sem lehetne. A Cake kódját baromira szereti a használói bázisa (köztük engem). Ez biztos.
Sajnálom, ha személyeskedésnek vetted, amit az elhamarkodott ítéleteiddel kapcsolatos tapasztalataimról írtam, de be kell vallanom, nem minden pontot tudtam 100%-ig követni, és feltételezem, ezzel más is így van, így nem tartottam teljesen indokolatlannak megemlíteni. Amit tudtam, azok egy jó részéről pedig nem vagyok meggyőződve, hogy (akár a nagykönyv szerint) nagyobb vétkek lennének, mint mondjuk docblokkból validálni.
Itt lehet, hogy közelítünk, dehát az nem ment egy cikket, ha elismered, hogy irreleváns. Nem tutorialt kértem számon, hanem hogy legyen érvényes következtetése (vagy ne legyenek túlzók).
Nem lesz hitelesebb. Akkor lesz hitelesebb, ha prezentálsz egy összehasonlítást.
A validateErrors-szal sem elsősorban a megjegyzéssel magával van bajom, hanem az abból levont következtetéssel. Lehet ez a Cake legkevésbé beszédes elnevezése akár, de ebből semmilyen általánosítást nem lehet tenni. A Sanitize->paranoid()-dal mi a gond? Szerintem kifejező.
Már megbocsáss, de akkor ezt kell leírni, nem úgy titkolózni, hogy hát ez itt bénácska. Ha kompatibilitási workaround, akkor nem érvényes az a kijelentés, hogy "semmi értelme". És az egész megintcsak irreleváns, mert ahhoz a témához kapcsolódik, hogy szeretjük-e, vagy nem, hogy a cake php4-en is fut.
(Totál OFF, de újabb példa, mekkora katasztrófa ez a php... Valahogy az IE-hez tudnám hasonlítani a böngészők világában. /OFF)
Valószínűleg inkább annyi, hogy a paraméter nélküli read() hívásokról feltételezi, hogy előzetesen check()-oltunk. Ebben semmi kivetnivalót nem látok. Sőt, teljesen logikusnak tartom, hogy ilyenkor kapok egy notice-t (a Config kulcsot nemrég implementálták, úgyhogy nem valószínű, hogy az játszik).
Talán most, bár tényleg nem az volt a célom, hogy pontról pontra vitába szálljak, hanem csupán azt közölni, hogy ez az egész értelmetlen úgy ahogy van. Egyszerűen az egésznek semmi tanulsága sincs.
Ezt nem véletlenül hangsúlyoztam, és bár az észrevételeid jónéhány részen vitathatók, tény, hogy te is a kontroll része vagy.
Sorry, kicsit már összekevertem. A blogos párbeszéd itt, a zendes fejlesztő írását fogalmam sincs már, hol olvastam. (XY, Zendre modult fejlesztő cég tagja leteszi a voksát cake mellett sztori, és az rémlik, hogy hasonlóan érvel, mint a párbeszédben olvasható.)
A kettő még mindig nem ugyanaz, de mindegy. Csak azt tudom mondani, hogy megpróbálok majd tapintatosabb lenni, ha ilyen vészes lennék... (És sajnálom, hogy nem értek egyet.)
Nincs itt probléma
Vitatkozni felesleges, a tények elég makacs dolgok. A kódban nagyon sok hiba van. Annyit kellett volna mondani: kösz, átnézzük, javítjuk. :)
tényleg nincs probléma
re: cakephp
A validateErrors-szal sem elsősorban a megjegyzéssel magával van bajom, hanem az abból levont következtetéssel. Lehet ez a Cake legkevésbé beszédes elnevezése akár, de ebből semmilyen általánosítást nem lehet tenni. A Sanitize->paranoid()-dal mi a gond? Szerintem kifejező.
A sok flame mellett viszont például arról nem esett szó, hogy mi a Cake terve a PHP4-gyel kapcsolatban. PHP6 alatt is majd PHP4 feature set mellett fogják programozni?
Üdv,
Felhő
re: cakephp
Az a die() nagy valószínűséggel soha nem fut le az égvilágon, legfeljebb valami óriási core bug esetén. Én legalábbis akárhogy gányoltam a controllereim nevével fájlnevekben, classokban, táblákban stb., vagy a dispatcherben elakadt php fatal errorral (gányolni is tudni kell), vagy sima esetben lement hibakezelőn. Viszont ugye a controller nevét parse-olja preg_matchcsel, aminek meg azért _illik_ (szeretjük ezt a szót) egy ágat szentelni sikertelen parse esetére is. Mert ha nem szentelek neki ágat, akkor meg az lesz a baj, mert _illik_. Ha meg hibakezelőbe rakom, akkor az lesz _egy kicsit bénácska_, mert valójában fatális, nem kezelendő hibáról volna szó.
Szóval nem igaz, hogy ebből éles oldalon csakúgy die lesz, és az sem igaz, hogy "saját magával nem konzisztens", mert ugye egy darab die-ról van szó, már amelyikre korábban nem vetettem egy pillantást a szóközkihagyásos keresésemkor. De ha gondolod, vizsgáljuk meg a többit is.
Egy biztos, hogy a cake-nek konzisztens hibakezelése van, amit konzisztensen használ.
Egy BTW-be talán belefér, már csakúgy ellensúlyozandó azt a másik féle parasztvakítást (l. később).
Akkor most ki kellene mutatni, hogy a cakephp-ban túl sok hiba keletkezik. Sok sikert.
app/config/core.php, 79. sor
Ugyebár eztet az elnevezésekkel kapcsolatos fenntartásaidra írtam. Nézzük azokat a konkrét hibákat.
Tény, hogy a getElementsById sokkal beszédesebb, mint a szemantikailag semmit hozzá nem adó $. Nyilván a prototype készítői is kicsit amatőrök, kicsit bad smellre hajlamos fejlesztők, akiknek valószínűleg nincs megfelelő IDE-jük...
A rövidítések problémájának egy részét át tudják vállalni az IDE-k, de az a helyzet, hogy a programozói világot ez egy cseppet sem zavarja abban, hogy a kódot is rövidítse olykor, s hogy a frameworkök is néhány saját rövidítést bevezessenek maguknak. Ez mintha divat is lenne mostanában, egyfajta nyelvgyúrás, a nagykönyvben biztos nincs leírva, és a cake-nek is van egypár ilyenje (e, m, am stb.) Ezeket a manuálokban előkelő helyen szokták ismertetni, ezek az adott framework sajátjai, lehet szeretni, nem szeretni, és főleg nem muszáj őket használni. Nekem is vannak rövidítéseim, pl. cf a create_function helyett (off, ez a create_function is micsoda egy torzszülemény a lambdázásra; on). És nekem a low() is tetszik a szintén katasztrofális strToLower() helyett. (Nem tudok megállni egy újabb kis parasztvakító kitérőt, ajánlott olvasmány, 1. pont.)
Egyébként adható erre a jelenségre egy viszonylag természetes magyarázat, amit most nem taglalnék időhiány miatt, mindenesetre a rövidítésekbe ilyenformán belekötni legalábbis vérszubjektív eljárás, konkrét hibaként érvelni vele meg konkrét hiba.
Azt az állításodat, hogy nem használja következetesen a rövidítéseit, nem támasztottad alá.
Erre szolgálna alátámasztásul a CAKE_SESSION_STRING?...
--
És akkor most mehetünk végig az egészen? Ha még azt mondod, hogy hoppá, validateErrors, nem furcsa ez egy kicsit, akkor még hümmögök rá, de a sanitize->paranoid()-ra már azt mondom, ne erőlködjünk. Olyan a posztod, mintha egy irodalmi blogra küldtél volna kritikát egy könyvről, és elkezdenéd benne taglalni, hogy az első 10 oldalon ennyi és ilyen helyesírási meg nyelvhelyességi hibát találtam, ez az író bizony gyengén tervez. És pszicholingvisztikailag bizonyított tény, hogy az ember 4 sorosnál hosszabb mondatokat nehezen ért már meg, úgyhogy Beckettet jobb, ha nem is olvasunk... Pedig én prekoncepció nélkül álltam neki...
Ám legyen, de ezekből semmilyen következtetést nem lehet levonni. Én épp ezt nevezném parasztvakításnak (elég hatásos is, ahogy nézem). És ezer méterről látszik, hogy könnyelműen, félvállról közelítesz egy mellesleg elismerten jó minőségű anyaghoz. És néha igencsak bakot lősz, csak ébernek kell lenni. Egyszerűen gyorsan ítélsz. (Bocs, ha ez személyeskedésnek számít.)
---
Még egyvalami fontos. A használatot nem lehet teljesen, sőt megkockáztatom, csak alig lehet elkülöníteni a kódtól. Az a legkorrektebb eljárás a kód megítélésére, ha összeveted egy ugyanolyan funkcionalitású másik kóddal. Ha van egy keretrendszer, amit azért szeretnek, amiért olyan, amilyen (belsőségeit beleértve, és nem azért, mert szép az adminja, mint a joomlának), akkor igencsak meredek dolog összehasonlítási alap nélkül megbírálni. Nézz szét a framework-recenziók között a blogoszférában, 98%-uknak X vs Y a címe. (És ez ugye még hangsúlyosabb, ha elnevezésekről akarunk ítélkezni.) (Mellesleg maradva a könyves példánál, még az irodalomtudomány is rájött, hogy a recenzió alapvetően összehasonlító tevékenység (komparatisztika).)
Nincs szempontod. Ha azt mondanád, szemügyre veszem a cake architektúráját, vagy magját, komponenseit, szolgáltatását, konzolját, CoC-jét, külcsínét, kezelhetőségét, stabilitását, az mondana valamit (és mennyire kézenfekvő is volna a rutinszerű összevetés akkor), de így, hogy megnéztem "a kódot", és akkor olykor hajuknál fogva ideráncigált tankönyves, olykor teljesen megalapozatlan, olykor jogosnak tűnő, de teljesen jelentéktelen dolgokon fennakadó kifogásaidat egy ilyen nagyzoló című posztba bedobálod, hát, te tudod...
---
Az, hogy a statikus változó nem tartja meg a változóreferenciát?
Már amennyiben nem a php4 hülyeségéről beszélünk, de tudomásom szerint arról. Legalábbis a dokban a php4 motorjáról van szó ennél a résznél. Erről a nyelv sajátjáról egyébként hirtelen az IE6 text selection bugja jut eszembe: hát igen, az is a böngésző sajátsága, hogy a head-en kívül is engedi a BASE taget, amiből sokminden érdekes dolog következik, közte az említett _sajátságot_ is. (Vagyis minden hülyeséget meg lehet magyarázni.)
Nem referenciaként átadni az objektumváltozót nem ugyanaz, mint referenciaként. Az utóbbi teljesítmény szempontjából optimálisabb. Lehet, hogy az egésznek nincs akkora jelentősége, de én azért nem bénácskáznám le amolyan felvételiztetői rutinnal azt, ha egy framework alkotói a teljesítményben jobb verziót választják, különösen akkor, ha egy bekezdéssel lejjebb meg már arról értekezek, hogy nagyobb projektre nem használnám.
A kód azt fejezi ki, hogy a read() a kiolvasásért felelős, a csekkolásért nem. És ez is történik. Bad smelling.
Érdekes módon ezt pont arra a mondatomra írod, melyben közlöm, hogy nem is érdemes. (Miközben lassan végigmegyünk az összesen.) A _posztra_ reagáltam, egészen konkrétan.
...kezdve a poszttal...
Ha talán ez lett volna a fő kérdés a posztban...
Ehhez szvsz előbb várjuk meg a PHP6-ot. De ha most valamit mondanom kéne (bár nem tudom, miért van ennek olyan nagy jelentősége), akkor talán azt, hogy jelenleg inkább hozzáad ez a kompatibilitás az értékéhez, mint levon belőle. Valószínűleg nem olyan kritikus a kompromisszum, vagyis megéri.
Amikor az emberek elbeszélnek egymás mellett
Ez rettenetesen demagóg szöveg, a felette felhozott prototype-os példád is. A
low-val nem az a baj, hogy rövid ÓMG, hanem hogy nincs az a programozó, aki tudja róla, hogy mire való, milyen paramétereket vár, és mi lesz a visszatérési értéke. (Még szerencse, hogy a legtöbb nyelvben adonyelvi elem.) AstrToLoweregyértelműen jelzi, hogy stringet vár paraméterként, lekicsinyíti, továbbá valószínűleg a visszatérési értéke lesz az új string. Továbblépve, bizonyára olvastad, hogy a másik baj alow-val, amire Felhő rámutatott, hogy egyszerűen csak egy wrapper a PHP-s natívstrtolowerfelett.Az elbeszélést lezárandó, várjuk frakitől a CakePHP-t bemutató cikket! Ha bármilyen segítségre szükséged van, fordulj bátran a WL szerkesztőségéhez.
low
Erről szerintem itt eddig senki nem is beszélt.
A low() rövidítés, épp olyan, mint az e() vagy az am(), és nem tudom, miért lenne demagóg a prototype-os példám. Alapvetően félreértés egy rövidítéstől elvárni, hogy többet mondjon, mint amit rövidít. Azt sem értem, miért érveltek azzal, hogy baj, ha csak egy wrapper, amikor a rövidítéseknek ez a tulajdonság sajátja. A rövidítés nem azért van, hogy többet adjon hozzá, hanem hogy a nevét lerövidítse. A $ is csak egy wrapper.
prototype
A low ránézésre nem mond semmit arról mit csinál. Hozzáadott érték nulla. És ez vele a legnagyobb baj.
még egy pontosítás
Sajnos pont ez nem történt meg. Nem próbálta ki. És én meg az egész alól épp csak ezt hiányolom.
kódvizsgálat
ezt honnan veszed?
Üdv,
Felhő
innen veszem
Idézek a posztból:
- "pont azért akartam megnézni, hogy eldöntsem, a Symfony-t vagy őt lenne érdemes szadabidőben kicsit próbálgatni"
- "munka tapasztalatom nincs vele kapcsolatban"
Szólj, ha ebből arra kell következtetni, hogy a poszt megjelenésének pillanatában volt vele munkatapasztalatod.
még egy ÁÁÁÁÁÁÁÁÁÁÁÁ
Üdv,
Felhő
Sztem, nem kell ennyire forrón enni...
Lásd példa, Wordpress. Egy bugware szar, már elnézést, mégis mennyien használják. Egy céleszköz, azt csinálja, amire ki lett találva és ha valaki nem tud sok erőt és energiát fordítani vagy nincs meg a tudása az OOP (ne adj Isten, UML) alapú teljes rendszer fejlesztésre, akkor ezek az eszközök annak ellenére, hogy magasabb szinten használhatatlanok, megnövelik a hatékonyságot.
Viszont azt is látni kell, hogy ezek az eszközök nagy, céges környezetben, komoly rendszerfejlesztésnél az inkonzisztenciáikkal hátráltatják a munkát.
Ergo, kinek mi. Van egy csomó ember, akinek egyszerűen össze kell rakni egy oldalt és pont. Fölösleges lenne erre egy teljes OOP fejlesztőcsapatot kialakítani, mert robbantaná a költségkeretet. Vannak viszont az olyan projektek, amik nagyon, más rendszerekkel összefüggőek, stb. itt szinte lehetetlen egy amatőr kezdeményezésből született frameworköt használni.
forrón evés
Üdv,
Felhő
Gondolj bele...
ezt a részét megérteném
Pont az ilyen rendszerekből tanultam a legtöbbet, többek között itt lehet találkozni a nyelv olyan finomságaival, amik úgy általában nem kerülnek előtérbe. Plusz ha valaki olyat mondott, amit nem ismertem, akkor megpróbáltam utánajárni, hogy mi is ez. Például Sitepoint fórumában rengeteg nagyon érdekes post volt tervezéssel kapcsolatban, eleinte gyakran nem is értettem pontosan, de éreztem, hogy fontos, meg számomra számított aki mondja (pl. a SimpleTest fejlesztője, a WACT fejlesztője, Jason Sweat, Voostind - Eclipse nevű cucc szerzője, Harry Fuecks, csupa olyan ember akiknek a szemléletmódja még most cél számomra), utánajártam a témának, és nem bántam meg.
Üdv,
Felhő
Forró fej...
Lényeg a lényeg: az Open Source szoftverek egy része sajnos ilyen, hogy vannak benne kevésbé átgondolt dolgok, egy fícsörnek gondolt dologból (ld PHP 4 kompatibilitás) könnyen lehet bug, hiszen nem csak képzett vérprofik mászkálnak a világban, viszont mindenki szeretne valamit tenni a közért (nagyon helyes) és ha jól látom, a Cake azért elég sok embernek megkönnyítette az életét.
Ami pedig azt illeti, ha kinőtted, nem kell használni. :) Egy adott framework egy adott célközönségre készül és aki többet, mélyebben akar keres mást... vagy csinál egy sajátot. Csak minél följebb mész az alaptudást feltételezésben, annál vékonyabb lesz a célközönség rétege...
észérvek
Üdv,
Felhő
uccsó re
Üdv,
Felhő
cakephp
Továbbá akceptálom, ha más viszont értelmetlennek találja, vagy azt is, ha az jön ki, hogy kevés vagyok hozzá, s azt is, ha a vitafelem emiatt kilép.
Nos, ahogy látom, néhány hülyeségbe jól beleszaladtam. Ilyen az, hogy a php referenciákkal kapcsolatos viselkedését a 4-es verziónak tudtam be, merthogy a dok a tárgyi fejezetet a következő módon kezdi be: "A PHP 4-et működtető Zend Engine 1..." Jól látom, hogy fölöslegesen említik a php 4-et? Én magam még nem singletonoztam, én csak cakephp-ztam :)
Rövidítés
-----------
További hülyeségbeszaladási kategória ez részemről, mert a $-ról tényleg elfelejtettem, hogy nem csak wrapper, bár itt már talán árnyaltabb a kép. A $$ már inkább csak wrapper. De van egy ilyenünk is: Array.from = $A;
Hasonlóan a cake-nek is van olyan rövidítése, ami hozzáad, ilyen a pr(), ami alapvetően egy print_r. A cake-nek van még emellett néhány rövidítése, amiket használ maga is, de valóban nem kizárólagosan (r, e, a, aa, am, h, low, up). Ezeket a manuálban fel is kínálja.
Nos, mit is ír a poszt? "Függvények rövidítése: túl sok értelme nincs". Ez az állítás egyszerűen szubjektív. A "szemantikailag nem ad hozzá semmit (sőt inkább rontja, nem túl kifejező egy low() nevű függvény)" egészen érthetetlen érv, hiszen a rövidítés magától értetődően levesz a szemantikai beszédességből.
Az is egy életszerűtlen érvelés, hogy nincs az a programozó, aki kitalálja belőle, mit jelent. Aki a cake-kel ismerkedik, az kb. az 5. percben már tudja, hogy van neki nagyságrendileg olyan 10 rövidítőfüggvénye, s köztük a low()-t még inkább meg is jegyzi, mint az am()-et (de amint belemerül a Set::extract() világába, már az utóbbit is inkább ő fogja keresni (velem legalábbis ez történt)).
"a rövidítésre meg megfelelő IDE-t kell használni" -- Ez így megintcsak szubjektív. Lehet, hogy ugyanannyi fáradság, sőt leütés az am()-et bevinni, mint az array_merge()-öt, számomra mégis szebben néz ki egy soktömbös lekérdezést megdolgozó logikában az am(), mint az ott már inkább csak sorhosszt és verbozitást, semmint szemantikai értéket hozzáadó array_merge().
"Ráadásul nem használja következetesen a saját rövidítéseit." Itt a "Ráadásul" már sugallja, hogy jól benne a vagyunk a slamasztikában, de tény, hogy nem használja őket rigorózusan. Kéne? (Vállrándít.)
--------------
És akkor feltehetjük a kérdést, hogy miről is beszélünk? Azt vitatjuk meg, hogy a rövidítéseknek mikor mennyi értelmük van, vagy három mondattal elintézzük őket egy cake-ről leplet lerántani akaró posztban.
--------------
Továbbmenve a következő pontra már ennyivel se fárasztod magad, csakúgy odaveted: "A uses() függvény: ennek sincs túl sok értelme." Nem kéne ezt kifejteni? Ebben áll a szakmaiság? Szerinted helyesen teszi bárki (ismerje a cake-et vagy ne ismerje), aki ebből a megjegyzésből bármilyen tanulságot levon? De, persze, gyarapítja a pontok számát, hogy a végén rámondhassuk: mindezekből látszik, hogy a cake gyenge lábakon áll. Ezzel a gőzzel azt is írhattad volna rögtön, hogy a cake-nek magának sincs semmi értelme. Tudjuk, hogy nem ezt akartad írni, de az információtartalma kb. ugyanannyi lenne.
---------------
Annak ellenére, hogy beleszaladtam néhány hülyeségbe, számomra ebből a vitából nem az a tanulság, hogy kussban kellett volna maradnom, hanem hogy jogosan kérem számon azt, amit. Van még mindig néhány elvarratlan szál.
Pl. oké, a php engine copy-on-modify módon dolgozik, de ez még nem bizonyítja, azt, hogy a referenciaátadás gyakorlata a mi esetünkben rosszabb volna, mint a nem referencia alapú. Az, hogy az a tömbösdi nem szép, nem a cake hibája, hanem a nyelvé.
Ehhez még nem is nyúltunk: "__ kezdetű metódusok, kifejezetten rossz szokás, ugyanis ez a PHP által fenntartott "névtér"."
A PHP-nak nincs fenntartott névtere (ezért is teszed idézőjelbe). Az én szememben a php alapvetően egy konvenciókáosz, melynek része a __ is. Van valami hivatalos állásfoglalás, hogy kerülni kellene ezt?
----------------
Itt megelőzendő a hülyeségbe szaladást, előre bocsánat a kérdésért, de mi akadályoz meg abban, hogy olyan renew metódust írj hozzá, ami ezt biztosítja?
---------------
----------------
Azért, mert az, hogy "egy kód minősége" mint olyan nem egzakt fogalom. Néha rámondjuk egy-két dologra, hogy úgy sz*r ahogy van (mint pl. a szomszéd topikban a joomlára), de azért a cake talán mégsem ez a kategória. És kifejtettem, hogy nem véletlen, hogy mennyire az összehasonlító kritikák az általános a blogoszférában.
Beveszek minden kedvességet most, de azért volt ott egy félrevezető mondat: "Most ha leírom, hogy a Solar/Symfony rendszerekben szerintem sokkal jobban átgondolt elnevezések vannak, akkor hitelesebb lesz az a kijelentésem, miszerint a Cake beliek nem azok." -- úgyhogy feltételezhetően erre _is_ gondoltál.
Elég sok konkrét dolog szóba jött már. Egy részük elvarratlan még, egy részükre én meg visszavonulva hümmögök. El kell ismernem, hogy van néhány die, amire nem találok én sem magyarázatot. Csak ebből túl sok következtetést nem tudok levonni. Ha jól számoltam, kb. 100 trigger_error-hívásunk és 10 árva die-unk van, amiből egyet megvizsgálva úgy láttam, hogy elő se lehet csalni. A többi is valószínűleg durva fatális. Ebből szerintem nem lehet rögtön levonni azt a következtetést, hogy a weboldalam egyszer csak die-ol. Először is az ember éles oldalon nem szokott fejleszteni, már csak azért sem, mert dev módban kell lenni. Tehát igencsak életszerűtlen, hogy ilyen fatális elő tudjon fordulni éles oldalon. Ergó az észrevétel jogosságát elfogadom, de a súlyossága melletti érvelést demagógnak tartom.
De itt alapvetően tényleg elbeszélünk egymás mellett, ahogy Gábor is írta: az észrevéleid közt vannak olyanok, melyek teljesen egyértelműen rámutatnak valamilyen gyenge pontra (mondjuk egy regény helyesírási hibájához tudnám hasonlítani), ezek között már kettő is volt olyan, ami az én legfrissebbemben máshogy néz már ki (az email logját nem néztem, arra írtam az óráról órárát, de a controllerben azok a sorok már elég régóta javítva vannak); s vannak vitathatók. Én elsősorban a vitathatókra szálltam rá. Ilyen esetben te folyton számonkéred, hogy fókuszáljak inkább az egyértelműekre. Mindkettőnk stratégiája nyilván érthető. S úgy láttam, miután beleevickéltem egy-két konkrétba is, még mindig makacsul fenntartottad ezt a számonkérést, ami kicsit szúrta már a csőröm.
Azért szúrta, mert közben elmaradt annak beismerése, hogy azok a nem konkrétak igencsak vitathatók. És te nem ilyen státuszban dobtad fel őket. Azok is a verdikt kimondásának hangnemét hordozzák. Azt hiszem, nekem nem kell minden pontodat egytől egyig falszifikálnom ahhoz, hogy megokoljam azt az állításomat, hogy gyorsan ítélkező, túlzott következtetéseket levonó, bombasztikus című poszttal állunk szembe, ami irreleváns módszerrel közelít egy frameworkhöz.
Most ha marad a 10-akárhány észrevételed közt 3, ami tényleg egyértelmű és evidens, akkor már minden rendben van? Abból még mindig semmilyen tanulság nem vonható le a cake-re vonatkozóan.
Úgyhogy nem kell összehasonlítani semmit semmivel, csak épp így nulla információhoz jutottunk. Kb. mintha azt mondanám, hogy XY regényben van 3 helyesírási hiba, és hogy Beckett hosszú és túlzsúfolt mondatokat ír (cake-ben is van osztálykompozíció, de nyitott vagyok itt is a lehurrogásra, ha nem jól látnám - ezt nem iróniából mondtam.).
rotfl
Komolyan... RTFM....
http://hu.php.net/manual/en/language.oop5.magic.php
"Caution
PHP reserves all function names starting with __ as magical. It is recommended that you do not use function names with __ in PHP unless you want some documented magic functionality. "
Mond ez neked valamit?
re> rotfl
Ettől függetlenül mielőtt valaki beleköt abba, hogy egy keretrendszer ilyeneket használ, talán figyelembe vehetné, hogy miért, és kiderül, hogy a dolognak sem a kód minőségéhez, sem a tervezéshez semmi köze.
hja...
De, hogy a PHP manuálban feltünően kiemelt, ép ésszel felfogható okokból kvázi-fenntartott prefixek közé szándékosan belegányol, az bizony tervezési hiba. Mer'hogy valszeg' náluk nincs olyan. Ahogy látom.
A kód minősége számomra meggyőző. Igaz enélkül sem rajongok a keretrendszerekért. Ezzel együtt meg végképp nem.
Mivel a "miért"-ed csak egy légből kapott marhaság (PHP4-ről beszélünk, tehát kábé halottnak a csók dolog). Nem rossz, hogy szeretnék a metódus nevében megjeleníteni, hogy hogyan definiálják azt. Csak ne egy kifejezetten fenntartott módon tegyék, mert ezzel szándékosan szembemennek az amúgy sem túl erős PHP konvencióval. Aminek a vége még nagyobb káosz. Ha már te ezt a szót használtad valahol a PHP-re...
Ráadásként pont fordítva csinálják, mint értelmes lenne... A private lesz a '__' és a protected a '_', közben meg ugye egy extend után éppen a private az, amit még felül lehet definiálni... Szóval a PHP4 káoszát a Cake csak erősíti.
érdekes vagy
Az én miért-em? Légből kapott marhaság, hogy egy keretrendszer prefixekkel jelöli a láthatóságot a php4-kompatibilitáshoz? Ez nekem kicsit képzavaros (függetlenül attól a kérdéstől, hogy mennyire hasznos a php4-kompatibilitás).
Ha még erős lenne, volna is jelentősége, de így éppenhogy nincs.
Fordítva van.
(Valahogy látszik még a magyar fórumokon és sajnos itt a weblaboron is, hogy sokan a flame-kultúrából jöttek. Megszámolhatnám, hány gyerekes ROTFL-okat, LOL-okat meg ÁÁÁ-kat kaptam -- smiley-k is enyhén túl vannak használva, de ez legyen az én savanyúságom --, miközben úgy tűnik, senki sem tökéletes...)
rotfl, lol: flame-kultúra
A Miérted valóban hiányzik. A belinkelt miért egy "agree" a cake részéről, miközben a php doksiban ugyanez egy "recommended". Ha már amerikaiak a fejlesztők illene érteni angolul egy kicsit, vagy legalább az alkalmazott nyelv dokumentációját ismerni.
A miért valami ilyesmi lehetne:
1. azért használja ezt a jelölést, mert szeretné private és a protected dolgokat jelölni (controlleren kívül semmi jelentősége nincs) - ezt már hallottuk itt.
2. a controller miatt használja: cake alatt a controller "bármely" actionje meghivható kívülről. Viszont szükségük volt olyan metódusokra, amelyek nem érhetők el. Ezt jelölni kellett. Hirtelen 2 lehetőséget látok:
a) vagy a publikus metódusokat jelölöd (pl: symfony)
b) vagy a többit (pl: cake)
Nem hiszem, hogy a két választás közül az egyik jobb lenne, mint a másik. Az viszont meglepő, hogy a cake ennyire belenyúlt a választásával.
igaz...
Sorry, kora reggel volt még nekem.
Csak annyiban a te miérted, hogy te hoztad fel. Természetesen a Cakeseké valójában. Mint említettem a prefixelés persze nem az. Csak az marhaság, hogy éppen egy védett prefixet kellett erre találniuk.
S egészen addig nincs jelentősége, amíg te nem PHP5-ben futtatod a Cake-t, és nem definiálnak (vagy akár te magad az ő konvenciójukra építve) felül egy vagy dokumentált, vagy nem dokumentált, de a fenntartott prefixszel ellátott magic metódust.
Remélem te is érzed, hogy ez mekkora kockázat. Bár már a legelső felvetésnél rá kellett volna jönnöd.
PHP névtér
Először is: úgy tűnik, hogy nem vagy tisztában a névtér fogalmával. Ez nem feltétlenűl baj. Egy változónak számos tulajdonsága van, többek között az is, hogy az adott változó a programkód melyik területén érvényes.
A php többféle névteret ismer:
A névtereken belül a névütközések elkerülése végett szokták alkalmazni a prefix vagy suffix-szel való ellátást. Biztos van másféle megoldás is, pl. névtér definiálásának támogatása nyelvi szinten. De ez tulajdonképpen az előző módszer elfedése.
namespace != scope
ettől még értelmes a hozzászólásod, csak az a része vált bizonytalanná, hogy fraki ne lenne tisztában a névtér fogalmával.
Hú de régen volt
Szerk.: Ezen kívül a php-ben külön névtere van a változóknak, a konstansoknak, a függvényeknek, a metódusoknak, a tulajdonságoknak. Lehet ugyan olyan nevű konstans, változó és függvény is a php-ben, nem történik névütközés. De lehet, hogy más nyelvben máshogy van.
Névtér
Igen
Igen, és?
terminológia
namespace = névtér
visibility = láthatóság
scope = hatáskör
re: cakphp
Azt a kódot hol találtad? (controller.php 641. sorától valami egész más van)
re: cakephp
A mail komponens szinte óráról órára változik még.
Lehet, hogy valamit félreértek, de eleve ott az M, C és V: kompozit osztályok. Aztán az egész component mechanizmusa az általad hiányolt mintát követi (Session, RequestHandler stb.). A sok singleton használata is erre hajaz (Router, Inflector, Config elérés). Mondanod kéne olyan példát, ahol az öröklődés nem jellemzően specializálja a szülőjét. Ahogy nézem, van egy absztrakt alaposztályunk, az Object. A fő osztályok zöme ebből van származtatva, és nincs agyonhierarchizálva.
Az alap példa is tipikusan rossz megoldás abból a szempontból, hogy nem generál új munkamenet azonosítót a bejelentkezéskor.
Annak azért az a neve, hogy simple... Mert nem használja az Auth komponenst. Az Auth komponens generál. (1.1-ben lehet h nincs Auth)
dokumentáció
Tök jó
Remélem egy hivatalos CakePHP fórumra is feldobod majd.
üdv:b
móka és kacagás
móka és kacagás:
CakePHP vs Rails
/off
Kellemes írás
Kíváncsi volnék, hogy hasonló írás fog-e születni a ZF -ről.
Pár hete az egyik fejlesztővel volt egy vitám a view dolgokról és kicsit idegesen(meg dühödten) néztem végig az általam ismert keretrendszereket, hogy hol miképpen dolgoznak ezekkel (milyen eszközök vannak arra, hoyg minél kevesebb html kódot kelljen írni). Emlékszem, hogy akkor meg is akadtam egy pillanatra, hogy a CakePHP fut PHP4 -n is. Felmerült bennem a kérdés azonnal, hogy minek... (illetve a kollegám ideges arca pár órányi referenciákkal való küzdés után)
zend framework áttekintés, view kezelés
Ezzel együtt rengeteg dolog szól a ZF mellett, egyrészt tekinthető defacto PHP frameworknek, nagyobb eséllyel fogsz (főleg az idő haladtával) ZF tudással munkát találni, mint egy másikkal, plusz valszeg nagy valószínűséggel elég jó IDE támogatást fog készíteni hozzá a Zend.
A View része a ZF-nek per pillanat nem egy nagy durranás (pont keresgettem én is ilyen téren nem olyan rég), de van egy elég ígéretes proposal. A legtöbb frameworkben a view nagyjából a layout támogatásban merül ki, de pont a Symfonyban ez szerintem nagyon jól ki van találva (sokban hajaz az említett ajánlásra), mi egy projekt során alapvetően ez alapján csináltunk egy saját megoldást.
Üdv,
Felhő
Spórolás
Mivel a ZF -ben ez még kezdetleges elkezdtem magamnak egy ilyesmit csinálni és az ilyen saját dolgok meg jól illeszthetőek a ZF view megoldásába. Magával a megvalósítással kimondottan van munka, de ha egyszer (végre) eljutok oda, hogy a kívánt eszközkészlettel fogok rendelkezni ezen a téren, akkor jön a spórolás ideje, mert csak metódusokat kell meghívogatnom nem html kódot gyártanom.
További előnye, hogy ha változik a html referencia, akkor csak egy helyen kell majd átírni egy kicsit a dolgokat.
Kissé kesze-kusza volt ez a gondolatmenet, de valahogy így képezelem el a "spórolás" témakört, amit említettem.
PEAR HTML osztályok
Sok
Példa:
Zend Framework - mert tetszik és látok benne valami jót
AdoDB -> adatbázis kapcsolat miatt
PEAR -> a html miatt
És még lehetne sorolni. A verziók rabja leszek idővel. Inkább én azt választom - bevállalva egy kevéske teljesítmény csökkenést is, hogy az egész alkalmazást ZF -re építem. Abban van adatbázis megoldás (lehet, hogy nem olyan jó, mint az AdoDB) és most agyalnak a View megoldásokon (illetve itt kopácsolom én is a magamét).
Persze az AJAX külön kérdés. Ebben nem vagyok hajlandó a melegvízet feltalálni :) Szerintem jQuery...
A PEAR kapcsán pedig van egy olyan érzésem, hogy nagyon mostoha gyerekként van kezelve. De ez csak érzés.
cakephp
Kihagyom
Második szempont, hogy most (2 szakdolgozat, egyetem, munkahely, magánélet) tényleg nincsen időm.
ezzel nem vagy egyedül
zend
A ZF max de jure php framework, a de facto-ra még várni kell.
Válasz
kíváncsi vagyok
Teljesítmény
A Paul M. Jones-féle benchmark alapján úgy látszik, hogy gyorsabb a cake, mint a symfony.
Ezek után elvégeztem egy kis házi mérést (ugyancsak hello world):
1. cake (1.2 legfrissebb SVN)
2. symfony (sandbox 1.0.7)
Vas: Core2 4300 (i965p), 1gb ram, 7200 vinyó
Szoftver: WinXP SP2, XAMPP 1.6.1
Parancs: ab -t 60 -c 10 ...
Mindkét rendszeren bekapcsolva maradt a layout és a session (bár ez utóbbiban csak a cake esetén vagyok biztos).
Mindkét rendszeren 3-szor futtattam a tesztet.
Eredmények (Complete requests):
1. cake: 1296, 1255, 1225 (átlag: 1259, logok, app könyvtár)
2. symfony: 1420, 1436, 1415 (átlag: 1424, logok, apps könyvtár)
UI.: Felhő: a cake a branch ágban tartja a legfrissebb svn verziót nem a trunk-ban (az írás alapján a trunk-ot checkout-oltad), bár ez nem sokat számít az összegzés szempontjából.
Benchmark nehéz ügy
Jaja
Különben is kevés olyan oldal van, ahol csak egy Hello World jelenik meg :), általában aktívan használnak adatbázist, session-t,... , és ahogy írtad, az már nem csak a framework teljesítményét méri.
Benchmark?
Ne értsetek félre, semmi baj az optimalizálással, de ha választanom kell a keretrendszert használó kényelme / gyors munkavégzése és a felhasznált processzoridő között, akkor az előbbit választanám. Annál is inkább, hogy a vas árak folyamatos zuhanásban vannak. (Fél évvel ezelőtt vettem 250 gigás SATA lemezt 24000-ért, most már 500 gigásat lehet ugyanannyiért kapni.)
mér kéne választani?
Amúgy meg így születnek a kiskukutyinkft.hu jellegű site-ok, amik önmagukban lefognak egy szervert... közben meg még vagy harminc hasonló site-ot elbírna az adott vas, ha egy picit optimálisabb kódot használnának az elkényelmesedett fejlesztők. (Köztük én is, mert a blogom alatt wordpress fut, amíg nincs időm befejezni a saját cuccomat, ami kicsit gyorsabb lesz, cserébe persze az általános célúságról le kell mondjak...)
attól függ
1. a vas már jó ideje olcsóbb, mint a fejlesztő
2. ez nem jelenti azt, hogy vassal bármilyen gány megoldást ki lehetne/kellene kerülni.
Az én választásom: optimális kód, optimális vason (a többit majd Szőke kapitány intézi ;) )
Hogy miből mi az optimális? Azt mindenki döntse el az adott szituációtól függően.
stílus és tartalom
Nem tisztem megítélni az írást tartalmilag, mert nem ismerem se a rendszert, se a kódját, de annál jobban érzem azt, hogy stilisztikailag is a Weblaboron megszokott minőség alatt van. Persze erre rögtön már az elején kapunk is egy mentséget, hogy ez ugye csak egy blogbejegyzés és ott simán röpködhetnek olyan szavak, hogy "para" (most csak egyet találok belőle, de első olvasásra jóval többre emlékszem - szerkesztetted azóta?). Ez teljesen helyénvaló is egy saját blogon, belinkelve a blogmarkok között (lásd Bence Silverlight-os ismerkedését), amit szívesen végigolvas a tudásra szomjazó kis kocka (=én), de itt a Weblaboron már többet vár az ember. Hiába, megszoktuk a jót.
re: stilus és tartalom
Üdv,
Felhő
no flame
session
A mixed valószínűleg a dokumentáció deficitje. A __validateKeys függvény nevével mi baj? A cake rengeteg más helyen használ dot-notációt (formhelper, Set stb.), így a session-nevek esetében is, ezt validálja az a fv. Ez sem kódminőség-, hanem koncepcionális kérdés.
Erre mondanál példát? A PHP-ban a session nevekre a változókra érvényes limitációk vonatkoznak. UTF-8 kulcsokat szeretnél? Ok, kijelenthetjük, hogy a cake core session kezelője nem kezeli az UTF8-as session kulcsokat. Csúnya, rossz cake...
Ahhoz képest, hogy a php-ban semmilyen névtere nincs a munkamenet-kulcsoknak, eleve elfelejtjük megemlíteni, hogy itt egyáltalán _van_ névtere a kontrollereknek és komponenseknek, és hogy ez tök jó (most kicsit parasztvakítottam). Adnak a Config singleton mintájára neked Config kulcsot, amibe a konfig adataidat te is belerakhatod. És istenem, felül is írhatod.
Megint nem kódminőség, és még csak nem is tervezés kérdése, hanem koncepció. A cake-et nem arra tervezték, hogy megvédje magát a szándékosan gányolóktól. Alapvetően CoC-re épül. Szerintem olyat vársz el tőle, amit nem is vállal, és nem is akar felvállalni.
re: session
Üdv,
Felhő
re: session
Ha figyelembe vesszük, hogy a paraméter alkulcsokat tartalmazhat, akkor az kulcsok. Amellett, hogy ezek az alkulcsok dotnotációban egy stringben vannak tárolva. Nincs ezzel különösebb baj.
Igyekeztem körültekintő lenni.
"The keys in the $_SESSION associative array are subject to the same limitations as regular variable names in PHP, i.e. they cannot start with a number and must start with a letter or underscore. For more details see the section on variables in this manual."
Nem egészen erről van szó. Csak úgy dot-notációval nem tehetsz kulcsot a session-be, a dot-notációval csak a kontrollerek és komponensek alá tehetsz információt, tehát kifejezetten ezeknek biztosít ily módon ponttal elválasztó névteret. Ez a viselkedés egyébként általános minta a cake-ben.
Nem független, ezt nem is mondtam, de nem is ugyanaz. Ha egy framework koncepciójában nem szerepel az, hogy megvédje magát az applikációt szándékosan szétgányoló használójától, akkor nem is úgy tervezik.
----------------
De végig azt érzem, hogy red herringeket dobálsz, vagyis eltérünk a mondókám lényegétől. Nem azt mondom, hogy ezek a felvetéseid ne lennének önmagukban jogosak, hanem azt, hogy a poszt címének és tételállításának szempontjából nem relevánsak, illetve kifejtetlenek, és mindenképp elégtelenek ahhoz, hogy rögtön ilyen ítéleteket alkoss belőlük. Ehhez képest úgy teszünk, mintha nekem minden pontodat meg kéne cáfolnom, pedig bőven elég néhány pontod kérdésességére vagy kifejtetlenségére rámutatnom. Ráadásul én vagyok a fárasztó butaságokkal előjövő emberke, holott most te is szépen beleszaladtál egybe (letehetsz int kulcsot a session-be, csak semmi értelme, mert nem jegyzi meg; már csak ezért is hasznos a cake validációja).
Ott is egyensúlytalanságot érzek, hogy ki mire reagál, és mit vár el a másiktól. Miközben folyamatosan mentem bele a további konkrétumokba, bár az állításomhoz ez nem szükséges, folyton csak arra hivatkozol, hogy kikerülöm őket, ugyanakkor te is szelektívan reagálsz (a renew()-szálat például folytathatnád).
Itt van ez az objektumkompozíciós dolog is. Attól, hogy van egy nagyon általános elv, hogy az objektumkompozíció előnyösebb az öröklődésnél, ettől még a cake-nek egyáltalán nem túlbonyolított az osztályhierarchiája. De még önmagában az sem minősít egy kódot, hogy nem követi 100%-ban az OOP mintákat.
Szóval maradnék annál, amit mondtam kezdettől fogva. Elvitatkozhatunk arról, hogy látszik a Titanic egyik snittjében a kamera a háttérben, és hogy ez milyen para, attól még ha írsz egy ilyen kritikát a filmről, hát nem sokmindent fogok róla megtudni.
rere
"The keys in the $_SESSION associative array are subject to the same limitations as regular variable names in PHP, i.e. they cannot start with a number and must start with a letter or underscore. For more details see the section on variables in this manual."
Lásd a __ használata. Teljesen egyértelmű, hogy nem egy szerencsés választás, de Te azt mondod, hogy DE, és csodálkozol, ha azt mondja rá Neked valak, hogy LOL. És nem hiszem el, hogy nem látod be, hogy ez egyszerűen veszélyes, folyamatosan kerülnek be a PHP-ba magic függvények, bármikor borulhat az egész, és igazából bármilyen más jelölésmódot használhattak volna. Ez egyszerű nem tudásból fakad, ha ezt tudja valaki, akkor egyszerűen suicid hajlama lehet, ha mégis emellett dönt. De Benned ebből is az marad meg, hogy de a Cake jól csinálja.
Rövidítések. Ez lehet szubjektív, bár szerintem amiket írtam ezzel kapcsolatban az is eléggé egyértelmű. Plusz amiért nem tetszett eredetileg, az az, hogy nem érzem benne a koncepciót (ami mondjuk a prototype esetén nem mondható el). Például substr miért nincs (str_replace mellett szerintem a leggyakrabban használt szövegkezelő függvény)? És itt is leírom, hogy nem használja konzekvensen, akkor azt mondod, hogy DE, közben ott a kód.
Mail komponens cserélgetős hibája: az nem hiba, az a kód óráról-órára változik. Ez LOL, akármit is mondasz. Ráadásul azt sose értettem, hogy egy egyértelműen rossz megoldás esetén miért védekezés az, hogy ez most csak egy átmeneti megoldás. Aki ilyet ír le, annak nincs tapasztalata biztonsági kérdésekben, ez egyértelmű, mert ezt a megoldást szokták tipikus rossz megoldásként felhívni.
És itt is Te arra gondolsz, hogy én azért mondtam, mert hogy szerintem elbonyolított a Cake osztálystruktúrája, közben én semmi ilyet nem mondtam, nem is néztem utána. Az objktum kompozíciónak számtalan más előnye is van, ez csak egyik, hogy bizonyos esetekben meg tudja akadályozni az osztály hierarchija robbanásszerű növekedését.
Üdv,
Felhő
Hozzászólások lezárva