Miért pont Django?
Horák György egy djangos prezentációt állít össze első sorban kezdő fejlesztőknek. Megkeresett azzal, hogy fussam azt át, és az észrevételeimet küldjem meg neki. Az e-mail megkeresésre poszttal válaszolok annak reményében, hogy értékes meglátásaitokkal ti is segítitek az anyag kidolgozását.
György – interpretációmban – azokat a webfejlesztőket kívánja megszólítani, akik főleg PHP-vel dolgoznak, kipróbáltak és talán használtak is már PHP keretrendszert, de módszeresen nem használnak egyet sem. De vajon miért nem? Nem kell, hogy tárgya legyen egy Djangot bemutató előadásnak, hogy meggyőzze a hallgatóságot, hogy érdemes keretrendszert használnia, viszont definició szerint annak igen, hogy a Djangot használja. Bizalmat kell kialakítani, az esetleges félelmeket és tévhiteket meg kell cáfolni. Tisztázzuk, mit ad egy keretrendszer. Pontosítok: mit nyújt a Django? És ha már egyáltalán (olcsón poén): miért pont Django? (A témában érdeklődőknek javaslom még Pásztor János Miért tetszik a Django? c. értekezését és az arra érkezett reflexiómat.)
Alapkiszerelésben tud (sorrendre való tekintet nélkül, címszavakban): űrlap kezelés, gyorstárazás, felhasználó kezelés, munkamenet kezelés, jogosultság kezelés, ORM, URL diszpécser, CSRF kivédés, RSS generálás, többnyelvűség, egységteszt keretrendszer, halom utility függvény (amelyek nem Django-s projektben is használhatók), illetve („batteries included”) adminisztrációs felület, egységes üzenet rendszer, hozzászólások, oldaltérkép, bla-bla.
György a vázlatában kiemeli az MVC szemléletet. (Anno én is kiemeltem, és Szilveszter is hivatkozik rá.) Mindazonáltal mai fejjel és a megszólított közönség ismeretében úgy gondolom, szerintem ez nem fontos. Nem fontos annyira, amennyire hangsúlyozott. (Pláne, hogy weben nehezen értelmezhető a hagyományos MVC, ahogy a Django is inkább MTV-nek nevezi ezt.) Kezdők felé úgy fogalmaznám, hogy a Django korszerű objektum orientált tervezési minták mentén felépített keretrendszer, amely megköveteli, de egyúttal bevezeti és segíti is a fejlesztőt ezen minták használatában.
Ebből a szempontból György a django.hu-n publikált háromrészes Django bevezetője például kiváltképp értékes. Míg a hivatalos és nagyszerű tutorial egyből – az általam kezdőknek gondoltak számára témaidegen – modellekkel bíbelődik, addig György a „megszokott” módon hello world-ot printel a képernyőre Django köntösben. Felépít egy egyszerű, érthető, PHP-ból érkezők számára ismerősnek ható logikájú alkalmazást, majd a cikksorozat záró fejezetében bevezeti a modelleket, és megmutatja, hogy lehet azok használatával szintet lépni. Hogy jobb legyen a kódunk. Hogy jobb programozók legyünk. Hogy ma is tanuljunk valamit. (A Django fennhangon artikulált contrib.admin komponense is akkor nyer igazán értelmet, ha a modellek szerepe és célja tisztázott.)
python manage.py runserver, WSGI? PHP-s szárnybontogató fejlesztőknek talán érdekesség, hogy nincs index.py. Olyanannyira, hogy a böngészőben a http://localhost/index.py nem értelmezhető. A mod_php nyújotta kényelem és a jobbára .htaccess-es Rewrite szabályokon alapulú URL feldoldás gyakorlata számos problémát elfed, amivel más rendszerek irányába kacsintáskor szembesül a fejlesztő. A kezdő lökést a djangos „XAMMP”-ok megadhatják: Instant Django, Bitnami DjangoStack.
Végül – és a listát nyitva hagyva a számotokra – amúgy NewTech meetuposan: és mi mindebben az üzleti modell? Lesz állásod.
■
Koszi
Mindenesetre koszi, es hozzaszolasokban is szivesen latom, hogy ki milyen temarol szeretne djangoval kapcsolatban hallani - ha nem is egy ilyen attekinto jellegu eloadas kapcsan, hanem kesobb, vagy pl. cikk formajaban.
Én Symfony keretrendszert
Amit kifelejtettél (azt hiszem) a Djangoval kapcsolatban az az, ami a Symfonyban (pl. a Yii-ben is, de szerintem ott nem átgondolt és nem ennyire szép) is megvan: az ún. "admin generátor", vagyis CRUD felületek automatikus és konfigurálható létrehozása az ORM alapján, ezt a Django is tudja (nem is akárhogyan), és ez szerintem nagyon költséghatékony, mert időt és hibakeresést, vagyis pénzt spórol.
Én így látom.
A Python és a Django keretrendszer nekem szórakozásnak, kikapcsolódásnak indult és nagyon megszerettem, mindenkinek csak ajánlani tudom, de ahogy látom, nem kell ajánlgatni :), mert egyre népszerűbb és talán rövid időn belül meg fogja szorongatni a PHP-t, illetve a PHP-s keretrendszereket, ha szabad ilyen meggondolatlan jóslással élnem.
+ úgy hiszem, hogy a kezdő fejlesztőknek nem árt ha PHP mellett Pythont is tanulgatnak. Nem írom le, hogy miért, mindenki gondolja hozzá a miérteket :)
Köszi
Dive Into Python
Hát ez maga az álom
És minden objektum. Engem
Engem éppen ez zavar össze: ha minden objektum, akkor miért nem minden tulajdonságukat metódusokkal érjük el? Például:
Ezt a kérdést már mások is
És Guido is megválaszolta a kérdést: Why does Python use methods for some functionality (e.g. list.index()) but functions for other (e.g. len(list))?
Zanzásítva a döntés oka, hogy a
len()
-t a Python az összeadás operátorohoz hasonló, egyszerű műveletnek tekinti. Hogy miként értelmezhető két objektum összege, az objektum__add__()
metódusa adja meg, miképp a hosszát pedig a__len__()
-nel lehet definiálni.Én nem tartom bajnak, hogy nem a javában megszokott vonalat viszi minden nyelv.
Én nem tartom bajnak, hogy
Csakhogy jobban szeretem az intuitív dolgokat. (Például az olyant sem díjazom, hogy PHP-ben a karakterlánc kezelő függvények egy része str, más része str_ előtagot kapott, vagy hogy a karakterláncban kereső függvények paraméterei $haystack, $needle sorrendben vannak, a tömbben kereső függvények paraméterei meg fordítva.)
Köszönöm a magyarázatot és az ajánlott házi olvasmányt.
Metódusok
Használhatom az objektumok speciális függvényét:
O'Reilly Head First