Jarosław Zabiełło - BLOG: Django ograniczeniem w rozwoju?

Django ograniczeniem w rozwoju?

Jarosław Zabiełło — Sat, 27 Oct 2007 16:31:00 +0200

Django do dobry i szybki framework do większości zastosowań. Jednakże ci, którzy chcą za jego pomocą stworzyć stworzyć większy projekt, mogę mieć później problemy z dalszym jego rozwojem…

Jednym z większych polskich projektów stworzonych w Django jest serwis społecznościowy grono.net. Niedawno w jednym z blogów ukazał się wywiad z dyrektorem działu IT tego serwisu – Albertem Szybińskim. Grono.net pierwotnie używało Javy, lecz to się nie sprawdziło. Java został zastąpiona pythonowym frameworkiem Django. Początkowo wszystko było dobrze, ale serwis się rozrastał i…

“Doszliśmy już do takiego poziomu, w którym Django zaczął być dla nas problemem. W czasie tworzenia portalu był to bardzo dobry framework, ale przy obecnym stopniu zaawansowania, Django stał się dla nas ograniczeniem w rozwoju i sami musimy go modyfikować.”

Czyli potwierdziło się to co pisałem wcześniej o Django. To system zbyt monolityczny i zdecydowanie za mało elastyczny. Django ciągnie za sobą dziedzictwo CMS Elington z jakiego wyrósł. Może dobrze sprawdza się w projektach typu “wertykalny portal dla wydawnictwa”, ale jak już chcemy coś nietypowego, zaczynają się problemy.

Na pytanie “Czy posiadając taką wiedzę jaką macie dziś, czy zdecydowalibyście się na zaimplementowanie Grono.net ponowie wykorzystując Django, czy może coś innego?” padło wskazanie na Pylons. Może nie ma tak ładnie zgrupowanych modułów w jednym miejscu jak Django, ale na pewno ma większy potencjał do tworzenia nietypowych czy skomplikowanych serwisów.

To nie Django jest prawdziwą pythonową konkurencją dla popularnego Ruby on Rails (że nie wspomnę frameworki pehapowe). Moim zdaniem, bardziej groźną dla nich konkurencją jest Pylons.

"Django ograniczeniem w rozwoju?" by michuk

Fri, 21 Mar 2008 16:42:39 +0100

@Jarosław Zabiełło: Sun wziął się niedawno za Jythona: http://osnews.pl/sun-zatrudnia-specjalistow-od-pythona/ i django ma działać w JVM (tutaj co już działa: http://osnews.pl/powrot-jythona/ )

"Django ograniczeniem w rozwoju?" by mort

Tue, 18 Mar 2008 12:18:01 +0100

OK, faktycznie widziam tu strasznie na RoR’a, ale krótko mówiąc według mnie ruby jest po prostu mniej naturalny czy też intuicyjny od python’a. Zwyczajnie sadząc po opiniach wielu moich kolegów(programistów i adminów) w pythonie sie po prostu pisze, podczas gdy ruby daje wrażenie obcości.

"Django ograniczeniem w rozwoju?" by Jarosław Zabiełło

Thu, 13 Mar 2008 03:38:40 +0100

Generatory kodu w Rails (czy Merb) są bardzo dobre. Wystarczy wiedzieć po co one są.

Konwencje Rails są też bardzo dobre (i jest już sporo innych projektów które to zaczęły naśladować) Nie wiem o jaką niespójność ci chodzi, bo nie podajesz konkretów.

Pythonowa zasada jednej drogi jest dobra, ale nijak ma się do podanych zagadnień w Rails gdzie stosowana jest analogiczna zasada DRY: nie potwarzaj się. (Gdybyś też chciał w Django użyć mocniejszego ORM’a – SQLAlchemy – to wtedy cała zasada pythonowej jednej drogi też bierze w łeb, bo tam istnieje wiele, mętnych dróg do tego samego celu.) Railsy prowadzą cię dosłownie za rękę w tworzeniu kodu.

Netbeans 6 (a ostatnio odrodzony RadRails 1.0) to dobre IDE. Wiadomo że mają większe wymagania niż vi, ale za to dostajesz świetną analizę kodu Rubiego, refactoring i graficzny, krokowy debugger do Railsów.

Deployment w Rails (pewnie chodzi o Capistrano) to nie zasługa Railsów ale Rubiego. Capistrano działa z dowolną technologią. Możesz tego użyć nawet do Django czy PHP.

Unit testy to przestarzała metodologia testująca bardziej strukturę kodu, a nie zachowanie aplikacji. BDD jest na pewno lepsze i pewnie da się znaleźć jakieś biblioteki do Pythona. Choć pewnie takiego wypasu jaki daje RSpec Stories nie będzie. Zobacz ten filmik o BDD vs TDD http://www.youtube.com/watch?v=oOFfHzrIDPk

Django korzysta z Pythona, który ma dojrzalsze biblioteki od Rubiego, fakt. Ale Rails ma dużo mocniejszego asa w kieszeni. Działa z JRuby i daje dostęp do jeszcze potężniejszych i dojrzalszych bibliotek w Javie. JRuby 1.1.RC2 jest już bardzo szybki (szybszy w wielu testach od Pythona) mimo że to nie jest koniec jego optymalizacji. Przyszłośc Rubiego i Rails pewnie wytyczy jednak wzorujący się na wirtualnej maszynie Smallalka – Rubinius.

Railsy mają doskonałą dokumentację, o niebo lepszą od tej do Django, czy nawet calego Pythona. Mam na myśli całą listę świetnych książek (“Agile Web Development in Rails” (wkrótce wyjdzie po polsku, zdobyła nagrodę jako najlepsza książka techniczna roku 2006)”, jest doskonała “The Rails Way”, “Ruby for Rails”, “Rails Recipes” (ta jest po polsku), “Advanced Rails Recipes” i masa innych, z “JRuby on Rails” włącznie). Tylko pozazdrościć i życzyć Pythonowi takich pozycji.

Nie wiem o co ci chodzi na końcu z tym brakiem konkretu czy backendami. Rails śmiga na Rack (odpowiednik WSGI) i używa asynchronicznego podejścia (EventMachine). Zalecanym adapterem jest asynchroniczny i lekki Thin lub bardzo szybki (napisanym w C) Ebb.

And last but not least, jeśli Rails z różnych względów ci nie pasuje, jest jeszcze konkurencyjny – Merb. Jest dużo szybszy i (to moja opinia) jeszcze lepiej zaprojektowany i zaimplementowany niż Rails (z którego oczywiście bardzo dużo zapożycza, więc przejście jest dosyć łatwe). Tworzony jest przez zawodowych programistów na pełnym etacie.

"Django ograniczeniem w rozwoju?" by mort

Wed, 12 Mar 2008 23:26:45 +0100

Generalnie nie zgodze się, że railsy sąlepsze ze wzgledu na poziom generacji kodu. IMHO railsy dają zbyt duży poziom automatyzacji co powoduje wrażenie(może mylne), że brak nam tak naprawde kontroli nad tym co się dzieje. Po drugie w railsach w moim odczuciu brak ujednoliconej konwencji, co znowu odziedziczyly po ruby. Pythonowa zasada, że porządnie pewne rzeczy da się tylko zrobić w jeden sposób jest prawidłowa w moim mniemaniu, zbyt dużo możliwości rozwiązania prostego taska genruje duże rozbieżności na poziomie projektu i w efekcie duże problem z jego rozumieniem. Argument jakoby Netbeansy byly spoko IDE mnie nie przekona, bo z założenia netbeansy i pokrewnego mu eclipsa uważam za błędne na poziomie przyjetych założeń(są dobre ale za cene szybkości, gdyby były bardziej optymalne, nie doskwierało by to aż tak). Faktycznie zgodze się ze URL resolver django mógłby być lepszy. Jesli chodzi o deployment, racja, railsy mają się tu czym chwalić, ale jak dla mnie django ma tu swoje racje, jak framework do robienia logiki aplikacji nie całych aplikacji. Jesli chodzi o testy zgodze się, ale nawykowo używam nosetest’ow pythonowych, i IMHO się sprawdzają. Generalnie jak dla mnie zaletą django jest dziedziczenie cech środowiska python’owego, to jest dojrzałego i konkretnego podejścia oraz dobrej developerskiej dokumentacji. Railsy robią dużo szumu i mają ładne tutoriale, ale w pewnym momencie woli sie doc’a, a w rails’ach brak dobrej dokumentacji, i to boli. Wreszcie django pięknie integruje się z całym pythonowym backendem w formie twisted, nosetestow, i całej reszty tego “badziewia”. Tu znowu duży kop w rails. Podsumowywujac, railsy-django 1,5:2. Railsy bylyby super, ale brak za bardzo zatracily konkret na rzecz eye-candy

"Django ograniczeniem w rozwoju?" by Jarosław Zabiełło

Fri, 29 Feb 2008 12:45:19 +0100

Nie twierdzę że jest bez sensu. Ma swoje zalety jak i wady. Elastyczność na pewno nie jest jego zaletą.

"Django ograniczeniem w rozwoju?" by Szymon

Fri, 29 Feb 2008 12:06:17 +0100

Czy w takim razie dalej obstajesz przy tym że django jest raczej bez sensu i powinno się raczej iść w stronę pylonsa?

"Django ograniczeniem w rozwoju?" by Jarosław Zabiełło

Fri, 22 Feb 2008 17:38:18 +0100

Co do startup w Pylons to się zgodzę. Mogłoby to być prostsze.

Co do resolvera URL w Django to się już nie zgodzę. Jest słabszy niż to, co oferuje pythonowy, używany przez Pylons, moduł Routes (podobne mapper jest w Rails i Merb). Czy Django ma jakiekolwiek wsparcie dla REST?

Jeśli chodzi o szybkość tworzenia kodu to też się nie zgodzę. W Rails jest tu duża przewaga dzięki liczniejszym generatorom/destruktorom, konwencjom, migracjom, taskach Rake i Capistrano dla deployingu.

Django może być pozornie szybszy w developingu gdy korzystasz z pewnych gotowych modułów w jakie jest wyposażony (np. i18n czy panel edytorski). Ale z kolei Rails ma to w mgnieniu oka osiągnięte za pomocą Globalize, Lipsiadmin czy ActiveScaffold. Więc w sumie nie ma dobrych argumentów na poparcie tezy że w Django pracuje się szybciej niż w Rails “dopalonym” paroma pluginami.

Rails też ma świetne IDE – Netbeans 6 z zintegrowanymi generatorami kodu, refactoringiem, świetnymi podpowiedziami i bardzo dobrym graficznym debuggerem. Myślisz że to nie przyśpiesza pracę? Oj przyśpiesza. :)

Także testowanie w Rails (i Merb) jest dużo bardziej rozbudowane i w sumie lepsze niż w Django, bo używana jest nowsza metodologia BDD zamiast starego podejścia TDD (vide RSpec Stories, pokrycie kodu automatycznie kontrolowane przez RCov, itp.)

"Django ograniczeniem w rozwoju?" by mort

Fri, 22 Feb 2008 16:15:13 +0100

Dodam swoje trzy grosze. IMHO django ma sensowne podejscie do AJAX, bo jest frameworkiem w moim odczuciu server-side, wiec wymaganie od niego jakichs js konotacji jest bledne. Ponadto sensowne w moim odczuciu jest podejscie programistow django do ORM i URLi. Jesli ktos chce miec na szybko aplikacje, powiedzmy demo wiekszej, blog, normalna strone, dostaje dobrze zintegrowane i udokumentowane rozwiazania w pakiecie. Jesli chce cos zmieniac, modyfikowac, poprawiac, moze niewielkim nakladem sił to zrobic. Wogole patrzac na django odnosze wrazenie o jego duzej modulowosci. Django ma mnostwo zalet o ktorych zdaja sie zapominac hardcore’owi koderzy. Dokumentacja, bateries-included, szybkosc dzialania i szybkosc developmentu. Ponadto za kazdym razem gdy mialem wrazenie ze django mnie ogranicza okazywalo sie ze probuje cos zrobic w sposob nieefektywny/bledny/dziwny. Railsy wedlug mnie sa przekombinowane, daja za duzo mozliwosci na zrobienie najprostszych rzeczy, zmuszaja do nadmiernego myslenia w niewlasciwych momentach. Pylonsy sa za to za bardzo hard-coder-friendly. Najprostszy start-up ciagnie za soba duzo pracy, a generalnie nie to jest celem frameworka

"Django ograniczeniem w rozwoju?" by lukasz@anwajler.com

Sat, 03 Nov 2007 22:34:34 +0100

Kubiku: to co opisałeś, sprawiło właśnie, że zainteresowałem się Django. Nie znałem wtedy Pylons, ale moja znajomość Pythona nie była wtedy zbyt dobra, więc bym się tylko do niego zraził. Django zapewniło całkiem niezłą dokumentację, grupa django-users wyjaśniła resztę wątpliwości i można było bardzo szybko zacząć kodzić, nawet nie mając wcześniej doświadczenia z Pythonem.

Podobnie jak Ty uważam, że to właśnie Django “przejmie” programistów, uciekających, tak jak ja, od PHP.

Tylko czy Django to jest już to? Czy następny etap to Pylons właśnie?:)

Się okaże.

"Django ograniczeniem w rozwoju?" by kubiku

Sat, 03 Nov 2007 20:53:34 +0100

Starcie Django vs. Pylions wg mnie przypomina trochę sytuację sprzed kilku lat z MySQL i PostreSQL.

Mamy “na rynku” dwa rozwiązania: 1. zaawansowane technicznie, “powerfulne”, elastyczne, rozbudowane i wydajne (PostreSQL, Pylons) 2. prostsze, wygodne prosto z pudełka, zapewniające całkiem niezłą funkcjonalnosć i wydajność (MySQL, Django)

Kilka miesięcy temu, kierując się w dużej mierze tym blogiem, zajrzałem na stronę Pylons z zamiarem jego użycia. Może cechowała mnie zbyt mała wytrwałość, jednak odbiłem się na samym początku – w sumie do tej pory nie wiem do końca jak to wszystko zainstalować i stworzyć coś większego od bloga.

Tymczasem na stronie Django czekała wyczerpująca dokumentacja dotycząca wszystkich aspektów fraweworka, kilka opisów instalacji i tutoriali. Zostałem przy Django, do wielu zastosowań nadaje się niemal idealnie, czasem trzeba trochę się nagimnastykować. Powinienem dodać, że Pythona dopiero się uczę, więc łatwiej mi było zacząć w środowisku, gdzie wiele rzeczy jest wyjaśnionych i opisanych.

Wg mnie Django może zachęcić do Pythona wielu developerów Javy i PHP. Może później przesiądą się na Pylons, a może rozbudują Django. Taki MySQL ma się wciąż świetnie i to coraz częściej też w klasie enterprise :)

"Django ograniczeniem w rozwoju?" by forgems

Fri, 02 Nov 2007 08:46:57 +0100

Dyskusja ta sprowadza się do wyższości świąt Bożego Narodzenia nad Wielkanocą.

"Django ograniczeniem w rozwoju?" by climbus

Fri, 02 Nov 2007 08:34:18 +0100

Po poście Jarka nie za dużo mam do dodania.

“Ukradli” – ostro z tym przesadziłeś. Twórcy Pylonsa ściśle współpracują z twórcami bibliotek których używają:

Ian Bicking, twórca PythonPaste jest członkiem wspierającym team pylonsa,

Michael Bayer, twórca Mako i developer SQLAlchemy jest developerem Pylonsa

Ben Bangert, twórca pythonowego Routes i WebHelpers jest twórcą Pylonsa.

Jak widzisz do kradzieży tu daleko. Raczej nazwał bym to współpracą. Pylons współpracuje też z TurboGears. Z kim współpracują developerzy Django?

Idąc twoim tokiem myślenia Pythona i jego biblioteki standardowe też powinni napisać od zera. Był by stabilniejszy :)

Pod tym co napisał wcześniej Jarek podpisuję się obiema rękami. Pylons daje gwarancję, że nie napotkam ściany w przyszłości. Mogę robić prawie wszystko bez paczowania frameworka.

"Django ograniczeniem w rozwoju?" by Jarosław Zabiełło

Fri, 02 Nov 2007 02:12:42 +0100

Dominik Szopa: dobrze że prace nad obsługą wielu baz trwają. Na razie kod jest w fazie alpha więc pewnie sporo czasu upłynie zanim uzyska status stabilnego.

Apropos’ wymyślania koła od nowa. Właśnie tu masz przykład takiego postępowania. SQLAlchemy od dawna obsługuje wiele baz. Tym bardziej, że wcześniej mówiono, że Django ma swój ORM zintegrować z SA. Zmienili zdanie czy nadal planują integrację z SA?

climbus niech sam ci odpisze. Ja tylko dodam od siebie, że nie widzę żadnej korzyści nad djangowym kodem w fazie alpha skoro mam znacznie stabilniejszą i dojrzalszą alternatywę w postaci SQLAlchemy. Coś pisane od zera nic nie oznacza odnośnie stabilności poza tym że ktoś znowu chce wymyślać koło. Jakość takiego kodu i tak zależy od poziomu jego twórców. Goście od Pylonsa znają bardzo dobrze Pythona. Nie sądzę, żeby ci od Django byli w czymś lepsi.

Pylons opiera się na dobrych, sprawdzonych bibliotekach a nie na autorskim kodowaniu wszystkiego od zera. I bardzo dobrze. Dzięki temu sam projekt się szybciej rozwija niż Django.

SQLAlchemy to najlepszy ORM jaki istnieje do Pythona. Czy Djangowy ORM potrafi obsłużyć złożone klucze obce?

Routes jest b. dobrą biblioteką, implementuje i dostarcza helpery do REST (Django to potrafi?) Mówiono, że Django miało opcjonalnie dodać Routes zamiast swego resolvera, ale nie wiem czy coś tu zrobiono czy tylko skończyło się na gadaniu.

Używany przez Pylons Mako to najlepszy (i najszybszy) system szablonowy jaki znam. Od początku był oparty na czystych obiektach unikodowych Pythona. Django dopiero niedawno do tego dorosło aby na to przejść. Mako jest też bardzo zgodny z pythonową filozofią pracy (wystarczy zobaczyć sposób pracy modułów, dodawania custom tagów, jako zwykłych bibliotek Pythona). Dużo prościej, i lepiej niż to robi Django. Poza tym Mako ma mocny i elastyczny cache, jest odporny na wątki, ma mocne dziedziczenie i silne, parametryzowane includowanie modułów.

Nie masz w ogóle racji, że jak ktoś coś napisze od zera to niby lepiej zaprojektuje. Nie rozumiesz chyba idei WSGI. Pylons pozwala na złożenie sobie frameworka takiego, jaki ci pasuje. W tym sensie Pylons nie jest tak jak Django frameworkiem, ale megaframeworkiem. WSGI to przyszłość. Jest już dodane do biblioteki standardowej Pythona 2.5. TurboGears też podąża w kierunku WSGI. Nawet w Django chciano też zejść blizej WSGI, ich middleware trochę to naśladuje, ale to wszystko są raczej półśrodki. Pylons jest unikalny nie dlatego, że ma jakieś tam dobre moduły, ale dlatego, że totalnie poszedł w kierunku WSGI.

"Django ograniczeniem w rozwoju?" by Dominik Szopa

Fri, 02 Nov 2007 00:04:16 +0100

Hmmm… z tego co widze to support dla multi db jest skonczyony (code.djangoproject.com/wiki/MultipleDatabaseSupport), została do zrobienia tylko dokumentacja, pewnie nie długo wyląduje w trunku.

Do climbus: tak nie pisali od nowa, tylko “ukradli” wszystko od innych. Czy jeżeli coś zostało napisane od zera, nie oznacza to większej stabilności oraz kontroli dla projektu??? niż jeżeli wszystko to tak naprawdę jedna wielka sklejka tooli, bibliotek itd??? Właśnie dla tego to że wszytko było pisane od zero oznacza lepsze przemyślenie całości(projektowanie oprogramowania sie kłania :-) )

"Django ograniczeniem w rozwoju?" by Jarosław Zabiełło

Thu, 01 Nov 2007 22:28:13 +0100

forgems: z tą obsługą formularzy to bym się nie podniecał. Django obsługuje dobrze raczej trywialne formularze. Ich mechanizm jest bezużyteczny w wypadku czegoś bardziej skomplikowanego, gdyż wtedy trzeba klepać w czystym HTML albo definiować swoją obsługę dla inaczej zachowujących się pól formularza. Jak do tego dojdą interakcje między polami w JS lub AJAX to jest jeszcze gorzej, bo Django nie ma tu nic dodatkowego do zaoferowania. Pylons i Rails lepiej nadają się do budowania bardziej nietypowych, skomplikowanych formularzy. Co do generic views to nigdy nie znalazlem w nich nic atrakcyjnego. Mają za mało dynamizmu, łamią przejrzystość przepływu sterowania modelu MVC i są za banalne, aby na nich zbudować coś bardziej skomplikowanego.

"Django ograniczeniem w rozwoju?" by forgems

Thu, 01 Nov 2007 20:56:17 +0100

To jest blog Jarka i chyba czas zakonczyc ta dyskusje.

"Django ograniczeniem w rozwoju?" by forgems

Thu, 01 Nov 2007 20:53:04 +0100

>>Nie mogę ingerować w bazę danych, dodając jakieś tabele potrzebne tylko do www. Po przejściu na SQLAlchemy mogę wpasować się w każdą strukturę.

A kto ci zabrania ?

>>Oj chyba się mylisz. To Django ma ciągotki do wynalezienia koła od nowa. Ludzie od Pylons nie pisali wszystkiego od nowa. Używali gotowych, sprawdzonych bibliotek.

Tu nie chodzi o wewnetrzna organizacje projektu, ale np obsługę formularzy, generic views itp. Te sprawy django ma przemyslane i dobrze zoorganizowane, nie musze szukac bibliotek ktore mi to ulatwia ani pisac wlasnych narzedzi poniewaz w django juz je mam, a podejscie tworcow jest bardzo pragmatyczne i zdrowo rozsadkowe.

"Django ograniczeniem w rozwoju?" by climbus

Thu, 01 Nov 2007 17:45:15 +0100

Oj chyba się mylisz. To Django ma ciągotki do wynalezienia koła od nowa. Ludzie od Pylons nie pisali wszystkiego od nowa. Używali gotowych, sprawdzonych bibliotek.

I chyba nie “wpasować” a “dopasować”. Deweloper musi się dopasować do frameworka.

Jak czytam ten wątek to upewniam się w swoim przekonaniu, że i tak wszystko kończy się na zmienianiu źródeł Django. Pylonsa mogę dopasować do swoich i mojej firmy potrzeb bez ingerencji w jego źródła.

M. in. dlatego wybrałem Pylons.

Nie mogę ingerować w bazę danych, dodając jakieś tabele potrzebne tylko do www. Po przejściu na SQLAlchemy mogę wpasować się w każdą strukturę.

"Django ograniczeniem w rozwoju?" by forgems

Thu, 01 Nov 2007 12:22:22 +0100

>>Znacznie lepiej odizolować to od siebie za pomocą parametrów formalnych.

Dalej nie widze problemu, to jest kwestia jak jest stworzona funkcja parsujaca dane do template taga. Odpowiednio stworzona funkcja może generować słownik **kwargs-ów i być stosowana wszędzie. Można napisać odpowiednią funkcje. Django nie stawia w tej kwestii żadnych ograniczeń, to raczej kwestia preferencji programisty.

>>Oczywiście, że tak. Zarówno SQLAlchemy jak i SQLObject to potrafią.

Taaa, a konfiguracja tego jest bardzo prosta. Równie prosta co w django, bo jeśli zechce to mogę podpiąć te ORM-y do django, praktycznie w identyczny sposób jak w pylonsach.

Pylons jest po prostu odpowiednikiem railsów dla pythona przy czym większy nacisk stawia na DIY niż szybki start projektu.

W gronie problem polega na tym że przy przechodzeniu z javy na django nie doszło do migracji bazy na taką jaka by sprzyjała django. Dlatego nie możemy wykorzystać świetnego django.contrib.auth, django.contrib.comments, django.contrib.contenttypes, przez nasza aplikacja korzysta już w tej chwili tylko z mapper-a urli i templatów.

Spójrzmy na pownce, które praktycznie w całości zostało stworzone za pomocą generic views i aplikacji dostępnyc w django.contrib.

Różnica między django a pylons to kwestia podejścia do sprawy developera. Czy woli dobrze poznać dany framework i wpasować się w niego ( django ), czy też woli pisać wszystko od podstaw bo wie lepiej co jest mu potrzebne ( przy czym w większości przypadków dokonuje wynalezienia koła od nowa )

"Django ograniczeniem w rozwoju?" by rsz

Thu, 01 Nov 2007 11:19:59 +0100

Tak na szybko tylko odpowiem: system generowania URLi w django jest bardzo rozbudowany i elastyczny. Ma reversowanie, wbrew temu, co piszesz, a z naszymi (sensisoftowymi) poprawkami z ostatnich paru tygodni to w ogóle wypas :)

"Django ograniczeniem w rozwoju?" by Dominik Szopa

Wed, 31 Oct 2007 23:54:31 +0100

Jarek: >>Unikanie helperów do Ajaksa bo niby
>>“Django nie chce wskazywać na jakiś
>>jeden framework” to chyba jakiś nonsens.
>>To jest ich oficjalne stanowisko czy sam
>>to wymyśliłeś?

Tak to ich oficjalne stanowisko, na stronie można znaleźć wywiad z lead developerem – Jacob’em Kaplan-Moss’em. Jest tam takie zdanie:

“PythonThreads >> Frameworks like ROR make it easy to add simple AJAX functionality to web applications. Any plans of adding similar support in near future? Jacob Kaplan-Moss >> This question comes up often, and I’m never really sure how to handle it. Part of the problem is that I don’t think anybody really can define what “supporting AJAX” really means. If it just means allowing JavaScript callbacks, Django’s already really good at that. The serialization libraries let you convert database objects to JSON, XML, or YAML in just a couple of lines of code.

However, if “AJAX support” means bundling a JavaScript library, that’s never gonna happen. We’re Python programmers—why should you trust our choices when it comes to JavaScript? If you added special support for (say) Dojo, we’d effectively be tying our users’ hands. Lock-in sucks in closed-source software, and it still sucks in open-source.”

Podsumowując: Django posiada narzędzia do serializacji, które pozwalają na konwersje obiektów z bazy do JSON’a. XML’a lub YAML’a, ale nigdy nie będzie specjalnej obsługi konkretnego framework’a Ajax’owego

"Django ograniczeniem w rozwoju?" by Jarosław Zabiełło

Wed, 31 Oct 2007 22:38:23 +0100

forgems: Nie przekonuje mnie to zupełnie. Uzależnienie wewnętrznej implementacji template taga od nazwy zmiennej w szablonie w kontekście jakiego ma się pojawić jest po prostu błędem projektowym. Znacznie lepiej odizolować to od siebie za pomocą parametrów formalnych. Można w ten sposób tworzyć sobie biblioteki tagów, nie martwiąc się o to, gdzie mogą być wykorzystane. Czy Pylons wspiera wiele baz? Oczywiście, że tak. Zarówno SQLAlchemy jak i SQLObject to potrafią.

"Django ograniczeniem w rozwoju?" by Jarosław Zabiełło

Wed, 31 Oct 2007 22:36:27 +0100

Dominik, ten argument o konieczności dbania o zewnętrzną bibliotekę brzmi niewiarygodnie. Przecież chłopcy-djangowcy usiłują od jakiegoś czasu zintegrować swój ORM z zewnętrznym , poteżniejszym SQLAlchemy. Wcześniej mówiono też coś o dodaniu Routes, bo każdy wie że bazujący na wyrażeniach regularnych resolver URLi w Django jest taki sobie (Nie ma wsparcia dla REST ani generowania URL. Jakakolwiek zmiana struktury aplikacji wymaga ręcznej wymiany tysięcy URL usianych w szablonach Django).

Unikanie helperów do Ajaksa bo niby “Django nie chce wskazywać na jakiś jeden framework” to chyba jakiś nonsens. To jest ich oficjalne stanowisko czy sam to wymyśliłeś? Przecież Django z def. wskazuje na konkretne rozwiązania (zresztą zgodnie z Pythonowym ZEN) i tu niby miałoby robić wyjątek? Nie wierzę. Tym bardziej, że dobrze pamiętam jak się zastanawiano nie “czy”, ale JAKI framework do Ajaksa wybrać. Zresztą sami w Wiki wskazują na jakieś rozwiązania które jeden, czy drugi internauta wymyślił. Trochę to bez sensu. Tym powinien zająć się core team a nie odsyłać ludzi do jakichś amatorskich rozwiązań. Poza tym, choć helpery to wygodna sprawa, to jak komuś nie pasują, zawsze może pisać w czystym JavaScripcie. W każdym razie Django nie daje takiej opcji.

Zresztą nie chodzi tylko o Ajaksa. Pylons ma bogate webhelpery ułatwiające tworzenie nie tylko JavaScript ale też kodu HTML (w Django musisz na piechotę zapieprzać z kodem HTML) Poza tym helpery nie muszą ograniczać się do jednego Prototype. Pylons reklamuje się że ich WebHelpery są oparte na Mochikit, Prototype, JQuery, Dojo czy Ext. Do wyboru, do koloru.

Odnośnie plusów Django. Generic views nigdy jakoś do mnie nie przemawiały. Nadają się tylko do prostych rzeczy. (Zresztą wkurza mnie nazywanie kontrolerów widokami i zamieszanie z terminologią MVC. Oni to pomieszali, bo po prostu nie wiedziali jak poprawnie to powinno się nazywać. Jeden z developerów Django sam to przyznał na jednym filmie.)

Co do panelu edytorskiego, to jest pożyteczny choć ma dosyć ograniczone zastosowanie. W sumie można by napisać coś takiego. Nawet do Rails coś tam podobnego stworzono. Ale fakt, że Django to już ma, to jego plus. Fakt.

Dokumentacja Django jest niezła. Prawda. Ale moduły jakie używa Pylons też mają dobrą dokumentację. Mako ma bardzo dobrą dokumentację. Nie można się dużo przyczepić do SAAlchemy czy Routes. Więc w sumie wychodzi na to samo. Poza tym do Pylons jest już dosyć dobra dokumentacja. Dużo się zmieniło w przeciągu ostatnich miesięcy. W sumie ja bym tu dawał remis.

Co do tego zlepku bibliotek, to mamy tu do czynienia z inną filozofią. Pylons to czysty framework WSGI i to jest akurat bardzo dobre. Jest niesamowicie elastyczny. I to też jest dobre, bo masz małe szanse że spotkasz się z jakimiś ograniczeniami w przyszłości. Django to jest aplikacja monolityczna, o określonym profilu, zastosowaniu. Ma to swoje zalety, ale też i wady. Zapomniałeś dodać, że ów zlepek bibliotek w Pylons jest zlepkiem bardzo dobrych bibliotek, lepszych od Django. I wcale nie mniej stabilnych. SQLAlchemy jest lepszym ORM niż Django, Routes lepszym resolverem, Mako lepszym systemem komponentowo-szablonowym. Zresztą Pylons pozwala na użycie Jinja które są ulepszonym klonem szablonów Django.

Z tym ograniczaniem co do Ajaksa, już wyżej napisałem. Brzmi to mało przekonująco. Sorry za długi wpis. Możemy przenieść dyskusję na pl.comp.lang.python jeśli jest taka potrzeba.

"Django ograniczeniem w rozwoju?" by Dominik Szopa

Wed, 31 Oct 2007 21:04:40 +0100

Jarosław Zabiełło Może byś tak podał jakieś konkrety n/t tych “dobrze przemyślanych i lepszych” rzeczy w Django?

Prosze bardzo:

* Widoki generyczne
* Automatyczny panel edytorski
* Bardzo dobra dokumentacja
* Nie jest zlepkiem tool'i, bibliotek itd. Co zapewnia większa stabilność
* Nie ogranicza do korzystania z konkretnego wbudowanego framework'a Ajaxowego - dla mnie to zaleta
* O czymś jeszcze zapomniałem???

"Django ograniczeniem w rozwoju?" by Dominik Szopa

Tue, 30 Oct 2007 22:08:12 +0100

A czy ktoś sie kiedyś zastanawiał dlaczego w Djnago nie ma takich helperów “out of box” do Ajaxa??? Kiedyś czytałem że dlatego tego nie chca dać bo to nie było by zgodne z filozofia Django. Musieli by odpowiadać za cudzy kod frameworka Ajaxowego, pozatym ktory wybrac? Jedne sa gorsze drugie lepsze. Uważam że to podjescie jest bardzo dobre, nie zmusza do korzystania z frameworka Ajax’owego XXX. Jest tylko zrobione wsparcie że mogę z Django bez problemu można użyć dowolnego frameworka Ajaxowego, takiego jaki mi sie podoba. Osobiscie do Django używam Prototype’a z script.aculo. Uważam że to dużo lepsze podjescie niż na siłe umieszczac w projekcie jeden konkretny framework Ajaxowy.

Pozdrawiam Dominik Szopa