Mi-au trebuit diverse chestii pentru afişare. De exemplu:
<?= e::int($val) ?>
Aici sunt sigur ca va afisa integer.
<= e::num($val) ?>
In MySQL daca ai un câmp de tip DECIMAL(5.2), daca afisezi direct <?= $val ?> va afisa mereu zecimalele, de exemplu 13.00, ceea ce nu vreau sa se intample, vreau sa afiseze zecimalele doar daca e ceva de afisat. Daca aduni numarul ala cu zero, va face exact cea vreau, “13”.
<?= e::cond($blabla == true, "afiseaza acest text) ?>
Asta e un fel concis de a afisa un text doar cand conditia este true. In template-uri nu-mi place sa am chestii de genul asta, daca pot sa le evit:
<?php if($blabla == true) echo "afiseaza acest text" ?>
Păi și abordarea ta cum face treaba mai bună? Pentru că iei o banală condiție și o abstractizezi inutil. Nu scrii mai puțin și cu siguranță nu e mai ușor de citit…
<?= e::cond($blabla == true, "afiseaza acest text) ?>
<?php if($blabla == true) echo "afiseaza acest text" ?>
Cand codul este un mix imbarligat de html si php gasesc ca e mult mai dificil sa localizez dintr-o privire ce face if-ul ala. Cand vad e::cond imi dau instant ca e vorba strict de afisare conditionala. De exemplu asa:
De ce n-ai face o metodă selected care întoarce doar atributul, pe care o apelezi <?= selected( $default, $value ); ?>?
Acum facem cherry picking, nu vreau (vrem) să te descurajăm sau să te dezumflăm. Ci doar că toate aceste mărunțișuri nu fac decât să argumenteze de ce e mai bine să folosești un framework public în defavoarea unuia custom.
Eu cred că un framework custom e un exercițiu bun, din care poți învăța multe, dar nu cred că ar trebui să se meargă prea departe, cu folosirea lui într-un proiect live șamd dacă nu vine cu ceva nou.
Symfony a venit cu conceptul de „totul e un pachet extern, fiecare folosește ce are nevoie”. Laravel a dus conceptul mai departe, adăugând și „cât mai multe teste”. Al tău cu ce vine?
Și nu e vorba că nu va fi adoptat de mulți și îl vei folosi doar tu ci e vorba că, cel mai probabil, pe codul tău va lucra la un moment dat și altcineva, moment în care lucrurile vor deveni cel puțin interesante pentru unii.
Un nou framework n-ar trebui să reinventeze roata doar pentru că are prea multe spițe
Pentru că atunci ai face o functie mult prea specializata, utila doar pentru “selected”. Eu am dat doar primul exemplu care mi-a venit in minte, sunt o gramada de alte situatii asemănatoare si voiam ceva cât de cât generic.
Ah, cârcoteala nu e problemă Multe din întrebările astea mi le-am pus şi eu la momentul ăla şi mi le pun şi acum, sunt genul mereu nemulţumit.
Nu intenţionez să vin cu ceva nou, pur şi simplu găsesc celelalte framework-uri prea îmbâcsite şi exasperant de lente. Sau dacă sunt mici şi rapide, au tot felul de limitări enervante sau convenţii care nu sunt pe gustul meu.
Dacă ar fi după mine, aş programa direct în raw-php (ceea ce am şi făcut până la un moment dat), dar după un punct devine prea îmbârligat dacă nu ai o oarecare separare între layer-ul de control şi cel de prezentare.
Şi exact asta a fost intenţia: să fac un layer foarte subţire între php şi developer, cu un “router” minimal, un auto-loader de clase, un view-render fără limite de imbricare şi câteva helpere pentru functiile pe care le folosesc intensiv (ca să nu zic “obsesiv-compulsiv” ).
Iar de lucrat pe codul meu… Probabil se va întâmpla mai devreme sau mai târziu. Dar arhitectura este atât de simplă încât nu văd ce problemă ar putea întâmpina cineva în înţelegerea lui. Cu mult timp în urmă am lucrat putin cu CodeIgniter, probabil seamănă un pic cu âla.
În ceea ce priveşte reinventarea roţii, well… dacă poţi să inventezi o roată mai uşoară si mai rapidă, de ce să n-o faci?
Iar pe mine ma enerveaza optiunile b,e,f, optiunile a,d,f imi sunt complet inutile, şi am neapărată nevoie de c,f,h.
Nu vi s-a întâmplat niciodată să nu vă puteţi hotărî la un framework/pattern, pentru că niciunul nu îndeplinea simultan toate condiţiile necesare? Până la urmă îl alegi pe cel mai puţin rău, după care îţi blestemi zilele că trebuie să-l scarpini în fel şi chip ca să-l convingi să facă ce trebuie.
Pe partea de web development n-am mai facut cercetari de câţiva ani, pentru simplu motiv ca acum am framework-ul meu, care nu mă poate dezamăgi
Dar hai să-ţi dau un exemplu pe parte de desktop: vrei sa faci o aplicatie cross-platform. Vrei sa foloseasca widget-urile native (ca sa oferi look & feel-ul specific fiecarei platforme), sa aiba layout manager, sa fie compact etc. Ai câteva variante: wxWidgets, Qt, FOX Toolkit, FLTK, Ultimate++ si alte cateva mai putin importante. Dar…
wxWidgets - foloseste widget-uri native, pe Windows şi pe MacOS arata bine si se misca bine. Pe Linux însă… e lent si foloseste de GTK+ pentru a arăta “nativ”. Urăsc look & feel-ului temelor GTK+. Lăbărţate ca naiba, de multe ori se comporta contra-intuitiv.
Qt - pare ca arată nativ, dar nu e nativ, widget-urile sunt emulate. Este gigantic, dar totusi destul de sprinten. Layout management-ul exista, dar dificil de folosit. Exista GUI builder, dar mai mult timp pierzi cu el decat sa scrii cod care sa genereze interfeţele. La momentul cand aveam nevoie de un toolkit inca nu avea licentă LGPL, altfel probabil as fi mers pe varianta asta.
FOX Toolkit - widget-urile nu sunt native, pe orice platformă arata ca o aplicatie de Windows 98. Extrem de greu de “infrumuseţat”, nu e facut sa fie “themeable”. Poate fi compilat pentru MacOSX, dar necesita XQuartz. Layout management superb, probabil cel mai bun pe care l-am vazut vreodată. Licenta permite linkeditare statică, binarul rezultat este foarte compact.
FLTK - cam ca FOX Toolkit-ul, dar mai urât si nici nu are layout management. Are câteva “teme”, dar urâte cu spume. Pe MacOSX poate rula “nativ”, in sensul că nu are nevoie de XQuartz. Binarele rezultate sunt foarte mici, este permisa legarea statica.
Ultimate++ - Foloseste o “tehnologie” pe care ei o numesc “Chameleon”, care face aplicatiile sa arate aproximativ ca alea native. Cred ca are si un soi de layout management rudimentar. Nu exista versiune de MacOSX. Developmentul este foarte dificil daca nu folosesti IDE-ul lor, asa-numitul TheIDE.
So… ce naiba să alegi? Sunt sigur că şi în lumea webdevelopment-ului ai alegeri cel puţin la fel de dificile: la ală nu-mi place cum se face rutarea, dar imi place cum se face autoload-ul, la celelalt e superbă rutarea, dar nu exista autoload, ala are un API beton dar un “hello world” se mişca de parcă ai implementa ditamai un motor de căutare. Samd.
Ştiu, e mult offtopic, dar sper că ai prins ideea
De fapt cred că aş trece multe cu vederea dacă framework-urile mainstream n-ar fi chiar atât de lente. N-am înţeles niciodata ce naiba au ele atâta de procesat. E un amărât de routing, vezi ce URL ai, faci un lookup ca sa vezi ce clasa trebuie instanţiată si ce metoda trebuie executată şi la gară…
Sunt sigur că şi în lumea webdevelopment-ului ai alegeri cel puţin la fel de dificile: la ală nu-mi place cum se face rutarea, dar imi place cum se face autoload-ul, la celelalt e superbă rutarea, dar nu exista autoload, ala are un API beton dar un “hello world” se mişca de parcă ai implementa ditamai un motor de căutare
Ce inseamna ca nu iti place cum se face rutarea sau autoload-ul? Sau ca nu exista autoload (hello, CodeIgniter, my old friend)? Din cate stiu eu, orice framework modern iti permite sa faci cam ce vrei in materie de rute si autoload e ceva atat de comun incat nici nu merita trecut la feature-uri.
N-am înţeles niciodata ce naiba au ele atâta de procesat. E un amărât de routing, vezi ce URL ai, faci un lookup ca sa vezi ce clasa trebuie instanţiată si ce metoda trebuie executată şi la gară
Dadeam nişte exemple random, habar n-am cum mai arată framework-urile moderne.
Well… Nu-mi pasă ce face el acolo. Mai corect, nu vreau sa facă nimic. Ai gasit ce clasă să instantiezi şi ce metoda să apelezi, gata, da-mi mie controlul, că ştiu eu ce am de făcut mai departe.
habar n-am cum mai arată framework-urile moderne
Nu-mi pasă ce face el acolo. Mai corect, nu vreau sa facă nimic
Ignoranta much?
E interesant ca nu vrei sa faca nimic si sa iti ofere tie controlul. Pana in momentul in care o sa vrei sa faca ceva, dar nu o sa stie cum. Si atunci o sa te apuci sa faci tu ceea ce un framework sustinut de comunitate face OOTB. Si o sa dai de probleme care deja au fost rezolvate de altii mult mai bine decat probabil ai putea s-o faci tu.
Pe de alta parte, nici nu pari sa intelegi ce reprezinta acele lucruri si cu ce te ajuta. Lasi impresia ca tot ce vrei e sa arunci cod care sa afiseze ce iti doresti tu, fara sa te intereseze de lucruri precum modularitate, extensibiltate sau mentenabilitate pe termen lung. Ceea ce e cam no-no in proiectele >=medii.
Also, nu mi-ai raspuns la intrebarile cu rutarea si autoload
Sigur, de ce nu. Chiar simţi nevoia sa ştii tot ce mişcă-n lumea asta? Eu nu.
Credeam că am fost clar, în titlul postării am scris “micro-framework”. Unealta potrivită la locul potrivit. Nu ai nevoie mereu de baros, uneori e suficient şi un ciocan mai mic.
Ce ai vrea să răspund? Ca în CodeIgniter se foloseşte un fel de autoload cu manivelă?
