Сайт на python
От: Mikhail Polykovsky Россия http://glader.ru
Дата: 16.01.07 15:18
Оценка:
Здравствуйте.
Меня попросили сделать сайт, и одновременно я взялся изучать python. Функциональность требуется примерно как у http://www.dive.ru/, слегка попроще.
В фреймворках питона я пока не разбираюсь, поэтому требуется совет опытных, как за это взяться
1) Django
2) Zope
3) другое
4) без фреймворка, руками.

(В веб-разработке разбираюсь, знаю perl.)
Re: Сайт на python
От: Alex Kirhenshtein Латвия http://www.netxms.org
Дата: 16.01.07 15:54
Оценка: 2 (1)
Здравствуйте, Mikhail Polykovsky, Вы писали:

MP>В фреймворках питона я пока не разбираюсь, поэтому требуется совет опытных, как за это взяться


Django. Только вначале надо прочитать их http://www.djangobook.com/ для понимания идеи.
NetXMS: Open Source Network monitoring solution
Re[2]: Сайт на python
От: Mikhail Polykovsky Россия http://glader.ru
Дата: 16.01.07 16:33
Оценка:
MP>>В фреймворках питона я пока не разбираюсь, поэтому требуется совет опытных, как за это взяться

AK>Django. Только вначале надо прочитать их http://www.djangobook.com/ для понимания идеи.


Спасибо. Какие-нибудь аргументы приведешь? Или просто нравится?
Re[3]: Сайт на python
От: Alex Kirhenshtein Латвия http://www.netxms.org
Дата: 16.01.07 16:43
Оценка:
Здравствуйте, Mikhail Polykovsky, Вы писали:

MP>Спасибо. Какие-нибудь аргументы приведешь? Или просто нравится?


Нравится. Особенно их идея темплейтов.
Zope — громоздкий, остальные фреймворки, которые я пробовал — неудобные (мне). Если не дьянго, я бы пожалуй остался бы на Ruby on Rails (или Java+Wicket, что вероятнее).
NetXMS: Open Source Network monitoring solution
Re: Сайт на python
От: dmz Россия  
Дата: 17.01.07 06:55
Оценка: 15 (2)
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, который, наверное, считается лучшим среди подобных.
Re[2]: Сайт на python
От: Mikhail Polykovsky Россия http://glader.ru
Дата: 17.01.07 07:07
Оценка:
MP>>В фреймворках питона я пока не разбираюсь, поэтому требуется совет опытных, как за это взяться

dmz>В общем, по моему мнению: фреймворк — это наглухо заваренный танк, у которого можно только ездить на броне.

dmz>По этой же причине в свое время отказался и от RoR, который, наверное, считается лучшим среди подобных.

Спасибо за инфу, буду думать.
Re[2]: Сайт на python
От: Mikhail Polykovsky Россия http://glader.ru
Дата: 17.01.07 07:21
Оценка:
dmz>В общем, по моему мнению: фреймворк — это наглухо заваренный танк, у которого можно только ездить на броне.
dmz>По этой же причине в свое время отказался и от RoR, который, наверное, считается лучшим среди подобных.

А как насчет быстрого старта? Правильно ли я понимаю, что в среднесрочной перспективе (год) проще сделать сайт на фреймворке, попутно изучая язык+фреймворк+прочее, чем пытаться сделать сайт самостоятельно с использованием указанных тобой компонентов?
А потом уже, на базе полученного опыта, при необходимости доработать/переписать без фреймворка.
Re[3]: Сайт на python
От: dmz Россия  
Дата: 17.01.07 13:01
Оценка:
dmz>>В общем, по моему мнению: фреймворк — это наглухо заваренный танк, у которого можно только ездить на броне.
dmz>>По этой же причине в свое время отказался и от RoR, который, наверное, считается лучшим среди подобных.

MP>А как насчет быстрого старта?


Не могу сказать. У меня было две попытки быстрого старта, на TG и Django. Быстрый старт заканчивался не менее быстрым стопом, когда выяснялось что мапить нашу схему базы на объекты при помощи SQLObject — проще застрелиться.

Третий быстрый старт произошел, когда мы попробовали перевести существующее приложение, написанное с использованием web.py на TurboGears, поверив, что они реализовали поддержку SQLAlchemy. Потеряли два дня, плюясь откатились обратно.

MP>Правильно ли я понимаю, что в среднесрочной перспективе (год) проще сделать сайт на фреймворке, попутно изучая MP>язык+фреймворк+прочее, чем пытаться сделать сайт самостоятельно с использованием указанных тобой компонентов?


Получается так, что мой опыт использования фреймворков очень ограничен. Я честно пытался их изучать, но получалось так, что "из коробки" то, что мне надо они не делали, а что бы их менять и расширять — нужно уже хорошо изучить их внутреннее устройство. Отдельные компоненты хороши тем, что реализуют какой-то маленький и хорошо выделенный функционал, ничего не навязывая — знать про них много не нужно (пока ничего не сломалось). Фреймворки же достаточно сложны внутри.

Надо более-менее трезво оценивать, что дают фреймворки, что бы понимать, чего лишаемся отказываясь от них.
Могу сразу сказать, что отказываясь от Django мы лишаемся автоматической генерации форм просмотра/редактирования сущностей базы (работает только для SQLObject), отказываясь от TurboGears мы отказываемся от коллекции html-виджетов (не особенно большой).

Я бы посоветовал потратить дня три на исследования — попробовать сделать простое приложение на Django, на TG и без них, используя отдельные компоненты — и выбрать, что понравится.

MP>А потом уже, на базе полученного опыта, при необходимости доработать/переписать без фреймворка.


Смысла особого нет. Для нас вопрос замещения функционала, который мы потеряли, отказавшись от фреймворков — это был вопрос пары дней. В основном, валидация форм, сигнализация об ошибках и заполнение форм значениями.

Впрочем, я верю, что Djano вполне пригоден для использования. Насчет TG все хуже.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.