Jakiego frameorka wybrac...
Husio
swojego ulubionego frameworka, wypisujac glownie wady innych. Im wiecej
czytam takich wiadomosci tym mniej wiem :/ A chce wybrac sobie jakis
dobry dla poczatkujacego server. Cos co pozwoli mi szybko rozwinac
swoje umiejetnosci, a zarazem nie bedzie straszna katorga. Probowalem
juz z zope3, cheppypy, apache+mod_python i mam zamiar poczytac troche o
Django.
Wlasciwie o zadnej z aplikacji nie mam wiekszego pojecia bo ciagle ktos
mi mowi ze nie oplaca sie uzywac X bo 'costam'. Wiec odkladam X i
probuje innej aplikacji.
Do czego daze :
Chcialbym abyscie poradzili mi z czym najlepiej zaczac. Wiem ze kazdy
zawsze zachwala to co najberdziej mu sie podoba, a reszta to diabel
wcielony i nalezy omijac szerokim lukiem, ale prosilbym o mozliwie
bezstronna ocene. Zalezy mi glownie na zdobytej wiedzy a nie na
sprawnie dzialajacym servisie/stronie (choc jedno wiaze sie z drugim)
pozdrawiam
Badziu
pylons'a - mam nadzieje ze nie bede zalowal.
Mozna by sie pokusic o stworzenie kryteriów wobec których powinnismy
ocenic dostepne frameworki i wybrac najlepszy...
Co wy na to ?
Husio
znalazly czas zeby dopisac pare linijek wlasnej oceny do wiki pythona
http://python.kofeina.net/ Mysle ze ulatwiloby to wybor wielu
poczatkujacym
Jaroslaw Zabiello
> Szczerze powiedziawszy mam/mialem ten sam problem. Poszedlem w strone
> pylons'a - mam nadzieje ze nie bede zalowal.
Mnie jednej rzeczy brakuje w Pylons: dokumentacji i więcej przykładów. Na
ircu (#myghty on irc.freenode.net) warto się o to przypominać. Jak ostatnio
rozmawiałem, to podobno jest to teraz ich najwyższy priorytet. Mają opisać
krok po kroku tworzenie wzorcowej aplikację. Bez tego, jaki by nie zrobili
framework, większość nie będzie miała siły, ani wiedzy, by skutecznie go
używać. Jak możesz, to naciskaj ich o to.
--
Jarosław Zabiełło
http://blog.zabiello.com
Jaroslaw Zabiello
> Do czego daze :
> Chcialbym abyscie poradzili mi z czym najlepiej zaczac. Wiem ze kazdy
> zawsze zachwala to co najberdziej mu sie podoba, a reszta to diabel
> wcielony i nalezy omijac szerokim lukiem, ale prosilbym o mozliwie
> bezstronna ocene. Zalezy mi glownie na zdobytej wiedzy a nie na
> sprawnie dzialajacym servisie/stronie (choc jedno wiaze sie z drugim)
Paru z nas obecnych na tej grupie trochę wieszało psy na CherryPy.
Napisaliśmy dla Muratora dosyć złożony serwis w CherryPy. Sam framework
wyglądał od początku atrakcyjnie. Był prosty, zbliżony do filozofii
Pythona. W sumie ja go wybrałem. Niestety, później okazało się że ma sporo
błędów w implementacji. Ale to nie jest najgorsze, bo błędy są wszędzie.
Najgorsze jest olewackie podejście developerów CherryPy, którzy
*bagatelizują* problemy i konieczność zachowania ostrożności przy
modyfikacji API z dnia na dzień bez żadnych ostrzeżeń. To jest największa
zmora tego frameworka. Nie znasz dnia ani godziny. Jutro nagle, coś zmienią
w API i ci się posypie aplikacja. Tak już parę razy było, włącznie z nagłą
decyzją o porzuceniu obsługi forków o które nie dość że nie napisano, to na
www przez długi czas istniała myląca informacja, że to jest obsługiwane
(sic!). Gdy zwróciłem im uwagę, że to bujda, bo to już nie jest wspierane,
i że ktoś powinien poprawić informację, to Remi to mi odpisał abym sobie
sam zmieniał w wiki. Takie to podejście developerów CherryPy. Strach się
bać.
TurboGEARS i zdaje się Subway są też oparte na CherryPy, więc dziedziczą
jego wady. Np. ciagły problem z implementacją sesji, poprawnym
zaimplementowaniem wątków i blokad itp.
Dosyć dużo dobrej opinii jest na temat Django. Sam Guido van Rossum
najwyraźniej się ku niemu skłania. Oficjalna strona Pythona wymienia go
zaraz po Zope (fakt, że nastepnym jest TurboGEARS, ale pewnie oni chyba nie
wiedzą o problemach z CherryPy). Co do Django, to ma dużo zalet, ale wciąż
nie ma wersji 1.0 ani 0.92 i trwa oczyszczanie apis z "magii". Mają też
dodać obsługę Ajax'a. W sumie można na tym już coś budować, ale trzeba mieć
na względzie że trochę będzie zmian w nowej wersji. Jednak trzeba oddać im
honor, że robią to ostrożnie, podają co się zmienia i nawet zamrażają
dokumentację do poprzedniej wersji. Czyli podchodzą znacznie bardziej
profesjonalnie od CherryPy.
Poza Django, dużo nadziei wzbudza Pylons. Jest bardzo elastyczny, można w
nim nawet uruchamiać Django czy TurboGEARS. Oparty jest na, moim zdaniem,
dobrze napisanym Myghty, "zportowali" do Pythona helpery z Ruby on Rails,
mozna nawet z projektu zbudować gotowy pakiet egg do dystrybucji. Niestety,
nie jest oczywiste jak to cudo używać. Dokumentacja zakłada za dużo
uprzedniej wiedzy. Już z nimi rozmawiałem aby dodali więcej dokumentacji
dla nowych osób, a nie dla starych wyjadaczy, któzy znają już Myghty.
Podobno to teraz dla nich najważniejsza sprawa.
Podsumowując: jest lepiej, ale wciąż nie ma krystalicznie czystej sytuacji
dla Pythona. Co byś nie wybrał, musisz mieć świadomość istnienia
potencjalnych problemów.
Badziu
jeszcze od jego projektu pythonweb.org dla cgi (juz nie rozwijanym).
Prosil o pomoc przy tworzeniu prostych przykladów uzycia pylonsa.
Sam napisalem (pod adresem:
http://pylonshq.com/project/pylonshq/wiki/AdamsNotes ) prosty przyklad
uzycia AJAX'a.
Chcialbym teraz w ramach przykladu zminimalizowac kod przy uzyciu
WebHelpera ale mam troche problemy ze zrozumieniem generowania linków
przez Routes'a.
Wydaje mi sie ze warto zainwestowac troche sil w Pylons'a - moze
on sam jako projekt jest dopiero w wersji 0.8 ale opiera sie na myghty
który jest stabilnym projektem (bazujacym na Masonie -którego uzywa
Amazon i nie tylko). Czerpie tez duzo z Railsa co chyba jest pozytywnym
kierunkiem rozwoju...
Gdyby ktos chcial wspomóc mnie z przykladami... - mozna by je
rozwijac jednoczesnie po angielsku i po polsku.
Jeszcze jedna mysl która mi wpadla do glowy - sila dobrego
frameworka jest tez spolecznosci która go wspiera...
Jaroslaw Zabiello
> http://pylonshq.com/project/pylonshq/wiki/AdamsNotes ) prosty przyklad
> uzycia AJAX'a.
> Chcialbym teraz w ramach przykladu zminimalizowac kod przy uzyciu
> WebHelpera ale mam troche problemy ze zrozumieniem generowania linków
> przez Routes'a.
Czytałeś
http://www.pylonshq.com/WebHelpers/module-webhelpers.rails.urls.html ? W
Pylons różnica jest taka że musisz użyć prefiksa h (o tej zmiennej jest
mowa w http://www.pylonshq.com/docs/0.8/getting_started.html)
Może mały przykład. Pylons (podobnie jak RoR) zakłada że używasz modelu
MVC. Może po kolei od podstaw. Załóżmy że na dysku h pod win32 chcę użyć
pylons. Tworze projekt, kontroler i odpalam serwer.
cd h:\pylons
rem tworze projekt
paster create --template=pylons myproject
cd h:\pylons\myproject
rem tworze kontroler
paster controller tescik
rem odpalam serwerek na porcie 5000 (domyslnie)
paster serve --reload development.ini
Edytuje plik kontrolera
H:\pylons\myproject\myproject\controllers\tescik.py
Niech będzie w srodku cos prostego:
from myproject.lib.base import *
class TescikController(BaseController):
def index(self):
# zmienne do szablonu przekazuje przez zmienna c
c.name = 'Jarek'
# renderuje i wyswietlam komponent:
m.subexec('/easy.myt')
def hello(self):
# tu wyswietlam bezposrednio na ekran, bez szablonu
m.write('wlazlem do hello')
Teraz tworzymy komponent:
H:\pylons\myproject\myproject\components\easy.myt
Czesc <% c.name %>,
kliknij <a href="/test/hello">tutaj</a>.
Wchodzimy na http://localhost:5000/tescik
Klikniecie na http://localhost:5000/tescik/hello
wyswietli "wlazlem do hello"
OK, teraz bez linka, uzyjemy helpera. Nasz szablon wygladac
bedzie teraz nastepujaco:
Czesc <% c.name %>,
kliknij <% h.link_to("tutaj", h.url(action="hello")) %>.
Efekt bedzie identyczny. Roznica taka, ze jak zmienimy sposob rozwiazywania
url, to wszystkie nasze linki sie automatycznie poprawia. Dokladnie to, co
jest w Ruby on Rails. Pylons ma zaimplementowane wiekszosc helperow RoR.
Mamy za to szybkosc i skladnie Pythona :)
Napisze niedlugo w blogu jaki artykul wprowadzajacy do Pylons (opisze to,
co juz wiem jak uzywac).
Taki Jeden
> jest obsługiwane (sic!). Gdy zwróciłem im uwagę, że to bujda, bo to już
> nie jest wspierane, i że ktoś powinien poprawić informację, to Remi to mi
> odpisał abym sobie sam zmieniał w wiki. Takie to podejście developerów
No i co? Miał rację - po to właśnie jest wiki. Jak widzisz że informacja
jest nieaktualna to możesz ją uaktualnić, a nie jak kapryśny klient
narzekać "niech ktoś to zrobi"...
Bartek
--
<aisi^> budzi sie we mnie zwierze
<aisi^> ale to niestety prawdopodobnie leniwiec
(http://bash.org.pl)
Marcin Stępnicki
> Wlasciwie o zadnej z aplikacji nie mam wiekszego pojecia bo ciagle ktos
> mi mowi ze nie oplaca sie uzywac X bo 'costam'. Wiec odkladam X i
> probuje innej aplikacji.
Ja tylko dodam że gdybym słuchał wszystkich takich głosów, to nie
używałbym Eclipse, Ubuntu, PostgreSQL, Pythona, Oracle XE, SQLObject i
wielu innych rzeczy. A jakoś używam i sobie chwalę :).
Zacznij używać tego co Tobie się spodoba i przestań gdy napotkasz wady
które Tobie wydadzą się istotne. Idealnego softu nie ma i nie będzie.
--
I find it kind of funny and I find it kind of sad | http://apcoln.linuxpl.org
The dreams in which I'm dying are the best I've | http://biznes.linux.pl
ever had |---------------------------------------| http://www.juanperon.info
| JID: Aragor...@jabber.org | http://www.naszedzieci.org
Husio
Marcin Stępnicki napisał(a):
> Ja tylko dodam że gdybym słuchał wszystkich takich głosów, to nie
> używałbym Eclipse, Ubuntu, PostgreSQL, Pythona, Oracle XE, SQLObject i
> wielu innych rzeczy. A jakoś używam i sobie chwalę :).
>
> Zacznij używać tego co Tobie się spodoba i przestań gdy napotkasz wady
> które Tobie wydadzą się istotne. Idealnego softu nie ma i nie będzie.
Tak byloby najlatwiej. Jednak nie mam jeszcze dostatecznie duzego
doswiadczenia aby moc osobiscie ocenic co warte jest uzywania. Obecnie
podoba mi sie wszystko na tyle proste ze rozumiem jak dokladnie dziala.
Tyle ze nie tedy chyba droga.
Najpierw musze zdobyc troche doswiadczenia zeby mog ocenic co jest
warte uzywania. (odpowiedniej dystrybucji szukalem prawie 2 lata ;) )
Grzegorz Makarewicz
> Marcin Stępnicki napisał:
> Najpierw musze zdobyc troche doswiadczenia zeby mog ocenic co jest
> warte uzywania. (odpowiedniej dystrybucji szukalem prawie 2 lata ;) )
>
Ja tez :) - po latach na redhacie przezucilem sie na debiana - ale te
frameworki :( co i rusz cos ciekawszego i daje mozliwosci niespotykanie
gdzie indziej - ror :), moze jednak cos w pythonie ?
Wasze zdanie o:
zope jako bazie ?
jak to rozszerzyc i utrzymac sie na powierzchni przez rok ?
plone ?
djnago ?
medusa ?
BTW jakis tam sklep uklecilem w php, ale to nie to :(
mak
Pigletto
obecnie zająć się Zope serii 3.x :)
Zope jest dość dobrze dopracowany, ma sporą i
pomocną społeczność a zmiany w kolejnych wersjach
nie są nagle i niespodziewane. W tej chwili jest
na przykład tzw. ścieżka migracyjna z Zope2.x na
Zope3.x i z własnego doświadczenia mogę powiedzieć
że się to sprawdza (programiści cherryPy chyba
mogą o takim czymś tylko pomarzyć).
Wchodząc w tworzenie aplikacji w Zope3 nie muszę
się martwić, że projekt ten umrze, ktoś coś
wywróci do góry nogami i wszystko przestanie działać.
Jakoś nie mam takiego zaufania do wymienianych
wcześniej frameworków, które na tle Zope wydają
się często dopiero raczkować. Nie mówię oczywiście że
Django, Myghty itd są złe, natomiast wspomniany
przykład serwisu Muratora wskazuje iż trzeba bardzo
uważać by nie wdepnąć na 'minę'. Jeśli chodzi o
Zope3 to takich obaw raczej nie mam. Może to wynika
z tego że mam doświadczenia z Zope 2.x a
może to też kwestia skali, ale w mojej firmie
jak już wybierze się technologię to raczej na lata,
natomiast jak ktoś robi drobne projekty to może
troche bardziej eksperymentować.
Problemem w Zope 3 jest niestety dokumentacja.
Najlepsze chyba materiały do nauki tworzenia aplikacji
w Z3 to ksiązki Stephana Richtera i Phillipa von
Weiterhausena, z czego tylko pierwsza jest dostępna
jako pdf, a druga jako papierowa. Tego niestety tygrysy
nie lubią najbardziej... ;) Trochę brakuje dobrych
tutoriali i materiałów do szybkiego startu na stronach
Zope. Ogólnie strony te nie zachęcają raczej do zabrania
sie za Zope :/ Generalnie trzeba trochę pogooglać.
Poza tym jednak warto. Opinie osób które
już pisały konkretne aplikacje w Zope 3 są bardzo dobre.
Ja mam na razie tylko trochę doświadczenia z Five ale
muszę powiedzieć że jest to zdecydowany krok w przód w
stosunku do Zope 2.
Na naszej grupie jest trochę osób piszących w Zope
lecz raczej mało się udzielają i moze wygląda że to
niszowa technologia, jednak zapewniam że tak nie jest :D
--
Pigletto
eXt
> Wasze zdanie o:
> zope jako bazie ?
Rozumiem, że masz na myśli bazę do tworzenia aplikacji webowych, a nie zodb.
W tym sensie IMHO solidniejszej i dojrzalszej od Zope bazy, opartej o
Pythona, nie znajdziesz.
> jak to rozszerzyc i utrzymac sie na powierzchni przez rok ?
Hę?
> plone ?
Plone to w pewnym sensie nakładka na Zope serii 2. Popularny, rozbudowany
oferujący duże możliwości. Obecnie konkuruje z nim, również oparty na Zope,
CPS.
> djnago ?
Ponoć super hiper wspaniały bo podobny do ROR... ;)) Jak potrzebujesz zrobić
coś mniejszego to pewnie warto spojrzeć właśnie na Django lub na Pylons.
Miej jednak na uwadze, że żaden z nich nie doczekał się jeszcze wersji 1.0.
> medusa ?
Medusa wykorzystywana jest w Zope jako ale w nowszych wersjach Zope'a na jej
miejsce wchodzi Twisted. Ale gdzies czytałem że jak ją trochę usprawnią to
będzie pythonowym odpowiednikiem J2EE i .NET :)
> BTW jakis tam sklep uklecilem w php, ale to nie to :(
hmm.. no cóż.. pe(c)hap ;)
Pozdrawiam
--
eXt
Riklaunim
mi się bardzo spodobał myghty, cherrypy też jest
dobry-łatwy lecz gorzej w nim z szablonami - przeplataniem html z
pythonem :) Zope/plone to cholernie duży projekt, rzadko kiedy
potrzebne są aż tak zaawansowane rozwiązania.
--
Riklaunim
'Biblioteka CMS - RkCMF & CMSy + PHP' (http://www.cms.rk.edu.pl) |
'Biblioteka Linuxa' (http://www.linuks.rk.edu.pl) | 'Biblioteka cRPG'
(http://www.crpg.rk.edu.pl)
------------------------------------------------------------------------
Riklaunim's Profile: http://forum.hotscripts.pl/member.php?userid=307
View this thread: http://forum.hotscripts.pl/showthread.php?t=12964
Jaroslaw Zabiello
> Na naszej grupie jest trochę osób piszących w Zope lecz raczej mało się
> udzielają i moze wygląda że to niszowa technologia, jednak zapewniam że
> tak nie jest :D
Ja bardzo chętnie bym poczytał sobie jakieś sensowne wprowadzenie do Zope3.
To, co jest dostępne, to jakiś koszmar. Kilka razy próbowałem się przemóc,
ale nie starczyło mi nigdy samozaparcia aby oodgadnąć jak używać Zope3. No
bo z dokumentacji to niewiele wynika.
Większość tych innych frameworków nie wzięła się z kapelusza. Powstała na
bazie zniechęcenia do Zope2, wolnego, z bałaganiarskim API, słabą
dokumentacją i żrącego pamięć jak smok.
Może Zope3 jest dużo lepsze od Zope2, ale bez dobrej, czytelnej
dokumentacji wypełnionej przykładami, raczej nie będzie specjalnie
atrakcyjniejsze od Django (nie mówiąc o Ruby on Rails, który tą kwestię ma
po prostu wzorcowo przygotowaną).
Jestem ciekaw jak Zope3 ma się wydajnościowo do Zope2. Nie chodzi tylko o
szybkość, ale także o ilość pożeranego RAM'u. I jak to się ma np. do
Django? BTW, to nie wiem dlaczego Django promuje mod_pythona zamiast
fastcgi. Ta pierwsza opcja przecież znacznie bardziej zżera pamięć.
Pigletto
> To, co jest dostępne, to jakiś koszmar. Kilka razy próbowałem się przemóc,
> ale nie starczyło mi nigdy samozaparcia aby oodgadnąć jak używać Zope3. No
> bo z dokumentacji to niewiele wynika.
Richtera w pdf i np. Benji York quick start.
> Większość tych innych frameworków nie wzięła się z kapelusza. Powstała na
> bazie zniechęcenia do Zope2, wolnego, z bałaganiarskim API, słabą
> dokumentacją i żrącego pamięć jak smok.
Roztaczasz apokaliptyczną wizję ;) Nie wiem czemu powstały inne
frameworki, ale Zope 2 wcale taki zły nie jest. Dokumentacja
nie jest słaba, tylko trzeba wiedzieć gdzie ją znaleźć, jest dużo pdfów.
Przecież jest nawet wbudowany system helpa. Zawsze są też listy
dyskusyjne, zapewniam że pomocne, oraz, bo w końcu to python, źródła Zope.
Bałaganiarskie API, to może tak, ale Zope3 to porządkuje. Ma nawet
wbudowane mechanizmy introspekcji. Czy Zope2 jest
wolny i żre pamięć jak smok? Jeśli chodzi o wydajność i pożeranie
pamięci to może nie dorównuje 'lekkim' frameworkom, ale jeśli
porównać z taką np. javą na której pracuje większość komercyjnych
portali to jego wymagania są znikome, o czym ostatnio sami przekonaliśmy
się w mojej firmie. Dodaj do tego wbudowane mechanizmy pozwalające na
klastrowanie, cacheowanie itd. Przy odpowiednim tuningu można sporo z
tego wycisnąć. Jak zachowają sie małe frameworki przy dużym obciążeniu,
czy będziesz mógł to łatwo klastrować i rozkładać obciążenie?
> Może Zope3 jest dużo lepsze od Zope2, ale bez dobrej, czytelnej
> dokumentacji wypełnionej przykładami, raczej nie będzie specjalnie
> atrakcyjniejsze od Django (nie mówiąc o Ruby on Rails, który tą kwestię ma
> po prostu wzorcowo przygotowaną).
Tu się jak najbardziej zgadzam, ale powiem Ci ze ludzie od Zope też to
zauważyli i jest nadzieja na zmianę.
> Jestem ciekaw jak Zope3 ma się wydajnościowo do Zope2. Nie chodzi tylko o
> szybkość, ale także o ilość pożeranego RAM'u. I jak to się ma np. do
> Django? BTW, to nie wiem dlaczego Django promuje mod_pythona zamiast
> fastcgi. Ta pierwsza opcja przecież znacznie bardziej zżera pamięć.
Dlaczego tak uparłeś się na tą pamieć? Prawda jest taka że pamięć jest
tania, dokupienie paru giga to tak naprawdę żaden koszt w komercyjnym
projekcie. Zamiast rezygnować z dobrego rozwiązania lepiej i łatwiej
dokupic kostkę ramu czy dwie. Mieliśmy odpalonego zope 2 i baze danych
na stacji roboczej przy której siedzial facet i normalnie pracował,
poczta, przegladarki, serwer ftp itd. Wtedy faktycznie przy 512 MB
pamieci maszyna niekiedy swapowała, ale już przy 1 GB różnica była
kolosalna. Czasy gdy liczył się każdy bajt to już na szczęście przeszłość :)
--
Pigletto
Jaroslaw Zabiello
> Chyba najlepsza jest ksiazka Richtera w pdf i np. Benji York quick start.
Jeśli masz na myśli "The Zope 3 Developers Book" ze strony
http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/FrontPage/Zope3Book
to mnie się ona nie podoba. Nie tylko ja uważam, że jest kiepsko napisana.
Trudno z niej się nauczyć Zope3. Opisuje jakieś szczątkowe informacje,
brakuje przykładów. Wygląda ładnie na wydruku ale czyta się słabo.
W ogole to mnie bardzo dziwi, ze na oficjalnej stronie domowej w sekcji
ksiazek jest cala masa starych ksiazek do Pythona a nic nie pisza ze sa
dostepne: Michel Pelletier , "Zope 3: Building Dynamic Web Sites" i Philipp
von Weitershausen, "Web Component Development with Zope: v. 3"
Nie znam ich. Czy te książki są warte uwagi? Bo jeśli są gorsze od ksiązki
Richtera, to jest kicha.
>> Większość tych innych frameworków nie wzięła się z kapelusza. Powstała na
>> bazie zniechęcenia do Zope2, wolnego, z bałaganiarskim API, słabą
>> dokumentacją i żrącego pamięć jak smok.
> Roztaczasz apokaliptyczną wizję ;) Nie wiem czemu powstały inne
> frameworki, ale Zope 2 wcale taki zły nie jest.
Ma jednak sporo wad. Znasz na pewno: http://zope-is-evil-666.idyll.org/,
http://www.amk.ca/python/writing/why-not-zope.html,
http://pywx.idyll.org/advocacy/why-not-zope.html. Np. Skunkweb jawnie to w
FAQ podaje jako powód stworzenia oddzielnego frameworku
(http://skunkweb.org/FAQ.html#sec2)
> Dokumentacja nie jest słaba, tylko trzeba wiedzieć gdzie ją znaleźć, jest
> dużo pdfów.
I o to chodzi. Trudno coś znaleźć. Wszystko jest chaotycznie porozrzucane.
To jest bvardzo frustrujące.
> Zawsze są też listy dyskusyjne, zapewniam że pomocne, oraz, bo w końcu to
> python, źródła Zope.
Co jak co, ale grzebać w źrodłach takiej kobyły jako Zope to ja bym nie
chciał. Za wielkie to. Bez dogłebnej znajomości Zope to jest bez sensu.
Zope był zawsze krytykowany za swoją własną logikę pracy która jest
kompatybilna z nią samą. Co z tego, że znasz Pythona? Jak nie znasz Zope to
ci to niewiele pomoże.
> Bałaganiarskie API, to może tak, ale Zope3 to porządkuje. Ma nawet
> wbudowane mechanizmy introspekcji.
Tak, doceniam to. Brakuje mi tylko lepszych tutoriali.
> Dodaj do tego wbudowane mechanizmy pozwalające na klastrowanie,
> cacheowanie itd. Przy odpowiednim tuningu można sporo z tego wycisnąć.
> Jak zachowają sie małe frameworki przy dużym obciążeniu, czy będziesz
> mógł to łatwo klastrować i rozkładać obciążenie?
Założę się, że są zacznie szybsze. Jaką stronę Zope bym nie oglądał, to
czas reakcji jest znacznie dłuższy. Zope nie pracuje wieloforkowo z powodu
GIL, więc nie wykorzystuje w pełni mocy maszyn wieloprocesorowych ani
proceserów dwurdzeniowych. Zaś przykładowo, Pylons/Myghty można (dzięki
WSGI) używać nie tylko wielowątkowo, ale także mieloforkowo (wykorzystując
wszystkie procesory na serwerze) albo można użyć modułu fastcgi do
Lighttpd. Memcache daje współdzielony między maszynami, wspólny cache. Zaś
Lighttpd (nowy Apache2 też) ma wbudowany szybki load balancing.
Zaletą Zope jest kompleksowość, komponenty. Wydajność nie jest jego mocną
stroną. Tzn. trzeba niewspółmiernie dużo sprzętu (koszta) aby uzyskać
podobną wydajność co te lekkie frameworki. Zope jest po prostu bardziej
złożony, więc to mnie nie dziwi.
> Dlaczego tak uparłeś się na tą pamieć? Prawda jest taka że pamięć jest
> tania,
O ile nie masz wlasnego serwera i alokacji to pamiec jest droga. Zreszta
pamiec do serwerow tez nie jest tania. Zope praktycznie wymaga, jesli nie
dedykowanego serwera, to chociaz VPS. Ceny hostingu sa drogie, i najdrozsza
jest tam pamiec.
Moze ja pisze o innej skali, bo oczywiscie, dla duzej firmy to nie bedzie
problem. Dla jednak mniejszych projektow, nie mowiac o projektach
niekomercyjnych, to jest powazny problem.
> Czasy gdy liczył się każdy bajt to już na szczęście przeszłość :)
Dla desktopu ale nie dla serwera. Zobacz ile zabulisz za VPS z 2GB pamięci.
Postawiłbyś na tym jakiś niekomercyjny projekt? Wątpię.
Dariusz Sznajder
> Dlaczego tak uparłeś się na tą pamieć? Prawda jest taka że pamięć jest
> tania, dokupienie paru giga to tak naprawdę żaden koszt w komercyjnym
> projekcie. Zamiast rezygnować z dobrego rozwiązania lepiej i łatwiej
To zależy ile było wcześniej ;)
Bo 4GB kostki (a i zapewne płyty, które je obsługują) to raczej tanie
nie są nadal... :>
--
Dariusz Sznajder
DSZ1-RIPE
eXt
> Jeśli masz na myśli "The Zope 3 Developers Book" ze strony
>
http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/FrontPage/Zope3Book
> to mnie się ona nie podoba. Nie tylko ja uważam, że jest kiepsko napisana.
> Trudno z niej się nauczyć Zope3. Opisuje jakieś szczątkowe informacje,
> brakuje przykładów. Wygląda ładnie na wydruku ale czyta się słabo.
Generalna opinia jest taka, że na początek lepiej jest przeczytać książkę
von Weitershausena (ciekawostka - koleś jest z rocznika 83!), a potem
książkę Richtera, jako adresowaną do bardziej zaawansowanych. Jest to pewne
wyjaśnienie do tego dlaczego źle Ci się ją czyta. Dodam jeszcze, że Stephen
mówił iż wersja do druku zawiera trochę zmian w stosunku do wersji on-line,
niestety nie robiłem analizy tego co jest inaczej. Zresztą ja miałem
podobne odczucia do Twoich, dlatego wziąłem na pierwszy ogień książkę
Philippa.
> W ogole to mnie bardzo dziwi, ze na oficjalnej stronie domowej w sekcji
> ksiazek jest cala masa starych ksiazek do Pythona a nic nie pisza ze sa
> dostepne: Michel Pelletier , "Zope 3: Building Dynamic Web Sites" i
> Philipp von Weitershausen, "Web Component Development with Zope: v. 3"
Fakt, acz Zopiści zdają sobie z tego sprawę, jak również z problemu
dotyczącego treści zamieszczonych na całym zope.org (gdzie tam jest
informacja o Zope 3?). Nie monitorowałem tego tematu, ale mam nadzieję, że
wkrótce ktoś się podejmie zmiany tego stanu rzeczy.
> Nie znam ich. Czy te książki są warte uwagi? Bo jeśli są gorsze od ksiązki
> Richtera, to jest kicha.
Pelletiera nie widziałem, von Weitershausena za to czyta się bardzo dobrze.
Książka podzielona jest na sekcje Beginner, Intermediate i Expert i
łagodnie dawkuje materiał. Są też krótkie wstawki dla osób znających Zope 2
obrazujące różnice pomiędzy nim a Z3. Nadto na swojej stronie Philipp
zamieścił stale aktualizowaną erratę, będącą odpowiedzią na uwagi i
problemy zgłaszane przez czytelników. IMO książkę Philippa zdecydowanie
warto przeczytać.
> Ma jednak sporo wad. Znasz na pewno: http://zope-is-evil-666.idyll.org/,
> http://www.amk.ca/python/writing/why-not-zope.html,
> http://pywx.idyll.org/advocacy/why-not-zope.html. Np. Skunkweb jawnie to w
> FAQ podaje jako powód stworzenia oddzielnego frameworku
> (http://skunkweb.org/FAQ.html#sec2)
Fajnie to przeczytać i uświadomić sobie jak daleką drogę przebył Zope od
tamtego czasu. W dniu dzisiejszym sprawy mają się nieco inaczej.
> Co jak co, ale grzebać w źrodłach takiej kobyły jako Zope to ja bym nie
> chciał. Za wielkie to. Bez dogłebnej znajomości Zope to jest bez sensu.
Pytanie po co w nich będziesz grzebał. Jeśli w celu zrozumienia działania
Zope jako całości to masz rację - nie ma to sensu, bo od tego są chociażby
wyminione wcześniej książki. Jeśli natomiast po to by dowiedzieć się czegoś
na temat poszczególnych modułów to jest to, bardzo pomocne. Nie chodzi mu
to nawet o analizowanie kodu, ale zobacz na przykład doctesty w Z3.
> Zope był zawsze krytykowany za swoją własną logikę pracy która jest
> kompatybilna z nią samą. Co z tego, że znasz Pythona? Jak nie znasz Zope
> to ci to niewiele pomoże.
Dlatego powstał Zope 3. Pisze o tym sam Jim Fulton:
http://www.zopemag.com/Issue010/Section_Articles/article_WhyZope3.html
> O ile nie masz wlasnego serwera i alokacji to pamiec jest droga. Zreszta
> pamiec do serwerow tez nie jest tania.
W stosunku do ceny innych elementów serwera pamięć nie jest droga.
> Moze ja pisze o innej skali, bo oczywiscie, dla duzej firmy to nie bedzie
> problem. Dla jednak mniejszych projektow, nie mowiac o projektach
> niekomercyjnych, to jest powazny problem.
Są projekty i projekty, może w Twoich faktycznie lepiej używać czegoś
lżejszego, w moich jednak wybieram Zope.
>> Czasy gdy liczył się każdy bajt to już na szczęście przeszłość :)
>
> Dla desktopu ale nie dla serwera. Zobacz ile zabulisz za VPS z 2GB
> pamięci. Postawiłbyś na tym jakiś niekomercyjny projekt? Wątpię.
A postawiłbyś komercyjny?
--
eXt
Pigletto
> Nie tylko ja uważam, że jest kiepsko napisana.
> Trudno z niej się nauczyć Zope3. Opisuje jakieś szczątkowe informacje,
> brakuje przykładów. Wygląda ładnie na wydruku ale czyta się słabo.
piszesz, ale może to kwestia tego że znam już Zope2.
Polecam jeszcze Definitive guide to Plone. Bardzo dobrze napisane, od
podstaw. Dla tych którzy nie wiedzą, Plone to CMS oparty na Zope serii
2.x. Jak mi się wydaje, już niedługo będzie też działał na Z3 więc myślę
że warto o nim poczytać. Społeczność Plone ma lepszy marketing, a więc i
dokumentacje niż Zope.
Poza tym wejscie obecnie w Zope serii 2.x to też nie jest taki zły
pomysł. Zope 2.x zmierza małymi kroczkami w stronę Zope3 i jest ciągle
rozwijany, właśnie w tym kierunku. Startujac od Zope 2.x można
skorzystać z dorobku Z2 jak chocby z wspomnianego Plone. Warto tylko
mieć na uwadze produkt Five który wprowadza do Zope2 elementy z Zope3.
Na stronach plone.org jest też bardzo fajny tutorial do Five w Plone.
> Ma jednak sporo wad. (...) Np. Skunkweb jawnie to w
> FAQ podaje jako powód stworzenia oddzielnego frameworku
> (http://skunkweb.org/FAQ.html#sec2)
Wygrzebałeś jakiegos trupa... ;) Ta strona opisuje chyba stan sprzed 5
lat.
Większość wymienionych na tej stronie rzeczy to w chwili obecnej po
prostu śmiech na sali i proponuję nie podawać więcej tego linku bo to
wprowadzanie ludzi w błąd.
Zrobił się chyba OT wiec już bez wdawania się w dyskusję podsumuję to co
pisałem.
Serwer Zope jest sprawdzony, używany w różnych, małych i dużych,
komercyjnych i niekomercyjnych projektach także w Polsce. Warto
popatrzyć na referencje jakie ma Zope. Swoim postem chciałem zwrócić
uwagę że na pewno nie warto go skreślać z powodu tego że na tej akurat
liście jest bardzo głośno o Pylonsach, cherrypy, django itd itp, a o
Zope nie :) Zope przecież nie stoi w miejscu i też sie rozwija w dodatku
bardzo dynamicznie.
--
Pigletto
Jaroslaw Zabiello
> Polecam jeszcze Definitive guide to Plone.
Mam. Nawet kupiłem. Dobra książka. Jest nawet dostępna w pełnej wersji
online. http://docs.neuroinf.de/. Jest też "Plone Live"
http://www.sourcebeat.com/TitleAction.do?id=11, ale nie wiem czy warto
kupować.
> Jak mi się wydaje, już niedługo będzie też działał na Z3 więc myślę
> że warto o nim poczytać. Społeczność Plone ma lepszy marketing, a więc i
> dokumentacje niż Zope.
Nie mogę się doczekac, kiedy Plone wyjdzie na Zope3. Chociaż z drugiej
strony rośnie mu konkurencja, cms pisany od podstaw w Zope3: Z3ECM
http://www.z3lab.org/ Choć na razie chyba do niczego to się nie nadaje.
Wygląda na to że ten projekt jeszcze jest wstanie embrionalnym. Mam w
planach wkrótce postawić jakiś CMS i chyba zrobię to w Plone. Za mało czuję
Zope3 aby coś zbliżonego do CMS w nim napisać.
> Serwer Zope jest sprawdzony, używany w różnych, małych i dużych,
> komercyjnych i niekomercyjnych projektach także w Polsce. Warto
> popatrzyć na referencje jakie ma Zope. Swoim postem chciałem zwrócić
> uwagę że na pewno nie warto go skreślać z powodu tego że na tej akurat
> liście jest bardzo głośno o Pylonsach, cherrypy, django itd itp, a o
> Zope nie :) Zope przecież nie stoi w miejscu i też sie rozwija w dodatku
> bardzo dynamicznie.
To wszystko prawda. Ja nie skreślam nawet starego Zope2. Znam jego zalety
(sam używam od dawna Plone). Cały czas uważam, że Zope3 może przyćmić
wszystkie pozostałe frameworki w większych zastosowaniach o ile tylko
będzie w końcu więcej darmowej, dobrej dokumentacji. Jednakże w małych i
średnich projektach, to Zope jest za ciężki i za trudny. Tu widzę miejsce
dla Pylons czy Django. Szybkie do opanowania i szybkie w działaniu.
Jaroslaw Zabiello
> Pelletiera nie widziałem, von Weitershausena za to czyta się bardzo dobrze.
> Książka podzielona jest na sekcje Beginner, Intermediate i Expert i
> łagodnie dawkuje materiał. Są też krótkie wstawki dla osób znających Zope 2
> obrazujące różnice pomiędzy nim a Z3. Nadto na swojej stronie Philipp
> zamieścił stale aktualizowaną erratę, będącą odpowiedzią na uwagi i
> problemy zgłaszane przez czytelników. IMO książkę Philippa zdecydowanie
> warto przeczytać.
Skoro tak mówisz, to chyba ją kupię.
>> Co jak co, ale grzebać w źrodłach takiej kobyły jako Zope to ja bym nie
>> chciał. Za wielkie to.
>
> Pytanie po co w nich będziesz grzebał.
No boś napisał, że jak mi brakuje dokumentacji, to mogę sobie zaglądać do
źródeł.
> A postawiłbyś komercyjny?
Myślę, że dopóki nie przekonam się, iż w Zope3 mogę coś zrobić szybciej i
lepiej, to tak.
Jaroslaw Zabiello
> Dodam jeszcze, że Stephen mówił iż wersja do druku zawiera trochę zmian w
> stosunku do wersji on-line, niestety nie robiłem analizy tego co jest
> inaczej.
Ale ogólnie, o co chodzi? Która wersja jest lepsza? Ta na www, to starsza
czy nowsza wersja w stos. do papierowej?
eXt
> Ale ogólnie, o co chodzi? Która wersja jest lepsza? Ta na www, to starsza
> czy nowsza wersja w stos. do papierowej?
Wersja papierowa jest bardziej aktualna.
--
eXt
eXt
>> Pytanie po co w nich będziesz grzebał.
>
> No boś napisał, że jak mi brakuje dokumentacji, to mogę sobie zaglądać do
> źródeł.
To nie ja napisałem, ja się tylko podłączyłem do wątku :)
--
eXt
eXt
> To wszystko prawda. Ja nie skreślam nawet starego Zope2. Znam jego zalety
> (sam używam od dawna Plone). Cały czas uważam, że Zope3 może przyćmić
> wszystkie pozostałe frameworki w większych zastosowaniach o ile tylko
> będzie w końcu więcej darmowej, dobrej dokumentacji. Jednakże w małych i
Odnośnie dostępu do dokumentacji i w ogóle marketingu zope to sprawdziłem
jak się sprawy mają. Zerknij na work in progress:
http://www.modscape.com/zope/v3 (więcej info na mailing liście zope-web).
--
eXt