Web2py
Grzegorz Czekaj
Jestem ciekaw waszych opinii o frameworku pythonowym web2py. Czy jest to
kolejna zabawka znudzonych developerów, czy faktycznie poważne narzędzie ?
Grzegorz Czekaj
Artur Lew
> Jestem ciekaw waszych opinii o frameworku pythonowym web2py. Czy jest to
> kolejna zabawka znudzonych developerów, czy faktycznie poważne narzędzie ?
Licencja:
* Czyzbym widzial GPL2? Fuj...
Core:
* Nie sadze zeby pozwalal na takie bajery na jakie pozwala mi Routes w
Pylonsach...
* Zbudowany na MVC, jak bym mial zaczynac cos nowego to czemu nie
udostepnic uzytkownikowi czegos innego jak np IOC ?
* Duzo bajerow w srodku ale wyglada ze za wszystkim stoi jedna osoba
ktora kiedys polegnie pod naporem ticketow z bugami ;D Co wiecej Autor
twierdzi ze wszystko przychodzi z paczka i nie wymaga zewnetrznych
bibliotek a tutaj czytamy:
"... simplejson developed by Bob Ippolito"
W zwiazku z tym co bedzie w przypadku aktualizacji tej biblioteki ?
Musimy zmienic zrodla web2py a tutaj juz GPL...
Szablony:
Nie rozumiem po co wymyslac kolejny genialny system template'ow z ciut
dla mnie zbyt oryginalna skladnia tj:
{{for i in range(10):}}hello{{pass}}
Ciekawy jestem ile edytorow wspiera kolorowanie takiej skladni (oprocz
TextMate)?
Na rynku jest teraz pare zajebiscie dobrych i sprawdzonych systemow
szablonow jak Mako, Myghty czy Cheetah. Pamietam ile bylo z kazdym z
nich bojow, ile rewizji trzeba byl oczekac na jakies poprawki zwiazane
np z Unicode (Myghty). Kazdy z nich to teraz sprawdzona w bojach
machina. Ten ich system jest nowiutki jak bulki z piekarni i mysle ze
tez musi przejsc przez meke jak w/w frameworki.
ORM:
Ludzie narzekaja ze jest malo dokumentacji do SQLAlchemy (ja znalazlem
na razie paredziesiat MB ;) + ksiazka ktora sie drukuje) ktory teraz
jest obecnie najbardziej rozbudowanym ORMem dla Pythona (i dla Javy tez
;)). A co powiedziec o ich malutkim ORMie ktorego dokumentacja to pare KB?
Formularze bazujace na modelu DB to tani bajer i istnieja juz dosc
rozbudowane systemy (vide new forms w Django)
Interfejs do obslugi DB. Hmm... pgAdmin III juz nie wystarcza?
Lokalizacja:
Zajebiste ulatwienie z lokalizacja poprzez "T" ;) Caly swiat uzywa "_" a
kolesie wymyslaja sobie nowosc - T. Nie wspomne ze nie mam mowy tutaj o
jakis narzedziach do tej lokalizacji jak Babel/po...
Kompletna lokalizacja rozbudowanej aplikacji w Pylons to dwie komendy :)
Deployment.
W porownianiu do Pylonsa/Django nie ma nawet co porownywac. Powstalo
dziesiatki MB informacji jak to ustawic, skonfigurowac pod praktycznie
wszystkimi front-endami jak Apache czy Lighty. Nie wspomne ze np
Pylonsowy serwer zajebiscie dobrze sprawdza sie w dosc rozbudowanych
srodowiskach i nie trzeba kombinowac z FastCGI, etc...
Slowa nie ma takze o migracji aplikacji na nowa wersje co jest np
dostepne w Pylons i chyba Django tez.
Community:
Django czy Pylons moga sie pochwalic dosc liczna trzodka uzytkownikow...
Tutaj caly FAQ miesci mi sie na 19 " po obroceniu ekranu ;)
Cache:
Hmm moze "ram/disk/both" to duzo ;) ale gdzie wygoda z korzystania od
razu z memcached tak jak oferuja to np Pylonsy?
Chociaz wzmianka o "memcache" jest jakas
Plusy:
* WSGI
* Malutki i zgrabniutki. Mysle ze swietne narzedzie do robienia malych i
szybkich prezentacji jak autostarty na CD-ROM ;)
* Jako ze wszystko co potrzebne jest dostarczone od razu (jakze
Pythoniczne podejscie ;)) swietna rzecz do zabawy dla kogos kto nie lubi
czytac dokumentacji albo uzywa MSN-a a nie Google'a ;)
* Walidacja formularzy dzieki czemu poczatkujacy uzytkownik unika
czeskich bledow z escape, wyjatkami po stronie DB, etc...
* Migracja bazy. Hmm az musze zobaczyc bo nie sadze zeby update na
istniejacych tabelach/widokach bylo mozliwe.
* Wbudowane wsparcie do JSON czy RSS
* Dystrybucja aplikacji jako jednej paczki (niby nawet jako exec)
* Tickety, aczkolwiek i tak wole zwykle logi ;)
--
Pozdrawiam
Artur Lew
arturdotlewatgmaildotcom
forgems
> Hmm moze "ram/disk/both" to duzo ;) ale gdzie wygoda z korzystania od
> razu z memcached tak jak oferuja to np Pylonsy?
> Chociaz wzmianka o "memcache" jest jakas
To pylons ma cachowanie ? Z tego co pamiętam to nawet sesji out of the
box nie obsługuje.
Pozdrawiam Marcin Swiderski
climbus
> To pylons ma cachowanie ? Z tego co pamiętam to nawet sesji out of the
> box nie obsługuje.
Marcin, marcin, nieładnie, to źle o tobie świadczy :)
Robisz nowy projekt, w kontrolerze masz zmienną session, która jest
hmmm, chyba sesją i działa.
Aby sesja była w memcache robisz:
session.type = ext:memcached
session.url = host:post
Cache jest też dostępny i to na kilku poziomach: mako, beaker cache,
etag. Najprościej jest użyć dekoratora:
@beaker_cache
def jakas_akcja_w_kontrolerze(self):
pass
Dokumentacja:
http://wiki.pylonshq.com/display/pylonsdocs/Getting+Started#using-sessions
http://wiki.pylonshq.com/display/pylonsdocs/Caching+in+Templates+and+Controllers
Bawi mnie jak się tyle mówi, że Pylons nie ma dokumentacji a tych
kilka podstawowych stron nikt nie przeczyta.
To tak abyś się więcej nie wygłupiał :)
Climbus
forgems
> kilka podstawowych stron nikt nie przeczyta.
>
> To tak abyś się więcej nie wygłupiał :)
No tak, z przyzwyczajenie człowiek szuka działu o sesjach :)
Grzegorz Czekaj
> Licencja:
> * Czyzbym widzial GPL2? Fuj...
Artur a co złego widzisz w GPL2 dla frameworków ?
Piotr Keplicz
>> * Czyzbym widzial GPL2? Fuj...
>
> Artur a co złego widzisz w GPL2 dla frameworków ?
Wszystko napisane z wykorzystaniem takiego frameworka automatycznie podlega
GPL2?
.pk.
Daniel Podlejski
> GPL2?
Nadinterpretacja. Końcówka punktu drugiego GPL2 wyjaśnia kwestię.
--
Daniel Podlejski
Piotr Keplicz
> Nadinterpretacja. Końcówka punktu drugiego GPL2 wyjaśnia kwestię.
Słusznie. Aczkolwiek wyobraziłem sobie sytuację, gdy podstawowy kod programu
(w sensie np. wyniku "paster create app -t pylons") byłby objęty GPL...
.pk.
Artur Lew
> Artur a co złego widzisz w GPL2 dla frameworków ?
Otoz mimo ze framework jest juz doskonaly czasem jednak trzeba nawet na
szybko dodac do niego jakas funkcjonalnosc albo wprowadzic zmiany
specyficzne dla klienta (vide: Grono i Django). I pojawia sie problem.
Bo zmiane naniesc to pikus, gorzej pozniej z udostepnieniem takiej
wersji na GPLu - a tak wg mojej wiedzy nalezy jednak zrobic.
Oczywiscie mowie tutaj o kodzie zrodlowym frameworka bo GPL nie ma nic
do mojego kodu.
Druga kwestia to problematyczne laczenie wielu roznych bibliotek
opartych na roznych licencjach i sygnowanie tego wszystkiego pod szyldem
GPL (np ten web2py jest wlasnie na GPLu a uzywa simplejsona na MIT).
Tak na prawde czesto okazuje sie ze sam autor nie wie za bardzo jakie sa
konsekwencje takiego laczenia ;D
Pamietam jakie byly problemy np w przypadku Ext.JS gdy Jack przeszedl na
LGPL-a. Watki na forum byly dluzsze niz flame Python-Ruby :D
Jak sie mysli o dobrej komercji to jest to sprawa bardzo wazna bo w
ostatniej chwili mozna poplynac na takich pierdulkach :D
Daniel Podlejski
> wersji na GPLu - a tak wg mojej wiedzy nalezy jednak zrobic.
Ale nie masz obowiązku udostępniać tego publicznie, np na jakimś ftp
czy stronie WWW. Wystarczy że udostępnisz te zmiany klientowi dla
którego jest projekt w postaci źródeł - a w przypadku modyfikowania
django czy pylons i tak to zwykle robisz.
--
Daniel Podlejski
Artur Lew
> Ale nie masz obowiązku udostępniać tego publicznie, np na jakimś ftp
> czy stronie WWW. Wystarczy że udostępnisz te zmiany klientowi dla
duzo obiekcji:D
A co w kwesti mieszania licencji ?
Masz jakies doswiadczenie w tej materii ?
Daniel Podlejski
> duzo obiekcji:D
Prawnicy mają zawsze całą masę obiekcji - za to biorą kasę.
Generalnie mam wrażenie, że GPL jest mocno demonizowana, choć nie
jest aż tak straszna jak niektórzy starają się ją przedstawić.
Parę lat temu Zbyszek Okoń trochę się rozpisywał o tym na pcoa.
To co zapamiętałem i tu przekazałem stosuje i jeszcze nikt mnie
nie pozwał ;)
> A co w kwesti mieszania licencji ?
> Masz jakies doswiadczenie w tej materii ?
Z tym to jest rzeczywiście straszny chaos i pewnie można osiwieć
w niektóych przypadkach. Mi na szczęście się taki jeszcze nie trafił.
--
Daniel Podlejski
yarko
"*web2py* jest *GPL2* ale to nie rozprzestrzenia do użytków
rozwijanych z *web2py* jeżeli nie one włączają *web2py* szyfr. Podanie
nie są pochodne użytki (podanie). Przykład: *BSD* działający system
jest zbierany z *gcc* który jest *GPL* ale *BSD* jest nie *GPL*.
NOTE: I do _not_ speak Polish (just trying to help, using
poltran.com ;-)
UWAGA: JA _nie _ mówią Język polski (po prostu próbujący pomoc,
używający *poltran.com* ;-)
yarko
> On Mar 27, 5:02 pm, Daniel Podlejski <under...@underley.eu.org> wrote:
>
>
>
> > > Ja sie i moze z toba zgodze. Ale prawnicy firmowi z tego co wiem mieli
> > > duzo obiekcji:D
>
> > Prawnicy mają zawsze całą masę obiekcji - za to biorą kasę.
>
> > Generalnie mam wrażenie, że GPL jest mocno demonizowana, choć nie
> > jest aż tak straszna jak niektórzy starają się ją przedstawić.
> > Parę lat temu Zbyszek Okoń trochę się rozpisywał o tym na pcoa.
> > To co zapamiętałem i tu przekazałem stosuje i jeszcze nikt mnie
> > nie pozwał ;)
>
> > > A co w kwesti mieszania licencji ?
> > > Masz jakies doswiadczenie w tej materii ?
>
> > Z tym to jest rzeczywiście straszny chaos i pewnie można osiwieć
> > w niektóych przypadkach. Mi na szczęście się taki jeszcze nie trafił.
>
> > --
> > Daniel Podlejski
>
>
> "*web2py* jest *GPL2* ale to nie rozprzestrzenia do użytków
> rozwijanych z *web2py* jeżeli nie one włączają *web2py* szyfr. Podanie
> nie są pochodne użytki (podanie). Przykład: *BSD* działający system
> jest zbierany z *gcc* który jest *GPL* ale *BSD* jest nie *GPL*.
>
> NOTE: I do _not_ speak Polish (just trying to help, using
> poltran.com ;-)
> UWAGA: JA _nie _ mówią Język polski (po prostu próbujący pomoc,
> używający *poltran.com* ;-)
Drugi punkt od Massima:
2 ) *web2py* prace z *memcache*, to jest co tam nie jest wiele
rozsądek (z *web2py*).
Artur Lew
> "*web2py* jest *GPL2* ale to nie rozprzestrzenia do użytków
> rozwijanych z *web2py* jeżeli nie one włączają *web2py* szyfr. Podanie
Ale jak widac Autorowi zalezy na dobrej opinii na temat jego frameworku
;) Swoja droga to maly z niego "klamczuch" poniewaz niby:
"Does not require any third party library..." a dziekuje polowie swiata
Pythonowego za uzyte biblioteki ;)
Jak juz ustalilismy bardziej niebezpieczne jest laczenie roznych
bibliotek i narzedzi w roznych licencjach i udostepnianie tego pod
wspolnym szyldem jako GPL. Oprocz kwestii licencji problemem jest
robienie update komponentow skladowych tego frameworka.
W tej kwestii duzo bardziej podoba mi sie rozwiazanie z Pylons.
yarko
Jaroslaw Zabiello
napisać coś merytorycznego na ten post, to może spróbuję.
Wpierw ogólne wrażenie. web2py powstał na użytek nauczania Pythona na
uniwersytecie w Chicago. Jego twórca jest tam wykładowcą. Stąd framework
ten jest bardzo łatwy do nauki i zawiera minimalną ilość wiedzy niezbędnej
do opanowania web2py. Np. weźmy kwestię helperów do kodu HTML. Zamiasty
małpować helepry z Rails (vide: Pylons) tu przyjęto banalne założenie.
Każdy helper ma nazwę taką jak odpowiadający mu tag HTML. Pierwszy
parametr zawiera treść wewnątrz taga. Named parameters odpowiadają
atrybutom taga. Zaś aby nie było kolizji z nazwami, np. dla class,
wszystkie zaczynają się znaku podkreślenia (a nie niektóre jak to inni
mają)
Albo szablony, są banalnie łatwe do zrozumienia. Przyjęto właściwie
podpowiednik PHP, JSP czy ERb z tym, że używana jest składnia znana z
Django i Liquid {{ kod }} i {{= wyswietl_kod }} aby w przeglądarce można
było wszystko zobaczyć. Zamiast dziwnych endifów (Django) cz # endifów
(Cheetah) przyjęto że koniec bloko wyznacza {{pass}}. Proste i
dosyć intuicyjne.
Albo maile? Zamiast jakiechś rozbuchanych modułów mailera po prostu używa
się smtplib. Biblioteke standardowa jest wystarczająco potężna.
Dnia 27-03-2008 o 08:16:24 Artur Lew <no_spam...@poczta.onet.pl>
napisał(a):
> * Nie sadze zeby pozwalal na takie bajery na jakie pozwala mi Routes w
> Pylonsach...
Np. jakie? routes_in i routes_put
> * Zbudowany na MVC, jak bym mial zaczynac cos nowego to czemu nie
> udostepnic uzytkownikowi czegos innego jak np IOC ?
A po cholerę? IOC jest zdecydowanie przereklamowane (vide koszmar w
Spring). Zresztą, kto tu komu broni użyć IOC?
> * Duzo bajerow w srodku ale wyglada ze za wszystkim stoi jedna osoba
> ktora kiedys polegnie pod naporem ticketow z bugami ;D Co wiecej Autor
> twierdzi ze wszystko przychodzi z paczka i nie wymaga zewnetrznych
> bibliotek a tutaj czytamy:
> "... simplejson developed by Bob Ippolito"
Czepiasz się. Większość web2py oparta jest na bibliotece standardowej. To
że ten system wymyślił jeden człowiek jest pewnym fenomenem, nie przeczę.
Choć z drugiej strony, z tego co czytałem, to nad tym frameworkiem pracują
chyba też jego studenci. To, że web2py z pudełka udostępnia system
ticketów w wypadku wystąpienia błędu to bardzo dobrze. Przyjrzyj się tym
ticketom, są bardzo czytelne, pokazują dokładnie kontekst kodu źródłowego
gdzie wystąpił błąd.
> Szablony:
> Nie rozumiem po co wymyslac kolejny genialny system template'ow z ciut
> dla mnie zbyt oryginalna skladnia tj:
> {{for i in range(10):}}hello{{pass}}
> Ciekawy jestem ile edytorow wspiera kolorowanie takiej skladni (oprocz
> TextMate)?
I tu się mocno zdziwisz. Składnia jest wpierana na poziomie browsera.
Wpierw nie mogłem uwierzyć. Praktycznie całą aplikację można zbudować bez
uruchamiania żadnego edytora. Jedynym innym znanym mi systemem tego typu
to Zope, ale Zope nie wspiera podświetlania składni kodu w przeglądarce, a
web2py - tak. Dodatkowo web2py wspiera oczywiście tryb wisiwyg.
> Na rynku jest teraz pare zajebiscie dobrych i sprawdzonych systemow
> szablonow jak Mako, Myghty czy Cheetah. Pamietam ile bylo z kazdym z
> nich bojow, ile rewizji trzeba byl oczekac na jakies poprawki zwiazane
> np z Unicode (Myghty). Kazdy z nich to teraz sprawdzona w bojach
> machina. Ten ich system jest nowiutki jak bulki z piekarni i mysle ze
> tez musi przejsc przez meke jak w/w frameworki.
No coż. Wszystkie te przykłady są dosyć trefnie dobrane bo zawierają swoją
własną składnię którą trzeba się nauczyć, parsować i tam pewnie twkwiło
źródło tych wszystkich błędów. Szablony web2py to czysty Python
zagnieżdżony w HTML. Jedyna różnica że nie ma znaczenia wcięcie i używa
się {{pass}}.
> ORM:
> Ludzie narzekaja ze jest malo dokumentacji do SQLAlchemy (ja znalazlem
> na razie paredziesiat MB ;) + ksiazka ktora sie drukuje) ktory teraz
> jest obecnie najbardziej rozbudowanym ORMem dla Pythona (i dla Javy tez
> ;)). A co powiedziec o ich malutkim ORMie ktorego dokumentacja to pare
> KB?
SQLAlchemy jest nadmiernie skomplikowane, niepythonowe i ponoć nawet
wolniejsze od ORM'a z web2py. Poza tym SQLAlchemy zdaje się, że nie
posiada mechanizmu migracji bazy, a web2py tak. Django i SQLOBject zdaje
się też tego nie mają.
> Formularze bazujace na modelu DB to tani bajer i istnieja juz dosc
> rozbudowane systemy (vide new forms w Django)
Formularze bazujące na modelu to bardzo pożyteczna rzecz a nie tani bajer.
> Interfejs do obslugi DB. Hmm... pgAdmin III juz nie wystarcza?
Nie bądź śmieszny, panel jaki udostępnia web2py pozwala na zbudowanie
całej aplikacji za pomocą przeglądarki. Obsługa bazy to malutki jego
wycinek. Choć warto wspomnieć o dostępnym sqldesignerze
(http://mdp.cti.depaul.edu/sqldesigner/default/sqldesigner).
> Lokalizacja:
> Zajebiste ulatwienie z lokalizacja poprzez "T" ;) Caly swiat uzywa "_" a
> kolesie wymyslaja sobie nowosc - T.
Argument typu miliardy much jedzących gówno nie mogą się mylić do mnie nie
dociera. Nie przepadam za gettext'em, a to o czym mówisz jest na tym
oparte. web2py inaczej rozwiązuje i18n. wygląda to trochę podobnie do
zope3. można z webu modyfikować w locie tłumaczenia, zero restartu
serwera, kompilacji plików po i innych pierdół. ekstrakcja napisów z
kontrolerów i szablonów jest natychmiastowa i nie wymaga żadnych restartów.
> Deployment.
> W porownianiu do Pylonsa/Django nie ma nawet co porownywac. Powstalo
> dziesiatki MB informacji jak to ustawic, skonfigurowac pod praktycznie
> wszystkimi front-endami jak Apache czy Lighty. Nie wspomne ze np
> Pylonsowy serwer zajebiscie dobrze sprawdza sie w dosc rozbudowanych
> srodowiskach i nie trzeba kombinowac z FastCGI, etc...
Tuś to przywalił. Po pierwsze, web2py z def. obsługuje wiele aplikacji.
Każda ma własny panel (w przeciwieństwie do Django), mechanizmy sesji itp.
Po drugie, deplopyment w wypadku web2py to bajka. Mimo, że zapoznałem się
z web2py dopiero w ten weekend, byłem w stanie dwoma kliknięciami (to b.
intuicyjne) zapisać wybraną aplikację w formie tar z wyciętymi źródłami
Pythona (to jest opcjonalne). Tak dystrybuowaną apliakcję można wczytać do
innego serwera dwoma kliknięciami z poziomu przeglądarki. Jeśli ma tylko
pliki pyc to opcje design do źródeł będą zablokowane. Zaś deployment
wszystkich tych aplikacji to zwykły proxy na Apache, Nginx do
wielowątkowego serwera web2py (jest b. szybki, oparty na CherryPy3 i
obsługuje SSL).
Jeśli chodzi o instalację to web2py ośmiesza to, ile trzeba się narobić w
Pylons. Tu nie ma żadnej konfiguracji. Ściągasz źródła, odpalasz ze środka
skrypt web2py i (domyślnie, bo to można zmienić) porcie 4000 stoi panel
gotowy do budowania aplikacji. Oczywiście, można użyć Komodo czy dowolnego
edytora jak ktoś chce. NIkt nie musi używać browsera, to tylko opcja, ale
dosyć kusząca bo zgrabnie to chodzi/
> Slowa nie ma takze o migracji aplikacji na nowa wersje co jest np
> dostepne w Pylons i chyba Django tez.
Jakiej migracji w nową wersję? Django jest niekompatybilny wstecz,
przecież.
> Community:
> Django czy Pylons moga sie pochwalic dosc liczna trzodka uzytkownikow...
> Tutaj caly FAQ miesci mi sie na 19 " po obroceniu ekranu ;)
To prawda. I co z tego? Rails ma jeszcze większą trzodke użytkowników, a
taki PHP to dopiero ma tabuny. :) Dokumentacja web2py nie jest taka zła.
Lista dyskusyjna na google groups jest z kolei dosyć pomocna. Szybko
odpisują na problemy. Jest też książka na Amazonie jeśli ktoś potrzebuje
więcej. Autor web2py wydaje się osobą otwartą na krytykę i pytania. Prosił
nawet aby ten wątek ktoś mu przetłumaczył, bo nie zna polskiego...
> Cache:
> Hmm moze "ram/disk/both" to duzo ;) ale gdzie wygoda z korzystania od
> razu z memcached tak jak oferuja to np Pylonsy?
> Chociaz wzmianka o "memcache" jest jakas
Przecież web2py też obsługuje memcached. Nie wiem o co ci chodzi.
http://mdp.cti.depaul.edu/AlterEgo/default/show/69
Podpinasz memcache tak jak tam napisano i reszta przykładów działa tak
samo.
Ogólnie, powiem tak. Jestem bardzo zaskoczony, że jedna osoba potrafiła
stworzyć taki dobry projekt. web2py jest bardzo ciekawym projektem. Będę
chciał jeszcze dokładniej go poznać (zamówiłem sobie książkę). Jestem
ciekaw jak wypadnie zestawienie web2py z mającym lada dzień wyjść Merb'em
1.0. Ale to będę wiedział jak trochę się tym więcej pobawię. Jest też
http:/web2py.pl (strona dopiero raczkuje i chyba ma wkrótce być zmienionyu
layout)/
--
Jarosław Zabiełło
http://blog.zabiello.com
Artur Lew
> Troche ostatnio sobie posiedziałem nad web2py, a że nikt nie kwapi sie
> aby napisać coś merytorycznego na ten post, to może spróbuję.
> ten jest bardzo łatwy do nauki i zawiera minimalną ilość wiedzy
> niezbędnej do opanowania web2py. Np. weźmy kwestię helperów do kodu
true
> HTML. Zamiasty małpować helepry z Rails (vide: Pylons) tu przyjęto
> banalne założenie. Każdy helper ma nazwę taką jak odpowiadający mu tag
Explicit is better than implicit.
Jakie widzisz opory przed uzywaniem: h.img zamiast img w jakims globalu ?
Ja jednak wole kodowac HTML-a w HTML-u a nie kolejnym potworku ktory ma
byc kolejnym jezykiem opisu HTML-a (nic tak dobrze nie tlumaczy
rekurencji jak rekurencja ? ;).
Ale o tym dalej...
> podpowiednik PHP, JSP czy ERb z tym, że używana jest składnia znana z
> Django i Liquid {{ kod }} i {{= wyswietl_kod }} aby w przeglądarce
Badzmy szczerzy - glownie chodzi o to ze ciezko bylo mu oprogramowac
jedna z 20 bibliotek w JS do edycji HTML-a ;).
Jak dla mnie skladnia beznadziejna. Pokazywalem to paru osobom orzekli
to samo. Nio dobra - skladnia JSP jest jeszcze brzydsza ;)
> można było wszystko zobaczyć. Zamiast dziwnych endifów (Django) cz #
> endifów (Cheetah) przyjęto że koniec bloko wyznacza {{pass}}. Proste i
> dosyć intuicyjne.
I dosc subiektywne odczucie.
W wielu silnikach do szablonow sa ladne konstrukcje konczace blok. A
pass? Za bardzo sie kojarzy z pythonowym znaczeniem ale ma inne
znaczenie. To moze juz lepiej {{end;}} zeby bardziej pascalowo bylo ;)
> Albo maile? Zamiast jakiechś rozbuchanych modułów mailera po prostu
Nie przesadzaj Jarku. Wyslanie emila to banal i ze framework jest super
bo to wspiera mozna z przymruzeniem oka potraktowac.
> Np. jakie? routes_in i routes_put
A widziales nowe routes ?
Sa wystarczajaco potezne zebym nie uzyl 80% ich funkcjonalnosci ;)
Po co wiec wymyslac nowe ?
Zwlaszcza ze stare swietnie sobie radza z poddomenami, httpsem czy proxy.
> A po cholerę? IOC jest zdecydowanie przereklamowane (vide koszmar w
Fakt, chcialem byc adwokatem diabla tutaj ;).
Wiekszosci smiertelnikow MVC wystarczy w zupelnosci.
> Czepiasz się.
Oczywiscie. Ale mimo tego ze nie zagrzales miejsca w zadnej technologii
dosc dlugo to zgodzisz sie ze to jeden z najwazniejszych argumentow.
Sourceforge pelne jest porzuconych projektow...
> Większość web2py oparta jest na bibliotece standardowej.
I tak i nie.
Generalizujac mozna smialo powiedziec ze kazdy program w Pythonie bazuje
na biblitece standardowej. W praktyce jednak duzo rozwiazan koles lyknal
z wielu roznych projektow
(http://mdp.cti.depaul.edu/examples/default/thanks).
Lyknal w okreslonym czasie ich developmentu a te projekty poszly do
przodu. Smiem twierdzic ze potrzeba niezlej bandy ludzi zeby sprawdzac
czy np super rozwiazanie zabrane z Pylonsa rok temu jest nadal takie
fajne i bezpieczne teraz. Pylons np pod tym wzgledem jest o tyle lepszy
ze laczy biblioteki na poziomie pakietow przez co jego autorzy nie musza
mergowac swojego kodu...
> To że ten system wymyślił jeden człowiek jest pewnym fenomenem, nie
To fakt i szacun wielki dla niego.
> frameworkiem pracują chyba też jego studenci. To, że web2py z pudełka
Ktorzy wlasnie sie pisza magisterke i zajma sie zarabianiem na zycie.
Chcialbys na czyms takim oprzec produkcyjny system ktory ma czas
implementacji np 2 lata?
> udostępnia system ticketów w wypadku wystąpienia błędu to bardzo dobrze.
Tani bajer. Tak jak u mnie w firmie ludzie sie podniecali ze mozna
jabbera podlaczyc do log4j ;)
> Przyjrzyj się tym ticketom, są bardzo czytelne, pokazują dokładnie
> kontekst kodu źródłowego gdzie wystąpił błąd.
Tak samo np w Pylons.
Nigdy sie chyba jeszcze nie zdazylo zebym nie dostal linii gdzie jest
blad w logach, tj emilu ktory przychodzi mi z bledem na skrzynke ;)
> I tu się mocno zdziwisz. Składnia jest wpierana na poziomie browsera.
Haha. Powiedz mi czy zartujesz czy mowisz powaznie ?
Ja rozumeim ze fakt - edycja szablonu strony w plain ascii przez
przegladarke to mocna strona. Tylko wyobraz sobie ze masz 200 szablonow
nad ktorymi masz zapanowac. Jakas kontrola wersji itp.
Nie wspomne ze co w przypadku gdy nasz geniusz zapomnial sie
zabezpieczyc przed jakims atakiem i te strony nieautoryzowany user
bedzie mogl edytowac?
;D
> bez uruchamiania żadnego edytora. Jedynym innym znanym mi systemem tego
Ta fakt. Do zabawy, zwlaszcza na studiach to swietna rzecz.
Pamietaj ze nie mowimy o jakims kolejnym CMS tylko o serwerze aplikacyjnym.
> wisiwyg.
A raczej WYSIMOLWYG ;)
Ehh...
> zagnieżdżony w HTML. Jedyna różnica że nie ma znaczenia wcięcie i używa
Tylko po jaka anielke mamy rozdzial na MVC?
W praktyce ktos, jakis designer bawi sie w szablonach HTMLowych.
Dla niego kazde wstawienie instrukcji jezyka do szablonu to zagwozdka.
Nie wspominajac ze zaden z nich nie zna Pythona i ryzyko ze cos spieprzy
jest bardzo duze.
Nie doczytalem do konca ale gdzie tam jest cacheowanie poszczegolnych
"szablonow" czy ich fragmentow ?
W pewnym sensie przypomina to gniota w postaci C# i WF i magiczne
InitializeComponent...
> SQLAlchemy jest nadmiernie skomplikowane, niepythonowe i ponoć nawet
true, true, true ;)
Ale bez wglebiania sie w straszne jego zawilosci mozesz dosc wygodnie
tworzyc dosc skomplikowane rzeczy (bez pieprzenia sie chociazby w jakies
hbm-y ;)). Masz tez juz kilka wrapperow na niego ktore sprowadzaja
podlaczenie DB do paru linijek...
> wolniejsze od ORM'a z web2py.
Najszybsze jak wiemy sa proste kursory i bulk load...
Rozumiem ze kazdy kto uzywa ORM-a zdaje sobie sprawe z jego plusow
dodatnich i ujemnych ;). Zalet jest odpowiednio duzo zeby sie zbiesic i
zapomniec o milisekundach w zapytaniach ;)
> Poza tym SQLAlchemy zdaje się, że nie
> posiada mechanizmu migracji bazy,
Z tego co wiem to jest kilka niezaleznych i ktos pracuje nad tym.
W praktyce wiem jedno - nikt jeszcze nie wymyslil uniwersalnego sposobu
migracji DB za pomoca automatu i konczy sie zawsze na wlasnym skrypcie z
duza ilosia ifow...
A praktyka to m in pisanie poteznych aplikacji na amerykanski rynek
medyczny od 8 latek...
> Formularze bazujące na modelu to bardzo pożyteczna rzecz a nie tani bajer.
Tak pod warunkiem ze masz na mysli proste formatki.
Jezeli ciagniesz dane z wielu zrodel albo np z widoku to juz czesto jest
problem ze sie nie da zamapowac takiej struktury.
A co jeszcze w przypadku gdy potrzebujesz cos wiecej niz cienki klient
po stronie przegladarki? Uzycie np Ext-a skutecznie rozwala wiekszosc
gotowcow.
>> Interfejs do obslugi DB. Hmm... pgAdmin III juz nie wystarcza?
> Nie bądź śmieszny, panel jaki udostępnia web2py pozwala na zbudowanie
Hahah. Jarku prosze Cie to ty nie badz smieszny.
Mowisz o szablonie prostej aplikacji.
Pokaz mi Sherlocku jak dodac tam np indeksy funkcyjne albo zdefiniowac
pare funkcji czy triggerow...
A nie wspomne ze w normalnych aplikacjach tabele nie maja po 5 pol tylko
kilkadziesiat...
> wycinek. Choć warto wspomnieć o dostępnym sqldesignerze
To takze zabawka.
Zobacz sobie co oferuje np wspomniany pgAdmin III.
Duzej ilosci opcji nie ma nawet platny PL/SQL Developerze dla Oracla...
> Argument typu miliardy much jedzących gówno nie mogą się mylić do mnie
Ja takze stanowczo unikam podobnych porownan.
Pewnie dlatego tepie Jave w firmie ;)
Ale wez pod uwage fakt ze do tego magicznego gettext-a masz mase
gotowych narzedzi kompatybilnych ze soba.
Za pomoca poEdit-a np robisz banalne tlumaczenie, aktualizacja zrodel za
pomoca tego co oferuje np Pylons to 1 linijka komendy do pastera...
Co wiecej te narzedzia sa od lat, sa znane i sprawdzone.
Dzieki czemu wiem ze jak np wysylam do Saratova tlumaczenie na rosyjski
to koles bedzie mial narzedzie zlokalizowane dla rosyjskiego...
Widze ze na razie w tej gonitwie po frameworkach i technologiach nie
zetknales sie z takim pojeciem jak stabilnosc technologii ;)
> zope3. można z webu modyfikować w locie tłumaczenia, zero restartu
A ile razy na produkcyjnym serwerze miales koniecznosc poprawy tlumaczen
w locie?
> kontrolerów i szablonów jest natychmiastowa i nie wymaga żadnych restartów.
Tja, a konflikty czy nieprecyzyjne tlumaczenia ?
> Tuś to przywalił. Po pierwsze, web2py z def. obsługuje wiele aplikacji.
To takze nie jest problem.
Nie wymagam np od Pylonsa zeby jeden serwer obslugiwal mi wielu
niezaleznych klientow (aplikacji).
> itp. Po drugie, deplopyment w wypadku web2py to bajka. Mimo, że
Mowisz caly czas o uruchomieniu prostej aplikacji.
Klastra juz przez przegladarke nie uruchomisz...
> wyciętymi źródłami Pythona (to jest opcjonalne). Tak dystrybuowaną
Czyli innymi slowy normalny egg ;)
> apliakcję można wczytać do innego serwera dwoma kliknięciami z poziomu
> przeglądarki.
Nie wiem w czym ma sie kryc wygoda. To samo zrobie szybciej i
bezpieczniej na konsoli.
> zablokowane.
Na produkcyjnych serwerach nie daje sie mozliwosci edycji zrodel z
przegladarki ;)
> Apache, Nginx do wielowątkowego serwera web2py (jest b. szybki, oparty
To wiem.
> Jeśli chodzi o instalację to web2py ośmiesza to, ile trzeba się narobić
> w Pylons.
??
easy_install Pylons ?
paster serve development.ini
To duzo ?
Mozesz sobie to w jednym pliku stworzyc jak za duzo;)
> Jakiej migracji w nową wersję? Django jest niekompatybilny wstecz,
To mozliwe.
Pylons dosc zgrabnie potrafi mi przeanalizowac stare zrodla i powiedziec
co mam zmienic (sam tez potrafi(l) to zrobic).
> taki PHP to dopiero ma tabuny. :) Dokumentacja web2py nie jest taka zła.
Przyznam ze od ostatniego czasu jest tego dosc duzo.
Pewnie wielu studentow sie bronilo i kazdy mial 70 stron do napisania ;)
> więcej. Autor web2py wydaje się osobą otwartą na krytykę i pytania.
Wiem, sam do mnie pisal przerazony ze ktos "szkaluje" mu framework po
polsku ;)
> Prosił nawet aby ten wątek ktoś mu przetłumaczył, bo nie zna polskiego...
hahah, dokladnie o tym mowie ;)
> Podpinasz memcache tak jak tam napisano i reszta przykładów działa tak
true, dodali to.
> Ogólnie, powiem tak. Jestem bardzo zaskoczony, że jedna osoba potrafiła
> stworzyć taki dobry projekt.
true
> ciekaw jak wypadnie zestawienie web2py z mającym lada dzień wyjść
I znowu benchmarki a wiesz ze nie zawsze te Ci dobrze wychodza ;)
> Jest też http:/web2py.pl (strona dopiero raczkuje i chyba ma wkrótce być
Podobnie jak kazda polska strona dotyczaca jakiegos frameworku
Pythonowego :( A szkoda.
Reasumujac:
Nie twierdze ze web2py to jakis gniot czy cos.
Bo pare rozwiazan ma bardzo fajnych (vide testy przez www).
Po prostu chodzi mi o to ze za wczesnie jest mowic o tym ze jest
killerem rynku a tym bardziej ze zdetronizowal Django/Pylons czy zblizyl
sie jakos do Zope ;)
Co do rozwiazan produkcyjnych do jeszcze jest przed nimi szmat czasu.
Zobaczymy czy nie zgina smiercia naturalna po roku ;)
Jaroslaw Zabiello
napisał(a):
> Ja jednak wole kodowac HTML-a w HTML-u a nie kolejnym potworku ktory ma
> byc kolejnym jezykiem opisu HTML-a (nic tak dobrze nie tlumaczy
> rekurencji jak rekurencja ? ;).
Helpery skracają zapis. W wypadku wep2py nie trzeba się uczyć żadnego
specjalnego języka. Zasady są oczywiste. Co innego u innych.
> Ale mimo tego ze nie zagrzales miejsca w zadnej technologii dosc dlugo
Sam chyba nie zagrzałeś.
>> frameworkiem pracują chyba też jego studenci. To, że web2py z pudełka
> Ktorzy wlasnie sie pisza magisterke i zajma sie zarabianiem na zycie.
A ty w ogóle spróbowałeś go że tak krytykujesz?
> Nie wspomne ze co w przypadku gdy nasz geniusz zapomnial sie
> zabezpieczyc przed jakims atakiem i te strony nieautoryzowany user
> bedzie mogl edytowac?
A skąd wiesz, że się nie zabezpieczył?
> Pamietaj ze nie mowimy o jakims kolejnym CMS tylko o serwerze
> aplikacyjnym.
Jakim serwerze aplikacyjnym? Ani web2py ani Pylons nim nie jest. Jeśli
już, to Zope.
> W praktyce ktos, jakis designer bawi sie w szablonach HTMLowych.
> Dla niego kazde wstawienie instrukcji jezyka do szablonu to zagwozdka.
> Nie wspominajac ze zaden z nich nie zna Pythona i ryzyko ze cos spieprzy
> jest bardzo duze.
Wszystko zależy kto pracuje nad szablonami. Bo są i tacy dla których
Django/ Liquid będą niestrawne, bo nie czują ani nie widzą potrzeby
uczenia się programowania, zaś z drugiej strony posługują się sprawnie
Dreamweaverem. W takim wypadku jeszcze szablonami będą ZPT, Kid czy Genshi.
>> wolniejsze od ORM'a z web2py.
> Najszybsze jak wiemy sa proste kursory i bulk load...
Tylko że web2py, jeśli wierzyć temu co piszą (bo nie sprawdzałem) jest 4x
szybszy od pastera a ich ORM jakieś 2x szybszy od SQLAlchemy (nie mówiąc o
prostocie) i nie trzeba sięgać aż do poziomu kursorów (choć można).
>> Formularze bazujące na modelu to bardzo pożyteczna rzecz a nie tani
>> bajer.
> Tak pod warunkiem ze masz na mysli proste formatki.
> Jezeli ciagniesz dane z wielu zrodel albo np z widoku to juz czesto jest
> problem ze sie nie da zamapowac takiej struktury.
> A co jeszcze w przypadku gdy potrzebujesz cos wiecej niz cienki klient
> po stronie przegladarki?
Od tego jest Flash. Żaden Javascript mu nie podskoczy.
> Uzycie np Ext-a skutecznie rozwala wiekszosc gotowcow.
Ext jest dla masochistów lub przynajmniej zdecydowanych fanów JavaScriptu.
Ext to framework sam dla siebie. Więcej jednak z nim kłopotów niż
korzyści. Jeśli już miałbym pchać się w takie duże rzeczy, to wolałbym
YUI. Osobiście jednak wolę jQuery.
>>> Interfejs do obslugi DB. Hmm... pgAdmin III juz nie wystarcza?
Nie każdy używa PostgreSQL'a. Poza tym, ty masz na myśli jakąś inną skalę
aplikacji.
> Ale wez pod uwage fakt ze do tego magicznego gettext-a masz mase
> gotowych narzedzi kompatybilnych ze soba.
Miałem złe doświadczenia z gettextem. Konieczność przeładowywania
aplikacji po każdej zmianie... no i zachciało mi się ręcznie edytować
pliki po, co było koszmarem, bo są one bardzo wrażliwe na głupie błędy.
Być może, gdybym użył poEdit'a byłoby lepiej. W każdym razie podejście
jakie użyto w Globalize do Rails było prostsze i umożliwiało
natychmiastową, równoległą pracę nad aplikacją bez przerywania prac
ciągłymi restartami serwera.
Poza tym jest jeden argument, który podcina sens gettext'a - nie nadaje
się do tłumaczeń danych trzymanych w bazie. Gettext stworzono to
tłumaczenia interfejsów. Wolę rozwiązania oparte na bazie danych (tak jak
wspomniany Globalize)
>> zope3. można z webu modyfikować w locie tłumaczenia, zero restartu
> A ile razy na produkcyjnym serwerze miales koniecznosc poprawy tlumaczen
> w locie?
Tylko, że Zope nie ma typowego systemu plików ale używa bazę obiektową.
Jak niby chciałbyś odwzorować jej obiekty w płaskim pliku po? Gettext tu
się nie nadaje. Co do wersjonowania, to Zope wersjonuje każdą operację na
obiekcie i masz do wszystkiego undo.
>> kontrolerów i szablonów jest natychmiastowa i nie wymaga żadnych
>> restartów.
>
> Tja, a konflikty czy nieprecyzyjne tlumaczenia ?
Jakie konflikty? Jak coś jest źle przetłumaczone, to otwierasz sobie
browser i poprawiasz a zmiana wskakuje natychmiast brz przerywania pracy.
>> web2py z def. obsługuje wiele aplikacji.
>
> Nie wymagam np od Pylonsa zeby jeden serwer obslugiwal mi wielu
> niezaleznych klientow (aplikacji).
A co, jak ktoś wymaga? Zobacz wpinanie aplikacji w projekt Django, albo
slices w Merb'ie, albo produkty w Zope. To chyba normalne, że portal
>> itp. Po drugie, deplopyment w wypadku web2py to bajka. Mimo, że
> Mowisz caly czas o uruchomieniu prostej aplikacji.
> Klastra juz przez przegladarke nie uruchomisz...
No fakt. Ja mówię o względnie prostej aplikacji a ty jakichś kolosach.
>> wyciętymi źródłami Pythona (to jest opcjonalne). Tak dystrybuowaną
>
> Czyli innymi slowy normalny egg ;)
No niezupełnie. To nie jest egg. web2py pozwala na dystrybucję aplikacji
skompilowanych, pozbawionych kodu źródłowego.
>> Jeśli chodzi o instalację to web2py ośmiesza to, ile trzeba się narobić
>> w Pylons.
> ??
> easy_install Pylons ?
> paster serve development.ini
> To duzo ?
Chyba sobie jaja robisz. To dopiero początek męki. Ustawianie wszystkich
opcji w Pylons jest upierdliwe i nieoczywiste. Już Django jest tu
prostsze. web2py nie wymaga praktycznie żadnych konfiguracji.
>> taki PHP to dopiero ma tabuny. :) Dokumentacja web2py nie jest taka zła.
> Przyznam ze od ostatniego czasu jest tego dosc duzo.
> Pewnie wielu studentow sie bronilo i kazdy mial 70 stron do napisania ;)
Mało - źle. Dużo - też źle. Trudno ci dogodzić. Jest jeszcze (niezła)
książka do web2py, jak nie wiesz.
>> więcej. Autor web2py wydaje się osobą otwartą na krytykę i pytania.
> Wiem, sam do mnie pisal przerazony ze ktos "szkaluje" mu framework po
> polsku ;)
No to mu coś odpisz jak masz odwagę. Ja nie znam web2py aż tak dobrze.
> Po prostu chodzi mi o to ze za wczesnie jest mowic o tym ze jest
> killerem rynku a tym bardziej ze zdetronizowal Django/Pylons czy zblizyl
> sie jakos do Zope ;)
Nie wiem czy killer, ale uważam, że web2py jest dużo *prostszy* od Pylons,
jest ładnie wyposażony i może odebrać trochę userów konkurentom. To co mi
się najbardziej spodobało w web2py to jego pythonowa filozofia, prostota +
batteries includes. To najprostszy framework w Pythonie oferujący
równocześnie wszystko "z pudełka". I to jest jego siła, mimo że (nie
przeczę) Pylons potrafi więcej.
Zaś Zope to inna klasa i skala. Jest poza zasięgiem ich wszystkich. Ale
też jest dużo bardziej złożony.