Despre Django
In mai putin de doua saptamani voi avea un nou job, las la o parte Zope-ul si voi trece pe Django. Drept pentru care am inceput sa vad ce poate "Django in actiune" :)
Pentru inceput iata cateva lucruri care imi plac la Django:
- Fisierele de configurare sunt in Python. Un mare plus. Spun asta ca unul care de o luna - o luna jumate ma lupt cu editarea fisierelor de configurare in format XML. Postul asta, pe nume "Python is not Java", ar trebui sa fie un must-read pentru oricine se intampla "sa ia decizii" intr-un shop Python. Din pacate nu se intampla asa, dar asta deja e alta problema. Celor carcotasi ca mine cand vine vorba de fisiere XML de configuare li se spune "get a good editor, that can trigger the red alarm if your XML file is broken". Intrebarea e "ce e rau cu bietul meu editor Python, ce nu intelege XML?".
- Pana nu demult credeam ca ZODB-ul "batea la fund" RDBMS-urile PostgreSQL sau MySQL. Nu atat din punct de vedere al performantei, cat din punct de vedere conceptual. Imi zaceam ca e mult mai misto ideea de a stoca obiecte ce pot avea atasate atribute, metode etc. Pe cand in MySQL de exemplu se stocheaza pur si simplu niste data "chioare". Am inceput sa am primele dubii privind ZODB-ul odata cu prima "POSKey Error". Asta e o eroare care se datoreaza unor date corupte, si care in mod normal nu ar trebui sa apara, conform unuia din principalii developeri din spatele ZODB, dar asta nu e de nici un ajutor cand clientul tipa ca vrea sa scape de ea. Cum gasesti acele date corupte si cum rezolvi problema lor e treaba ta, dar pana faci asta s-ar putea sa ai norocul ca nici o cautare in ZMI sa nu-ti mearga. Alta problema legata de ZODB e ca pentru un numar relativ modest de intrari (sub 100.000, sa zicem), s-ar putea sa ai bafta sa ai un numar de conflicte anormal de mare. Solutia? "Upgrade to the latest ZODB version". Ce se intampla cand ai 1.000.000 de intrari in ZODB si cat de repede mai merge atunci "jucaria" ramane ca tema pentru cititor :) Pe cand toate RDBMS-urile (cel putin cele care se respecta) se descurca confortabil atunci cand au 1.000.000 de intrari (desigur, daca baza de date nu a fost proiectata cu picioarele). Alt punct in minus pentru ZODB este ca poti avea acces la date doar programatic, prin intermediul scripturilor Python, pe cand in cazul unei baze de date MySQL ce sta in spatele unei instante Django pot inspecta si chiar modifica datele cu un produs ca phpMyAdmin, de exemplu, ce nu are nici o legatura cu Django. Asta numesc eu "loose coupling".
E deja tarziu:) o sa revin cat de curand cu alte impresii despre Django.
Pentru inceput iata cateva lucruri care imi plac la Django:
- Fisierele de configurare sunt in Python. Un mare plus. Spun asta ca unul care de o luna - o luna jumate ma lupt cu editarea fisierelor de configurare in format XML. Postul asta, pe nume "Python is not Java", ar trebui sa fie un must-read pentru oricine se intampla "sa ia decizii" intr-un shop Python. Din pacate nu se intampla asa, dar asta deja e alta problema. Celor carcotasi ca mine cand vine vorba de fisiere XML de configuare li se spune "get a good editor, that can trigger the red alarm if your XML file is broken". Intrebarea e "ce e rau cu bietul meu editor Python, ce nu intelege XML?".
- Pana nu demult credeam ca ZODB-ul "batea la fund" RDBMS-urile PostgreSQL sau MySQL. Nu atat din punct de vedere al performantei, cat din punct de vedere conceptual. Imi zaceam ca e mult mai misto ideea de a stoca obiecte ce pot avea atasate atribute, metode etc. Pe cand in MySQL de exemplu se stocheaza pur si simplu niste data "chioare". Am inceput sa am primele dubii privind ZODB-ul odata cu prima "POSKey Error". Asta e o eroare care se datoreaza unor date corupte, si care in mod normal nu ar trebui sa apara, conform unuia din principalii developeri din spatele ZODB, dar asta nu e de nici un ajutor cand clientul tipa ca vrea sa scape de ea. Cum gasesti acele date corupte si cum rezolvi problema lor e treaba ta, dar pana faci asta s-ar putea sa ai norocul ca nici o cautare in ZMI sa nu-ti mearga. Alta problema legata de ZODB e ca pentru un numar relativ modest de intrari (sub 100.000, sa zicem), s-ar putea sa ai bafta sa ai un numar de conflicte anormal de mare. Solutia? "Upgrade to the latest ZODB version". Ce se intampla cand ai 1.000.000 de intrari in ZODB si cat de repede mai merge atunci "jucaria" ramane ca tema pentru cititor :) Pe cand toate RDBMS-urile (cel putin cele care se respecta) se descurca confortabil atunci cand au 1.000.000 de intrari (desigur, daca baza de date nu a fost proiectata cu picioarele). Alt punct in minus pentru ZODB este ca poti avea acces la date doar programatic, prin intermediul scripturilor Python, pe cand in cazul unei baze de date MySQL ce sta in spatele unei instante Django pot inspecta si chiar modifica datele cu un produs ca phpMyAdmin, de exemplu, ce nu are nici o legatura cu Django. Asta numesc eu "loose coupling".
E deja tarziu:) o sa revin cat de curand cu alte impresii despre Django.
posted by mihai turcu at 11:36 PM
7 Comments:
easy give up :P
Ce mi se pare aiurea la Django este template engine-ul.
E chiar lame.
Citeam acu' ceva vreme pe lista de la Turbogears despre TG vs Django şi băieţii de la TG chiar aveau dreptate. (vezi IF "tag")
Ce imi place la Django e faza cu url mapping direct pe funcţii.
Faza cu ORM iară e puţin deplasată (de ce să faci o chestie nouă când există deja SQLObject sau SQLAlchemy).
Iţi urez succes.
Nici eu nu am fost prea multumit la inceput cu template-urile Django. Mi se pareau intr-un fel "handicapate", mai ales venind dinspre Zope in ale carui zpt-uri poti sa faci o multime de chestii. M-am mai obisnuit intre timp, parte pentru ca ce vedeam ca ar trebui sa stea in template ar fi trebuit sa stea de fapt in "view function-ul" scris in Python, parte pentru am inceput sa imi dau seama cum imi pot defini "custom tags and filters".
Din cate am inteles, chiar daca a fost oficial lansat doar vara trecuta, Django era folosit in productie cam de vreo doi ani, deci inaintea lansarii SQLObject, din cate stiu. De aceea nu cred neaparat ca au ales sa scrie un ORM pentru ca ar fi suferit de sindromul NIH, ci pentru ca la ora aceea ce era pe piata nu le satisfacea "nevoile".
Da, si sunt de acord ca "the IF tag kinda' of sucks", ca sa zic asha :)
Tot încerc să mă apuc de un proiect web, only in Python.
Am oscilat între Djang şi TG pentru un proiect recent.
Am ales: PHP :))
De ce ?
Păi doar eu din echipă ştiam Python şi era şi o chestie de timp (deadline).
So far ce am online şi e running, merge pe twisted with custom template engine (small bubu), not too much DB and co.
Mă tentează ceva de genu:
- mod_python
- sqlobject
- airspeed template engine
Ce lipseşte:
- framework pt validare de formular (formkit ?)
O altă chestie interesantă ar fi Plone pentru CMS (nu ca framework). V-aţi jucat ?
Am observat de exemplu că Green Pixel a început să producă site-uri bazate pe Plone cu toate că au Avandor CMS.
Şi băieţii de la Kondiment, cu toate că au CMS pe Java (KSP parcă) au făcut dacia.ro pe Plone.
Singura chesie naşpa la Python WEB programming e că sunt prea multe variante, dar nici una un e 100% completă.
Ne auzim.
"Am observat de exemplu că Green Pixel a început să producă site-uri bazate pe Plone cu toate că au Avandor CMS."
Catalin,
permite-mi sa te contrazic.
1).manual XML generating and writing is like making a horse dance: it's immoral.
2). orice ar fi, am devenit convis untilizator de Django. e primul meu pas spre Python care mi se pare extraordinar.
am legat Django la postresql si performantele sunt bune. acum ma joc putin cu GAE, sper sa gasesc ceva revolutionar.
ce are Django si nu are PHP is scalibility, modularity. Putini inteleg cu adevarat ce inseamna asta.
catalin: plone si zope sunt foarte slabe. merge extrem de incet.
Cred ca python si django merita atentia necesara !
http://groups.google.ro/group/django-romania
Post a Comment
<< Home