TurboGears na Pylonsach
Grzegorz Staniak - 28-06-2007 00:02
TurboGears na Pylonsach
OIDP ktoś kiedyś powiedział, że duża liczba konkurujących ze sobą
webowych frameworków w Pythonie wynika z faktu, że bardzo łatwo
jest coś takiego w tym języku napisać. Mark Ramm (autor "Rapid Web
Applications with TurboGears") bloguje na temat eksperymentalnego
przepisania TurboGears z Cherrypy na Pylons. Trzech facetów, jeden
weekend:
http://compoundthinking.com/blog/ind...in-turbogears/
GS
--
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>
Piotr Husiatynski - 28-06-2007 00:02
Dnia Wed, 27 Jun 2007 06:18:24 +0000, Grzegorz Staniak napisał(a):
> OIDP ktoś kiedyś powiedział, że duża liczba konkurujących ze sobą
> webowych frameworków w Pythonie wynika z faktu, że bardzo łatwo
> jest coś takiego w tym języku napisać. Mark Ramm (autor "Rapid Web
> Applications with TurboGears") bloguje na temat eksperymentalnego
> przepisania TurboGears z Cherrypy na Pylons. Trzech facetów, jeden
> weekend:
>
> http://compoundthinking.com/blog/ind...in-turbogears/
>
> GS
Czy Pylons to juz nie framework? Czyli powstanie framework++.
Mam nadzieje ze szybko skoncza prace i bede mogl wyprobowac nowego
Turbogears, bo po przygodach z cherrypy nie chcialem nawet tego instalowac.
Grzegorz Staniak - 28-06-2007 00:02
On 27.06.2007, Piotr Husiatynski <phusiatynski@gmail.com> wroted:
>> OIDP ktoś kiedyś powiedział, że duża liczba konkurujących ze sobą
>> webowych frameworków w Pythonie wynika z faktu, że bardzo łatwo
>> jest coś takiego w tym języku napisać. Mark Ramm (autor "Rapid Web
>> Applications with TurboGears") bloguje na temat eksperymentalnego
>> przepisania TurboGears z Cherrypy na Pylons. Trzech facetów, jeden
>> weekend:
>>
>> http://compoundthinking.com/blog/ind...in-turbogears/
>
> Czy Pylons to juz nie framework? Czyli powstanie framework++.
W zasadzie port API TurboGears na Pylonsach.
> Mam nadzieje ze szybko skoncza prace i bede mogl wyprobowac nowego
> Turbogears, bo po przygodach z cherrypy nie chcialem nawet tego instalowac.
Nie jesteś w tym odczuciu osamotniony (aczkolwiek trzeba przyznać, że
wersja 3.0 idzie w dobrym kierunku). Ten powyższy eksperyment to jedno,
a RhubarbTart (minimalny kod zgodny z CP do zastąpienia go w TG) to
drugie. Za jakiś czas może CP w TurboGears już nie być.
GS
--
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>
=?UTF-8?B?UmFmYcWC?= Zawadzki - 28-06-2007 00:02
Grzegorz Staniak wrote:
> OIDP ktoś kiedyś powiedział, że duża liczba konkurujących ze sobą
> webowych frameworków w Pythonie wynika z faktu, że bardzo łatwo
> jest coś takiego w tym języku napisać.
IMVHO swego czasu wszystkie były tak żałosne, że łatwiej było zacząć pisanie
od zera niż dopasowywanie się do kulawej koncepcji istniejących ;)
pozdrawiam
--
bluszcz
http://glam.pl
Rob Wolfe - 28-06-2007 00:02
Grzegorz Staniak napisał(a):
> OIDP ktoś kiedyś powiedział, że duża liczba konkurujących ze sobą
> webowych frameworków w Pythonie wynika z faktu, że bardzo łatwo
> jest coś takiego w tym języku napisać.
No tak, tylko zadziwia mnie jeden fakt. Podobno (bo osobiście się z
tym
nie zgadzam) w Ruby jest równie łatwo albo i łatwiej, a jednak tamta
społeczność nie tworzy tych frameworków hurtowo (raczej trudno
mi uwierzyć w to, że Rails spełnia oczekiwania wszystkich).
Może to wynika z faktu, że społeczność Pythona jest bardziej
kreatywna, a może bardziej wybredna?
RW
riklaunim@gmail.com - 28-06-2007 00:02
TG 1 "nie jest" WSGI, TG 2 ma być z tym że chyba nie wiedzą do końca
co chcą zrobić. To co wypuszczają jako komponenty WSGI - toscawidgets
itp. od razu "przejmuje" Pylons, w którym to łatwo wykorzystać. Było
też coś o połączeniu projektów to i teraz może być o zrobieniu TG w
Pylonsie.
Grzegorz Staniak - 28-06-2007 00:02
On 27.06.2007, riklaunim@gmail.com <riklaunim@gmail.com> wroted:
> TG 1 "nie jest" WSGI, TG 2 ma być z tym że chyba nie wiedzą do końca
> co chcą zrobić. To co wypuszczają jako komponenty WSGI - toscawidgets
> itp. od razu "przejmuje" Pylons, w którym to łatwo wykorzystać. Było
> też coś o połączeniu projektów to i teraz może być o zrobieniu TG w
> Pylonsie.
Zasadniczo, to właśnie to w ten weekend zrobili - przeportowali API
TG na Pylonsy.
GS
--
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>
Grzegorz Staniak - 28-06-2007 00:02
On 27.06.2007, riklaunim@gmail.com <riklaunim@gmail.com> wroted:
> TG 1 "nie jest" WSGI, TG 2 ma być z tym że chyba nie wiedzą do końca
> co chcą zrobić. To co wypuszczają jako komponenty WSGI - toscawidgets
> itp. od razu "przejmuje" Pylons, w którym to łatwo wykorzystać. Było
> też coś o połączeniu projektów to i teraz może być o zrobieniu TG w
> Pylonsie.
Cytat z Marka Ramma na liście TurboGears:
Recently there have been a number of requests for more clarity about
the future of TurboGears, and since I've been involved heavily with a
couple of experimental projects designed to help us explore our
options, I'd like to help clarify things as best I can.
A bit over a week ago several of us decided to get together in Atlanta
this past weekend and hack on an experimental Pylons/TurboGears
integration project. We wanted to discover if we could re-implement
the TurboGears API on top of paste+pylons in a way that would make
TurboGears better.
[...]
On all counts, I think we can now say that this experiment has been a
huge success. And after lots of good discussion with Alberto, Kevin,
and Ben Bangert from the Pylons project, the way forward is now much
clearer. The results of the sprint will become the basis for
TurboGears 2.0.
GS
--
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>
=?ISO-8859-2?Q?Rados=B3aw_Bu=B3at?= - 28-06-2007 00:02
Rob Wolfe napisał(a):
> No tak, tylko zadziwia mnie jeden fakt. Podobno (bo osobiście się z
> tym
> nie zgadzam) w Ruby jest równie łatwo albo i łatwiej, a jednak tamta
> społeczność nie tworzy tych frameworków hurtowo
Pisanie frameworków w Rubym jak i Pythonie jest równie łatwe. Nie widzę
powodów, żeby było inaczej.
>(raczej trudno mi uwierzyć w to, że Rails spełnia oczekiwania wszystkich).
Na pewno wszystkich nie zadowoli, ale myślę, że bardzo dużą część.
Myślę, że duże znaczenie ma tu fakt, że Ruby jest ogromnie elastycznym
językiem i pozwala na dość głębokie ingerowanie w to co, jak i kiedy
robi. Dzięki temu jak coś komuś nie pasuje, albo brakuje (a zdarza się
to często) to wystarczy napisać jakiś plugin, zmienić definicję jakiejś
metody itp. Prosty przykład. RoR nie wspiera złożonych kluczy, ale
nikomu to nie przeszkodziło w napisaniu odpowiedniego plugina. A jeśli
już komuś ewidentnie nie pasuje RoR jako całość (co jest raczej
niemożliwe, bo implikowałoby to prawdopodobnie, że język Ruby także mu
nie leży) to ma kilka innych możliwości. Są to: nitro
(http://www.nitroproject.org/), camping
(http://redhanded.hobix.com/bits/camp...ramework.html), hobo
(http://hobocentral.net/) framework oparty na... RoR, Merb
(http://merb.rubyforge.org/files/README.html).
> Może to wynika z faktu, że społeczność Pythona jest bardziej
> kreatywna, a może bardziej wybredna?
Oj, bynajmniej! Społeczność Ruby jest ogromnie kreatywna. Nie zamierzam
jej porównywać do społeczności Pythona (której tak dobrze nie znam), ale
jestem prawie pewien, że obie społeczności są pod tym względem podobne.
Społeczność Ruby swoją kreatywność opiera raczej na tym co już istnieje,
zamiast wymyślać koło po raz n-ty. I tak, zamiast tworzyć kolejnego
frameworka może lepiej byłoby wykorzystać już istniejący, albo dopisać
plugin?
Kiedyś oglądałem, być może znany Wam, film video z prezentacji Django i
Rails. Snakes and Rubies:
http://video.google.com/videoplay?do...56954580527226 . DHH trochę
ironicznie zapytał (1h:55m:30s), że skoro Python podkreśla "There should
be only one way to do it" to dlaczego jest tyle frameworków w Pythonie?:)
Jaroslaw Zabiello - 29-06-2007 00:02
Dnia 27-06-2007 o 23:22:38 Radosław Bułat <radarrek@poczta.fm> napisał(a):
> Kiedyś oglądałem, być może znany Wam, film video z prezentacji Django i
> Rails. Snakes and Rubies:
> http://video.google.com/videoplay?do...56954580527226 . DHH trochę
> ironicznie zapytał (1h:55m:30s), że skoro Python podkreśla "There should
> be only one way to do it" to dlaczego jest tyle frameworków w Pythonie?:)
Tu akurat DHH się wygłupił a jego adwersarz tego nie wykorzystał. A mógłby
np. wskazać na zaśmieconą przestrzeń nazw Rubiego (wiele metod występuje
pod kilkoma nazwami). Ta zasada "jednej drogi" dotyczy języka, a nie
ilości, czy różnorodności, aplikacji napisanych w Pythonie. W Pythonie
jest mniej konstrukcji, mniej metod w obiektach itp. Ma to oczywiście
zalety jak i wady. Zalety, bo łatwiej Pythona się nauczyć, a wady, bo
więcej metod (pomijam te nadmiarowe aliasy) daje większe możliwości i
skraca końcowy kod. Inna sprawa kopletnie zupełnie inna filozoficznie
między Ruby i Pythonem to kwestia podejścia explicite (jawne) vs.
implicite (bardziej magiczne). Ruby jest bardziej "magiczny". To też ma
plusy (kod b. ładnie wygląda) ale i spore wady, bo "magiczny" kod jest na
pewno trudniejszy (bardziej czasochłonny) w debugowaniu. Tropienie czegoś
w Ruby to czasem nie byle wyzwanie.
--
Jarosław Zabiełło
http://blog.zabiello.com
Grzegorz Staniak - 29-06-2007 00:02
On 27.06.2007, Radosław Bułat <radarrek@poczta.fm> wroted:
[...]
> Kiedyś oglądałem, być może znany Wam, film video z prezentacji Django i
> Rails. Snakes and Rubies:
> http://video.google.com/videoplay?do...56954580527226 . DHH trochę
> ironicznie zapytał (1h:55m:30s), że skoro Python podkreśla "There should
> be only one way to do it"
To jest notorycznie przekręcane: "one - and _preferably_ only one -
_obvious_ way to do it" (podkreślenia moje). Jeden _oczywisty_ sposób,
tzn. język powinien wskazywać łatwą drogę. Nikt nie twierdzi, że powinna
być tylko i wyłącznie jedna droga.
> to dlaczego jest tyle frameworków w Pythonie?:)
Moja prywatna teoria - ponieważ infrastruktura w momencie nadejścia czasu
na frameworki webowe była na tyle dojrzała i funkcjonalna, że napisanie
własnego było kwestią kilku dni. Pierwsza wersja TurboGears to było jakieś
200 linii kleju między gotowymi komponentami.
GS
--
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>
Sulsa - 29-06-2007 00:19
On Thu, 28 Jun 2007 00:22:38 +0200
Radosław Bułat <radarrek@poczta.fm> wrote:
> A jeśli
> już komuś ewidentnie nie pasuje RoR jako całość (co jest raczej
> niemożliwe, bo implikowałoby to prawdopodobnie, że język Ruby także mu
> nie leży)
No zobacz nie mozliwe stalo sie mozliwe, ja rubiego nie lubie, wiec
pewnie RoR pewnie tez ;)
=?ISO-8859-2?Q?Rados=B3aw_Bu=B3at?= - 02-07-2007 00:01
Sulsa napisał(a):
> On Thu, 28 Jun 2007 00:22:38 +0200
> Radosław Bułat <radarrek@poczta.fm> wrote:
>
>> A jeśli
>> już komuś ewidentnie nie pasuje RoR jako całość (co jest raczej
>> niemożliwe, bo implikowałoby to prawdopodobnie, że język Ruby także mu
>> nie leży)
>
> No zobacz nie mozliwe stalo sie mozliwe, ja rubiego nie lubie, wiec
> pewnie RoR pewnie tez ;)
Chodziło mi o to, że jak ktoś lubi język Ruby to raczej jest
nieprawdopodobne, że nie będzie lubić RoR :-).
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
|
Kodowanie: z iso na utf
foto -> rysunek
[ntg] sklepy oferujace programy graficzne...
mysql - replikacja w ramach tego samego serwera (lub bazy)
monitorowanie MSSQL ze zdalnej maszyny
phpSolutions - szewc bez =?UTF-8?B?YnV0w7N3?=
Foramtowanie danych
[sqlite] sortowanie
Kopiowanie rekordów
Wskazanie odtwarzaczowi w swf co ma grac
zanotowane.pldoc.pisz.plpdf.pisz.pltejsza.htw.pl
Cytat
Decede mihi sole - nie zasłaniaj mi słonca.
Gdy kogoś kochasz, jesteś jak stworzyciel świata - na cokolwiek spojrzysz, nabiera to kształtu, wypełnia się barwą, światłem. Powietrze przytula się do ciebie, choćby był mróz, a ty masz w sobie tyle radości, że musisz ją rozdawać wokoło, bo się w tobie nie mieści
Hoc fac - tak czyń.
A tergo - od tyłu; z tyłu.
I czarne włosy posiwieją. Safona |
|
