Здравствуйте.
Меня попросили сделать сайт, и одновременно я взялся изучать python. Функциональность требуется примерно как у http://www.dive.ru/, слегка попроще.
В фреймворках питона я пока не разбираюсь, поэтому требуется совет опытных, как за это взяться
1) Django
2) Zope
3) другое
4) без фреймворка, руками.
MP>>В фреймворках питона я пока не разбираюсь, поэтому требуется совет опытных, как за это взяться
AK>Django. Только вначале надо прочитать их http://www.djangobook.com/ для понимания идеи.
Спасибо. Какие-нибудь аргументы приведешь? Или просто нравится?
Здравствуйте, Mikhail Polykovsky, Вы писали:
MP>Спасибо. Какие-нибудь аргументы приведешь? Или просто нравится?
Нравится. Особенно их идея темплейтов.
Zope — громоздкий, остальные фреймворки, которые я пробовал — неудобные (мне). Если не дьянго, я бы пожалуй остался бы на Ruby on Rails (или Java+Wicket, что вероятнее).
MP>В фреймворках питона я пока не разбираюсь, поэтому требуется совет опытных, как за это взяться
MP>1) Django
можно.
MP>2) Zope
нет.
MP>3) другое
Pylons, TurboGears и еще куча.
MP>4) без фреймворка, руками.
Смотрели разные фреймворки, в итоге пришли к тому — что на сложных проектах
от них одна головная боль. В питоне достаточно компонентов для поддержки веба.
Начиная c WSGI. В итоге — можно брать наиболее устраивающие компоненты, и работать
с ними, не вгоняя себя в рамки.
Основная претензия к фреймворкам — это зачаточная поддержка SQLAlchemy — лучшего на
сегодняшний день ORM для питона. Вместо этого они поддерживают SQLObject, который достаточно
убог. Поддержка SQLAlchemy заявлена и в Django и TurboGears, но она на текущий момент проблемная.
Вторая моя претензия — это вопросы к масштабированию систем, написанных на этих фреймворках.
Третья — несмотря на то, что в них декларируется легкая смена шаблонного движка — на самом деле
это все не так легко.
В итоге, если взять TG или Django, прикрутить туда устраивающий шаблонный движок и устраивающий ORM —
то что остается от самого фреймворка? Остается только головная боль У Django, например,
отваливается генерация бекендов при использовании SQLAlchemy.
Итого, для несложной системы использовать фреймворки вполне можно. Но надо учитывать риск того, что если
система начнет становиться сложной — то вы можете поиметь либо ковыряние во внутренностях фреймворка, либо
спешный переезд с него на что-нибудь другое. Мы на такие грабли один раз наступили.
При том, что отдельных компонентов для построения веб приложения хватает на любой вкус:
шаблонные движки: myghty, cheetah, kid, genshi, ...
middleware: cherrypy, colubrid, paster, web.py, ...
orm: sqlalchemy
валидация и заполнение форм: FormEncode (используется во всех фреймворках, но такая пакость при этом. плюнули, написали свое за полдня)
В общем, по моему мнению: фреймворк — это наглухо заваренный танк, у которого можно только ездить на броне.
По этой же причине в свое время отказался и от RoR, который, наверное, считается лучшим среди подобных.
MP>>В фреймворках питона я пока не разбираюсь, поэтому требуется совет опытных, как за это взяться
dmz>В общем, по моему мнению: фреймворк — это наглухо заваренный танк, у которого можно только ездить на броне. dmz>По этой же причине в свое время отказался и от RoR, который, наверное, считается лучшим среди подобных.
dmz>В общем, по моему мнению: фреймворк — это наглухо заваренный танк, у которого можно только ездить на броне. dmz>По этой же причине в свое время отказался и от RoR, который, наверное, считается лучшим среди подобных.
А как насчет быстрого старта? Правильно ли я понимаю, что в среднесрочной перспективе (год) проще сделать сайт на фреймворке, попутно изучая язык+фреймворк+прочее, чем пытаться сделать сайт самостоятельно с использованием указанных тобой компонентов?
А потом уже, на базе полученного опыта, при необходимости доработать/переписать без фреймворка.
dmz>>В общем, по моему мнению: фреймворк — это наглухо заваренный танк, у которого можно только ездить на броне. dmz>>По этой же причине в свое время отказался и от RoR, который, наверное, считается лучшим среди подобных.
MP>А как насчет быстрого старта?
Не могу сказать. У меня было две попытки быстрого старта, на TG и Django. Быстрый старт заканчивался не менее быстрым стопом, когда выяснялось что мапить нашу схему базы на объекты при помощи SQLObject — проще застрелиться.
Третий быстрый старт произошел, когда мы попробовали перевести существующее приложение, написанное с использованием web.py на TurboGears, поверив, что они реализовали поддержку SQLAlchemy. Потеряли два дня, плюясь откатились обратно.
MP>Правильно ли я понимаю, что в среднесрочной перспективе (год) проще сделать сайт на фреймворке, попутно изучая MP>язык+фреймворк+прочее, чем пытаться сделать сайт самостоятельно с использованием указанных тобой компонентов?
Получается так, что мой опыт использования фреймворков очень ограничен. Я честно пытался их изучать, но получалось так, что "из коробки" то, что мне надо они не делали, а что бы их менять и расширять — нужно уже хорошо изучить их внутреннее устройство. Отдельные компоненты хороши тем, что реализуют какой-то маленький и хорошо выделенный функционал, ничего не навязывая — знать про них много не нужно (пока ничего не сломалось). Фреймворки же достаточно сложны внутри.
Надо более-менее трезво оценивать, что дают фреймворки, что бы понимать, чего лишаемся отказываясь от них.
Могу сразу сказать, что отказываясь от Django мы лишаемся автоматической генерации форм просмотра/редактирования сущностей базы (работает только для SQLObject), отказываясь от TurboGears мы отказываемся от коллекции html-виджетов (не особенно большой).
Я бы посоветовал потратить дня три на исследования — попробовать сделать простое приложение на Django, на TG и без них, используя отдельные компоненты — и выбрать, что понравится.
MP>А потом уже, на базе полученного опыта, при необходимости доработать/переписать без фреймворка.
Смысла особого нет. Для нас вопрос замещения функционала, который мы потеряли, отказавшись от фреймворков — это был вопрос пары дней. В основном, валидация форм, сигнализация об ошибках и заполнение форм значениями.
Впрочем, я верю, что Djano вполне пригоден для использования. Насчет TG все хуже.