Grok wyszedł z jaskini
- Dodano: 23 października 2009
- Wprowadził: SeeM
- Komentarze: 13
Po trzech i pół roku ciosania, łupania i gładzenia powstał pierwszy Grok „stable” – ten framework do Zope 3 został ochrzczony mianem 1.0. Początki projektu to niewielki sprint w Niemczech. Dzisiaj Grok jest najważniejszym przedsięwzięciem związanym z Zope 3, który może przyczynić się do popularyzacji, niszowego jak na razie, Zope.
Zope 3 jest bardzo zaawansowaną platformą do pisania aplikacji sieciowych, ale dość trudną do opanowania z powodu konieczności pisania XML-a, równocześnie z kodem Pythona. Grok usuwa tę niedogodność dzięki konwencjom, do których programiści muszą się stosować. Chodzi zwłaszcza o nazewnictwo podstawowych plików i klas w kodzie projektów. Pozwala to skupić się na tym, co w Zope najlepsze: szablonach stron, wbudowanej, obiektowej bazie danych oraz samym Pythonie.
Twórcy Zope są przekonani, że nie będą już wprowadzać dużych zmian do swojego produktu. Argumentują to jego dojrzałością i stabilnością, przywiązują również dużą (niektórzy twierdzą, że zbyt dużą) wagę do wstecznej kompatybilności. Siłą rzeczy rozwój Zope skupił się bardziej na zewnątrz, czyli w Plone oraz Grok.
Wersja 1.0 nie jest w tym przypadku wynikiem osiągnięcia założonych celów, przynajmniej celów większych niż dla kolejnej wersji beta. Bardziej jest to zabieg marketingowy – gdy jeden z programistów rzucił pomysł wypuszczenia wersji 1.0 na liście mailowej, reszta przyznała mu rację. W każdym razie Grok może się ostatnio pochwalić wsparciem dla Pythona 2.5, pełną integracją z pasterem podczas instalacji i aktualizacji oraz znaczącą poprawą dokumentacji w postaci „dictringów” wewnątrz kodu. Skrócona lista zmian znajduje się na stronie PyPi.
Inaczej niż w przypadku Zope 3, nie znajdziemy najnowszych źródeł na stronie projektu, gdyż Grok jest udostępniony wyłącznie poprzez PyPi i mechanizm easy_install. Proces instalacji jest opisany na stronie projektu.
Warto też dodać, że Grokowi wreszcie udało się zdetronizować w Google przepisy kulinarne i zajmuje obecnie zasłużone, pierwsze miejsce.
Więcej informacji: http://grok.zope.org/project/releases/1.0
Znalazłeś literówkę? Zgłoś ją używając formularza!
Jeśli uważasz, że ten nius jest nieobiektywny, przedstawia nieprawdziwe wydarzenie, jest spamem lub nie spełnia standardów serwisu, napisz raport.
Niusy na podobny temat:
Komentarze są prywatnymi opiniami dodających je osób. Prosimy o zachowanie kultury wypowiedzi. Komentarze obraźliwe oraz obniżające poziom serwisu będą usuwane. Więcej w regulaminie komentowania.
13 komentarzy
Wszystkie autorskie niusy w serwisie publikowane są na licencji Creative Commons Uznanie autorstwa 2.5 Polska.
"wbudowanej, obiektowej bazie danych"
Chodzi o ORM (+DBAL?) tak jak w Propelu czy Doctrine?
Nie, jasno jest napisane że *obiektowej*, a nie "relacyjnej + klasy owijające", chodzi o ZODB.
Konkurować z Django raczej mu będzie ciężko jak i całemu światkowi Zope – nie jest to programowanie "szybkie i przyjemne" – wybierane wyłącznie gdy takie a nie inne rozwiązanie jest potrzebne. Do tego geeki mają Pylonsa i inne jeszcze bardziej niszowe
Olaboga. Tak się składa, że jestem zupełnie początkujący jeśli chodzi zarówno o Pythona jak i programowanie w ogóle, a jednak Pylons wydało mi się bardzo proste, łatwe i logiczne. Skoro to jest geekowskie, to pisanie w czystym WSGI zakrawa chyba na hackerskość – o niższych poziomach abstrakcji nie wspominając
chcesz byc bardziej geekowski to mozesz jeszcze pisac bezposrednio na twisted
Mam przy okazji takie małe pytanie – czy istnieje inny pythonowy framework (nie-Zope i pochodny), który ma szablony stron zgodne z (X)HTML? Czyli robię szablon stron, który można otworzyć w przeglądarce bez posiadania zainstalowanego Zope?
TurboGears i każdy inny w którym użyjesz Genshi.
Słyszałem właśnie, że Genshi można zastosować w Zope, ale nie wiedziałem, że to jest z Gears-ów. Dzięki.
Gwoli ścisłości, samo Genshi nie ma chyba nic wspólnego z TG per se – po prostu jest tam domyślnym silnikiem szablonów. W Pylons można nim zastąpić Mako (automagiczna konfiguracja jeśli wybierzemy ten silnik przy tworzeniu aplikacji) zaś tutorial na stronie Genshi bierze na warsztat "surowe" CherryPy. Nie wiem tylko jak ma się sprawa w Django
Jest taki śmieszny framework w perlu: Jifty. Jego twórcy wszędzie starają się wprowadzić uniwersalny zapis. To znaczy, od konfiguracji, bazy danych, aż do szablonów(zupełnie niezgodne z xhtml) wszystko piszemy w taki sam sposób. Ciekawe podejście, z tym, że jeśli chodzi o szablony to implementacja pozostawia wiele do życzenia.
Ale to chyba dobre podejście. Jestem skrzywiony perlem, bo nie ma czegoś takiego jak 'konwencja', ale jeśli zerkniemy na Catalyst, to odkryjemy, że:
-pliki konfiguracyjne piszemy w yaml'u albo apachelike generalconfig,
-sql piszemy w sql:P,
-orm z DBIx::Class,
-szablony w Template Toolkit 2,
-Kontrolery z Moose…
… a i to nie koniecznie. Możemy użyć właściwie czegokolwiek. Z jednej strony: potęga i wolność. Z drugiej: chaos.
Kiedy już wybierze się i opanuje moduły które nam najbardziej odpowiadają możemy zdziałać cuda. Ale wybór wcale nie jest prosty, a poznanie 3-4+, modułów zabiera kilka dni, o perfekcyjnym ich opanowaniu nie wspominając.
Istnieje oczywiście jifty i mojo, które są zdecydowanie bardziej uporządkowane. Ale jifty stanowi właściwie dodatkową warstwę pomiędzy programistą, a kodem modułów, których używa ogromne ilości i wchodzi w drogę, kiedy chcemy zrobić coś inaczej niż powinniśmy chcieć;) Mojo nie używa żadnego niestandardowego modułu i proponuje w miarę jednolity zapis, ale brakuje mu możliwości i znów okazuje się, że kodujemy w DBIx::Class. No i wracamy do Catalysta. Cholerny perl. Dobry dla anarcho-indywidualistów z ADHD. Nie dziwię się, że ror zdobywa popularność: konwencja. Krótki czas nauki i mała ilość dylematów.
Perla nigdy nie dotknąłem, Ruby mnie odrzuca, ale jeśli chodzi o pythonowy framework Pylons to tam "konwencja" jest imo rozsądna. Szablony piszemy w wybranym silniku, natomiast reszta może być albo całkiem w Pythonie, albo niektóre elementy skonfigurowane w plikach ini. Nie ma to jak wybór
tmtowtdi
W tekście jest błąd – nie 'dictstring', tylko docstringi.