Комментарии 21
Код бы ещё разукрасить
+ module_name_arr = module_name.split('.')Какой-то странный Python.
+ module_name = module_name_arr[len(module_name_arr)-1]
module_name = module_name.split('.')[-1]
Вот ещё «перлы»:
1. setattr(f,'method','local')
а можно
f.method = 'local'
2. attrib = control.__dict__[item].__dict__['method']
а лучше
attrib = getattr(control, item).method
3. except: pass
а вот так лучше вообще не писать
там ещё много такого
1. setattr(f,'method','local')
а можно
f.method = 'local'
2. attrib = control.__dict__[item].__dict__['method']
а лучше
attrib = getattr(control, item).method
3. except: pass
а вот так лучше вообще не писать
там ещё много такого
Автор, заботьтесь о читателях!
Вместо:
if route_path.endswith('/'):
repeat=True
while repeat:
route_path = route_path[:-1]
repeat = route_path.endswith('/')
Напишите:
route_path = route_path.rstrip('/')
Вместо:
if route_path.endswith('/'):
repeat=True
while repeat:
route_path = route_path[:-1]
repeat = route_path.endswith('/')
Напишите:
route_path = route_path.rstrip('/')
спасибо за фикс. Поправил
Хм. А зачем разбрасывать по контроллерам пути? Скажем, если в сложной системе путей для сайта надо сменить порядок их использования?
перед нами задачи стоят другие. Нам было необходимо иметь инструмент, позволяющий быстро и без лишних движений убрать контроллер из приложения. В нашем случае простым переносом папки/файла контроллера в «другое место» мы убирали его из системы. Дальше уже лазить не надо было.
Да и когда у вас 20 контроллеров (как раз сложная система) и в каждом по 10-20 методов, связанных урлами, то далее поддержка файла routing.py становится головной болью.
Хотя у каждого по своему.
Да и когда у вас 20 контроллеров (как раз сложная система) и в каждом по 10-20 методов, связанных урлами, то далее поддержка файла routing.py становится головной болью.
Хотя у каждого по своему.
всегда можно группировать роуты по разным файлам. Ясное дело, что сорок или сто строк в диспетчере заспросов — то еще бл*тво.
а чем обуславливался выбор фреймворка? какими-то конкретными преимуществами?
а чем обуславливался выбор фреймворка? какими-то конкретными преимуществами?
выбор фрэймворка… тяжелый вопрос. По сути, доверился работнику.
Сам я писал на Perl и из Python юзал Django. Но,
Django всетаки community-like фрэймворк, и на нем в частности, если хочется сделать что-то эдакое(показываю размер жестом рыбака), то написание кода, а потом и сопровождение превращается в какое-то издевательство над собой. Когда работал ПМ-ом видел сие чудо в разных исполнениях. было страшно. Я понимаю, что на нем можно писать большие и просто огромные сайты, но это не для меня.
TurboGears, Zope, web2py и прочее как-то прошли мимо. Zope сразу оттолкнул громоздкостью. web2py — лень было изучать. TurboGears — да, легкий, да, быстрый. Но объем «багажника» разочаровал немного.
Да и сам я начал с Pylons, правда потом отказался в пользу легкого в изучении Django. Теперь вот вернулись. Вроде оптимально: плюшки, кастомные модели (на несколько серверов баз), достаточно легкие контроллеры, да и структура теперь полегче чем в Django.
Но это ИМХО. :-)
Сам я писал на Perl и из Python юзал Django. Но,
Django всетаки community-like фрэймворк, и на нем в частности, если хочется сделать что-то эдакое(показываю размер жестом рыбака), то написание кода, а потом и сопровождение превращается в какое-то издевательство над собой. Когда работал ПМ-ом видел сие чудо в разных исполнениях. было страшно. Я понимаю, что на нем можно писать большие и просто огромные сайты, но это не для меня.
TurboGears, Zope, web2py и прочее как-то прошли мимо. Zope сразу оттолкнул громоздкостью. web2py — лень было изучать. TurboGears — да, легкий, да, быстрый. Но объем «багажника» разочаровал немного.
Да и сам я начал с Pylons, правда потом отказался в пользу легкого в изучении Django. Теперь вот вернулись. Вроде оптимально: плюшки, кастомные модели (на несколько серверов баз), достаточно легкие контроллеры, да и структура теперь полегче чем в Django.
Но это ИМХО. :-)
Я питонист и из фреймов видел Zope (ну, не совсем, конечно, фреймворк); Джанго и еще один жирный корпоративный продукт. А я рядом со мной сидит совсем уж убеленный сединами питонист и джангист.
Как-то мы оба нормально относимся к мысли о больших проектах на Джанго… Я как раз недавно ковырял здоровенный портальчик, автор которого очень качественно и аккуратно использовал архитектурный подход к проектированию в стиле Явы.
Наоборот, несколько пугает мысль об использовании фреймворка, за которым не стоит здоровенное коммьюнити и множество открытого кода.
Впрочем, это ваше решение :)
Как-то мы оба нормально относимся к мысли о больших проектах на Джанго… Я как раз недавно ковырял здоровенный портальчик, автор которого очень качественно и аккуратно использовал архитектурный подход к проектированию в стиле Явы.
Наоборот, несколько пугает мысль об использовании фреймворка, за которым не стоит здоровенное коммьюнити и множество открытого кода.
Впрочем, это ваше решение :)
Community-like — это значит на нем крайне удобно делать портальчики социального направления.
Попробуйте на джанге реализовать функционал «коментарии для всего». Разница с Pylons будет большая.
PS. Величина комьюнити иногда роли не играет. Тут двояко все. Если нет комьюнити, то нет особо вопросов. Может документация лучше, а мож сам фрэймворк попроще. Мне вот больше нравятся версии Джанго за 0.9.* — там все было относительно просто.
Попробуйте на джанге реализовать функционал «коментарии для всего». Разница с Pylons будет большая.
PS. Величина комьюнити иногда роли не играет. Тут двояко все. Если нет комьюнити, то нет особо вопросов. Может документация лучше, а мож сам фрэймворк попроще. Мне вот больше нравятся версии Джанго за 0.9.* — там все было относительно просто.
как это проблемы с «комментарии для всего»? вы что? вот как раз были в том же портальчике, который уже упоминал выше,
что-то вроде тега "{{ comments_for_object object «template.html»}}".
внутри комментов — generic_relation с произвольной таблицей. Кстати говоря, комментарии ветвящиеся. Можно кеш организовать в теге, да и вообще что угодно. Это я стандартные использовал комменты с дополнением
Впрочем, я ведь согласен с вашим высказыванием насчет социальной (тут точнее «публичной») направленности. Вот, скажем, для сложных коммерческих («enterprise») проектов надо усложнить формы, сильно развить идею generic_view и включить по умолчанию генерилку рестфул типа django-piston.
что-то вроде тега "{{ comments_for_object object «template.html»}}".
внутри комментов — generic_relation с произвольной таблицей. Кстати говоря, комментарии ветвящиеся. Можно кеш организовать в теге, да и вообще что угодно. Это я стандартные использовал комменты с дополнением
Впрочем, я ведь согласен с вашим высказыванием насчет социальной (тут точнее «публичной») направленности. Вот, скажем, для сложных коммерческих («enterprise») проектов надо усложнить формы, сильно развить идею generic_view и включить по умолчанию генерилку рестфул типа django-piston.
Вообще, идея динамического создания таблицы диспетчеризации (на декораторах в питоне/атрибутах в перле/каталисте) гениальна, не понимаю почему до сих пор больше ни в одном фреймворке я этого не видел.
Код не читал, может быть он, судя по комментариям выше, и не идеален, но идея правильная и нужная.
Код не читал, может быть он, судя по комментариям выше, и не идеален, но идея правильная и нужная.
Читатели, буду благодарен за фиксы. Идея реализовывалась ночью «за 5 минут» перед дедлайном, так что любые «пинки» за некрасивый код только приветствую.
Список урлов в проекте сделать конечно не проблема при таком подходе… Но практика перемещения модуля как-то смущает.
А не проще ли было унаследовать Mapper() и хранить в настройках список имен «запрещенных» контроллеров. Ну и в своем маппере урлы на контроллеры из списка выкидывать?
А не проще ли было унаследовать Mapper() и хранить в настройках список имен «запрещенных» контроллеров. Ну и в своем маппере урлы на контроллеры из списка выкидывать?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Pylons. Альтернатива routing.py