Całkiem niedawno postanowiłem poznać ciut bliżej pylons - pewien framework Pythona. Czytałem w różnych opisach (dat nie pamiętam), że pylons nie ma dokumentacji... Rzeczywiście - pewnych rzeczy w dokumentacji oficjalnej na witrynie http://wiki.pylonshq.com/display/pylonsdocs/Home się nie doszukałem, jednak nie są to jedyne źródła informacji !
Po pierwsze pogłoski iż jakoby pylons miał kiepską dokumentacje są nie trafione. Ten framework tak silnie korzysta z zewnętrznych, tworzonych w ramach osobnych projektów rozwiązań, że gdyby przestały istnieć framework przestałby funkcjonować przynajmniej na jakiś czas. Rozwiązania te, takie jak : SQLAlchemy czy Mako - mają własną dokumentację. Obszerną, dokładną, przerzystą dokumentację. Nie ma co się dziwić ... skoro to zewnętrzne projekty to czemu miałoby być inaczej ?
Dokumentacja istnieje, jest więc tylko troszkę rozproszona, ponieważ pylons korzystając z konkretych rozwiązań pokazuje tylko coś "na start" i zaprasza do zapoznania się z dokumentacją np. SQLAlchemy w celu pogłębienia swojej wiedzy. Moim zdaniem to rozwiązanie jest rozsądne i słuszne - po co robić kopiuj wklej opracowania jakiegoś projektu z którego korzystasz jeżeli możesz po prostu do niego odesłać.
Zastanawia mnie tylko jedna rzecz. Django i Pylons, z nieznanych mi powodów, ale zapewne jakieś są, idą łeb w łeb ... gdzie jednak Django ma napisane wszystko "od siebie" a Pylons sam napisał może 2% tego co djangowcy bo przecież 98% to zewnętrzne rozwiązania z naklejką "ready to go !". Logicznie myśląc skoro pylons i tak "wykorzystuje" cudzą pracę to mogłoby rozwijać się znacznie szybciej niż django, w którym wszystko jest implementowane po djanogowemu na potrzeby frameworka.
I jeszcze na koniec - to nie prawda, że Pylons ma słabą dokumentację. Dokumentacja jest wystarczająca - choć oczywiście mogłaby być lepsza. Dla zapaleńców polecę jeszcze tylko polski tutorial do Pylons: http://python.rk.edu.pl/w/p/pylonsindex/
I kto mówił, że Pylons ma słabą dokumentacje ?
1 comment:
Drobna uwaga na temat korzystania z zewnętrznych rozwiązań: to są projekty open source - one nie mogą przestać istnieć. W najgorszym przypadku mogą zmienić licencję za zamkniętą, co nie zlikwiduje możliwości rozwijania projektu od tego punktu przez inną grupę.
Dostosowanie pylons do nowszej wersji lub nawet wymiany biblioteki na inną, oferującą określoną funkcjonalność, mogę przeprowadzić z jednym programistą. W projektach w stylu django jest to bardziej problematyczne (sprawdzone w praktyce).
Post a Comment