Ce framework-uri PUBLICE folosiți și de ce?

Cunoaștem problema: majoritatea site-urilor au opțiuni comune iar scrierea de cod asemănător iar și iar e obositoare și frustrantă. Pentru a evita asta folosim framework-uri.
Personal am experimentat cu câteva dintre ele, însă nu am timp destul să le studiez amănunțit pe toate pentru a putea decide care dintre ele este cea mai bună. Criteriile cărora le acord atenție deosebită sunt consumul de resurse (RAM și CPU) și calitatea documentației/manualului oficial.

Cine are experiențe solide cu un framework este rugat să ni le împărtășească, alături de o evaluare cât mai obiectivă a punctelor forte și a dezavantajelor. Dacă cunoști mai multe framework-uri, atunci poți face și comparații.

Altfel spus, nu este de ajuns să ne spui că folosești un anumit framework și că e cel mai bun sau că l-ai folosit pentru sute de proiecte, iar opțiunea "you own" o știm cu toții deja

Pe web există astfel de evaluări, însă acestea sunt făcute de o singură persoană și, de parcă nu ar fi fost de ajuns, și pe o perioadă scurtă de timp, deci superficiale.

Deci insist să faceți afirmații acolo unde chiar aveți cunoștințe de cauză. Toate părerile vor fi apreciate. Mulțumesc.

Edited by OriginalCopy, 03 September 2008 - 12:34.

Pai daca ai experimentat cateva te astept sa scrii despre ele. Chiar eram curios .. poate imi schimb parerea (nu prea buna) despre framework-urile scrise in PHP.

Nu pot scrie despre ele din moment ce nu am folosit nici una (doar experimentat putin). Contactul meu cu ele nu a fost suficient, si nici nu vreau sa investesc timp orbeste in asa ceva.

In cadrul firmei unde lucrez am folosit timp de un an un framework propriu bazat pe MVC. Erau doua fisiere mari, un controller.php care verifica toate actiune facute de user, si un delegate.php unde erau tinute intr-o clasa (delegate) toate methodele folosite in aplicatie (getClientById, getClientByName, updatePasswordById, etc, etc). Controllerul verifica datele, delegateul era legatura cu baza de date. Ca si mod de lucru e foarte simplu. Oarecum scapi de spaghetii code (nu in totalitate), si e usor de facut debugging pe el. Problema e ca cele doua fisiere ajungeau uneori la 10-20 de mii de linii, enorm. Foarte naspa era ca daca voiai sa iei ceva dupa id, trebuia sa ai getClientById, getUserById, etc. Cand s-ar fi putut face mult mai simplu, insa asta era modul lor de lucru.

Ceea ce incerc zilele astea e sa imbunatatesc acel framework (daca se poate numi asa).

Edited by nasorum, 04 September 2008 - 16:59.

Firmele de productie nu folosesc framework-uri care le gasesti la download-at, ci folosesc framework-uri custom.
Deci daca vrei sa faci un soft mai complex mai bine iti dezvolti framework-ul tau sau vei avea mari probleme cind vei ajunge sa scrii cod din ce in ce mai complex.

 cuigri, on Sep 9 2008, 21:08, said:

Nu am scris nimic complex in framework-urile alea.. il folosesc pe al meu custom, dar asta din alte motive. De ce crezi ca nu fac fata unor cerinte complexe? (eu cred ca PHP-ul e de vina nu framework-urile).
Poate ar fi mai indicat un thread de genul "ce asteptati de la un framework/toolkit pentru web".

Offtopic: Abia astept sa dea drumul firma mea favorita de hosting la FastCGI-uri.. si adio PHP, welcome C++

Edited by florindinu, 10 September 2008 - 08:36.

CakePHP pentru ca are cel mai activ canal de IRC din cate am vazut vreodata la un limbaj de programare (orice limbaj nu numai PHP) ... daca pui o intrebare pe acel IRC primesti raspunsul aproape instant ...

 florindinu, on Sep 10 2008, 09:22, said:

Pai nu cred ca fac fata la chestii complexe pentru ca sint sa zicem programare "high level". Daca vrei sa adaugi functionalitati noi inseamna ca intri in framework si nu mai poti face usor update-uri la versiuni noi, deci devine tot un fel de custom framework.

Doar daca vrei sa faci niste module pe care vrei sa ai viteza mare de executie (damon sau un server ceva) (sau daca iti place mai mult sa programezi in C) ar trebui sa lucrezi cu cgi-uri. In rest PHP-ul face fata fara probleme...

 cuigri, on Sep 10 2008, 22:24, said:

Aici cred ca depinde de framework si de cum a fost gandit, ai dreptate dar nu toate sunt asa. Framework-ul pe care il folosesc a fost gandit sa fie extensibil, daca stii ce faci poti sa adaugi module noi lucrand doar cu api-urile expuse, poti adauga si cuvinte cheie pentru parser doar extinzand o clasa si inregistrand noul token, toate astea pastrand posibilitatea de upgrade. (in momentul de fata versiunile noi nu sunt compatibile cu cele vechi asta pentru ca inca e la inceput si se schimba api-urile, dar odata stabilizate nu cred ca vor mai fi probleme)

 cuigri, on Sep 10 2008, 22:24, said:

Din nou ai dreptate cu CGI-urile dar nu vorbeam despre ele ci despre FastCGI, e un model cu cateva diferente care te lasa sa faci un design eficient pentru orice website (desigur e cam overkill pentru site-uri simple). Uite un articol care explica mai bine aceste diferente: http://cryp.to/publications/fastcgi/, si un toolkit inspirat de Qt care poate genera si FastCGI-uri: http://www.webtoolkit.eu/wt#/

Folosesc propriul framework MVC. Am folosit CakePHP si am plans; am ramas placut impresionat de CodeIgniter.

la fosta firma foloseam symfony, in prezent am trecut pe zend framework.
prefer symfony pt ca este mai organizat fata de zend, totusi. nu prea am ce sa zic de ele nimic special: ambele-s mvc, ambele-s bine documentate si intretinute de comunitate.

 cuigri, on Sep 9 2008, 19:08, said:

vorbesti prostii

 cuigri, on Sep 9 2008, 19:08, said:

cu cat o sa fie mai complex cu atat o sa fie mai greu de intretinut si de invatat. sunt toal impotriva framework-urilor interne.

Edited by zuppy, 22 September 2008 - 10:44.

 zuppy, on Sep 22 2008, 11:43, said:

Daca vorbesti din perspectiva unei firme care schimba des angajatii ai dreptate.

Oricum chestia asta cu ce framework folositi si de ce este cam la fel cu ce editor de text folositi si de ce. Toata lumea isi va spune parerea ca ala e cel mai tare si face nu stiu ce minuni. Depinde de de felul cum programeaza fiecare si cum le este comod. E greu sa gasesti ceva ce ar multumi majoritatea oamenilor. (nu spun toata lumea ca nu exista asa ceva).

Edited by cuigri, 23 September 2008 - 12:34.

Din instinct mi-am dedicat atentia lui Zend Framework. Ca un purist ce sunt, m-au dat gata "loose coupling" și acele "object-oriented best practices" - își merită numele, nu e doar o formulare "de marketing". Ca să nu mai zic de licență.

Totuși, exemplele de cod sunt puține, iar documentația este greu de urmărit. Trebuie să citești câteva articole în paralel ca să te prinzi ce și cum, mai ales când folosești un alt directory layout decât cel standard. Adevărul este că nu te forțează să îți construiești "aplicația" într-un anumit fel - poți chiar folosi un Zend_Layout fără MVC. Iar mutarea de la un directory layout la altul poate necesita nimic mai mult decât un apel la o metodă. Dar dacă faci mofturi și vrei ca un director să se numească "foo" în loc de "controllers" atunci trebuie să adaugi încă un apel la o metodă. În general oricum ți-ai modulariza și organiza fișierele într-o manieră asemănătoare cu cea standard in ZF.

ZF nu te forțeză nici să folosești un anumit template engine. Are unul bazat pe PHP simplu, și se poate extinde cu altele (smarty printre ele). Cu Zend_Form poți genera formulare direct din PHP, ceea ce adaugă overhead, însă presupun că se poate face cache cu Zend_Cache. În schimbul overhead-ului, poți face și prelucrarea formularului tot în aceeași clasă în care o definești, ceea ce conduce implicit la mai puține buguri stupide (dar dese)
ZF vine cu Dojo, însă nu am testat formulare cu AJAX încă. Presupun că poți integra la fel de ușor apeluri asincrone - de ex pentru verificarea validității datelor înainte de trimiterea lor prin http în mod tradițional.

Momentan nu (prea) există module (ex "guestbook", "forum" etc), însă ZF oferă o platformă bună pentru dezvoltarea propriilor module. Exact asta e ceea ce mi se pretează mie cel mai bine, pentru că nu am chef și timp să studiez un framework cu zeci de "module" reutilizabile, care să aibe totuși nevoie de modificări - lucru care poate aduce multă frustrare în plus. Deci pe un purist îl scapă de frustrare.

Datorită "Proposal Lifeycle" poți fi sigur că ce intră în repozitoriile oficiale (Zend și ZendX) este bine gândit și sigur/stabil. Un mare minus este suportul comunității. zfforums.com, canalul IRC #zftalk @ freenode sunt aproape moarte.

Concluzie: categoric bun pentru cine trebuie să facă lucruri stabile de la zero, și bine/corect. Categoric nerecomandat celor care trebuie să-și facă treaba repede.

LE

 cuigri, on Sep 23 2008, 12:33, said:

Corect, este o întrebare pe același calapod, dar totuși la un nivel mai înalt, pe care sper să îl menținem pe parcursul discuției, altfel va trebui să-l mut și p-ăsta la Începatori

Sper să nu apară flame-uri și să participe doar oameni destul de experimentați în PHP care știu că nu există "scula perfectă" ci doar "scula perfectă pentru proiectul curent", asta în funcție de punctele forte și punctele slabe ale fiecărui framework. Exact acesta este scopul thread-ului: culegerea de puncte forte/slabe. Fiecare decide pentru el într-un final.

Edited by OriginalCopy, 27 September 2008 - 19:10.

 cuigri, on Sep 23 2008, 12:33, said:

orice firma isi schimba angajatii, mai devreme sau mai tarziu.

framework-urile interne sufera de mai multe lacune:
- prima si cea mai importanta este documentarea. m-as mira ca un framework intern sa fie documentat la un nivel indeajuns de bun. m-as mira sa gasesti pe google raspunsuri la problemele de care s-au lovit si altii inaintea ta.
- maturitatea: cate framework-uri interne pot sa fie considerate mature? cate feature-uri sunt "mereu in lucru"™ ?
- securitatea: tuturor ne mai scapa cate un bug prin diferite locuri. nu spune ca tie nu ti se intampla . simplul fapt ca pe codul ala arunca ochii mii, zeci de mii de persoane conteaza enorm.
- reinventarea rotii: de ce trebuie sa facem ceva doar ca sa fie al nostru, daca el deja a fost inventat in 100 de forme (testate si suportate de propria comunitate).


de ce ar trebui sa renuntam la toate avantajele oferite de framework-urile open source conscacrate si sa folosim ceva proprietar? de ce sa pierdem posibilitatea de a gasi usor un raspuns pe google? nu-mi spune ca asta nu conteaza, mai ales la o firma de dimensiune medie.

Ok, ok, am avut o mica scapare in titlu si profitati de ea observ Thread redenumit.

Vă rog on-topic:

 OriginalCopy, on Sep 3 2008, 12:31, said:

Hm ... ei bine eu personal tind sa agreez folosirea unui framework intern poate pur si simplu ca in decursul a peste 5 ani de programare php am ajuns sa construiesc unul destul de stufos la care eu si echipa cu care lucrez ii stim toate dedesupturile. Cand spun ca stiu exact fiecare clasa, functie, bucla si if care se executa intr-o anumita situatie nu exagerez. Pot efectiv sa ma plimb cu imaginatia prin fiecare linie de cod, lucru care n-am sa-l pot niciodata face pe un framework extern. Cele mai multe probleme le izolez instant in citeva secunde de gindire fara apelul la nici debuger, documentatie online sau ore intregi de cautari intr-un cod total strain. La asta adaug faptul ca denumirile claselor si metodelor imi sunt la fel de familiare ca limbajul php in sine.

Pe de alta parte cind suntem obligati la cerinta clientilor sa folosim un framework extern intodeuna sesizez o crestere a timpului petrecut pentru cele mai minore modificari. Cautari nesfirsite in codul sursa. Instalari de pluginuri la care sa recunoastem citi dintre noi fac analiza codului etc. In general daca securitatea oferita de un framework extern poate fi destul de buna spanacul care rezulta dupa instalarea a zeci de pluginuri din surse diferite transforma orice framework open source intr-o necunoscuta totala si intr-o aplicatie foarte nesigura.

Si mai vreau sa remarc ceva ... multe din framework-urile open source din ziua de azi au fost la origine framework-uri interne!

Este evolutia fireasca si probabil ca si noi in viitorul apropiat o sa publicam framework-ul nostru intern. Asadar cred ca locul unde sa intimpla revolutii, apar idei si lucruri noi este tocmai in domeniul acestor frameworkuri interne. Cele deja consacrate ajung inevitabil sa poarte in spate o arhitectura veche, de multe ori plina de greseli facute cu ani in urma. Greseli care sunt perpetuate in noile versiuni de multe ori doar datorita faptului ca nimeni nu doreste sa dea peste cap intreaga colectivitate de utilizatori facind schimbari radicale.

Asadar cine blameaza framework-urile interne uita ca multe din ele sunt sursa progresului si unele intr-o zi vor ajunge noul framework open source la moda. Daca ne-am rezuma toti sa folosim numai ce au facut altii deja acest progres nu ar mai avea loc!

Edited by alopia, 09 October 2008 - 00:49.

 alopia, on Oct 9 2008, 01:42, said:

Exact ceea ce vroiam eu sa spun, numai ca mai in detaliu...
As putea adauga ca la fel cum sint multi oameni care gindesc posibilele scapari de securitate din framework-ul open-source, sint si oameni care cauta aceste gauri pentru explioturi. In caz ca gaseste cineva o gaura in frameworkul opensource care il folosesti (lucru care nu ti l-as dori) vei avea int-adevar de lucru la debug-uit si cautat. Daca stii cum zicea si alopia framework-ul pe din afara nu ar fi o problema (nu zic ca nu ai putea stii pe din afara si framework-ul opensource).

zuppy said:

Daca oamenii se schimba de la o firma la alta ar trebui sa invete framework-ul agreat de noua firma.

ei bine daca tot venii vorba de un framework, (chiar de nu l-am folosit, apropo nu vreau warn pentru post) este barebonesMVC-PHP. e foarte simplist, in 60 de linii de cod (comenturile nu sunt calculate) si ofera o functionalitate minimala, dar totusi foarte flexibila. ar putea fii baza unui framework propriu... exemplul de la pagina proiectului ilustreaza simplitatea implementarii lui...