Pylons Framework

[@le0pard]

Только по тегам понял, на каком языке этот фреймворк (хоть и догадывался по названию, но указывать язык надо).

[@kerrygun]

Аналогично, прежде чем не читать (ну не входит питон (не орите на меня, я знаю, что правильно — пайтон) в круг интересов) пришлось промотать до тэгов.

Хорошо бы автору вынести Python в название.

[@zw0rk]

> основные идеи были взяты из Ruby On Rails и улучшены!

Неплохо бы раскрыть эту фразу детальней…

[@MyGodIsHe]

Цель статьи была не сравнить фреймворки. Для этого нужна отдельная статья которую планирую написать и сравню в ней Django, Pylons и RoR. На вскидку могу лишь заметить, что в Pylons нет соглашений, все указывается явно.

[@zw0rk]

Взяли и выкинули основную идеологическую концепцию рельсов и утверждаете что это улучшение? :) Странно. Я бы сказал более нейтрально: «взяли основные идеи RoR и питонифицировали».

[@MyGodIsHe]

Конечно это моё личное мнение, основанное на любви к питону :) Но вообще SQLAlchemy мне больше нравится, чем ActiveRecord. Routes тоже чуть получше(работа с поддоменами). И шаблоны тоже… вообщем долгая история :)

[@maratk]

Мне тоже кажется, что тут больше любви к питону как у меня больше к руби :)
Например, мне

User.find(:first, :conditions => {:name => «Маша'})

понятнее, чем

session.query(User).filter_by(name=u»Маша").first()

С ассоциациями то же — belongs_to и has_many это просто супер: как читается, то и означает.
Найти бы кого-то непредвзятого… :)

[@MyGodIsHe]

Ассоациации? Алхимия это сложная наука, по этому придумали Эликсир! Употребляешь и все становится проще :)

[@zw0rk]

А толку-то с непредвзятого? Это ведь субъективная штука, непредвзятый станет предвзятым, как только ознакомится с обоими подходами :).

Разве что, ему может не понравится то, что в :conditions надо писать практически raw sql.

[@maratk]

да, но в руби DataMapper тоже свой есть, тем не менее и он более удобочитаемый, чем

session.query(User).filter_by(name=u»Маша").first()

:

zoo = Zoo.first(:name => 'Luke')

[@maratk]

Фаулера читать не лень :), в заблуждения вводят названия фреймворков (например, когда-то я думал, что ActiveRecord — это чисто название фреймворка, а не название паттерна изначально).
Пока ехал в метро, понял что session — это и есть UnitOfWork, а заодно и закрались сомнения относительно рубишного ДатаМаппера.
Спасибо за короткий анализ, у Фаулера его нет.
Может знаете, есть ли на руби правильная реализация ДатаМаппера?

[@MrNull]

Действительно, схожесть с RoR увидел только в роутах…

[@demmsnt]

А сравните с ASP и c RoR, кто ближе?

[@demmsnt]

Вот! ASP это фреймворк для WEB и RoR для WEB. Если вы берете классификацию по назначению, то оба они попали в одну корзину, а VCL скажем в другую. Если вы классифицируете по стэйтлесс и стэйтфул. То группировка изменится. Состояние в Django есть — это сессия и много еще разных моментов. В ASP я писал наследника от HTTP кто, то там (не помню уже), потом в массиве хранил пути и обработчике путей. При этом конечно 90% ASP было выкинуто к чертям, но это был RoR (точнее Django стиль).

Возможно я коряво излагаю свою мысль, но Django, Pylons, TG это все близкие родственники RoR. В противоположность разным WSGI фреймворкам которые работают на более низком уровне (ДА Я ЗНАЮ, что Django WSGI, но до такого уровня обычно никто не опускается). В этих фреймворках можно создать роуты, а можно обойтись вообще без них.

[@MyGodIsHe]

flash есть в Pylons

[@myem]

flash есть в большинстве фреймворков (и даже в некоторых CMF).

Задача после post формы выдать сообщение об её обработке после стандартного редиректа слишком частая, чтобы кто-либо мог её проигнорировать.

[@demmsnt]

Или с типичным PHP проектом, где роутами занимается апач, а весь код в шаблоне

[@Novikov]

Да ладно! В типичном пхп-проекте апач кидает запросы на индекс.пхп, а тот уже дальше — в зависимости от архитектуры.

[@Envek]

Ещё WebHelpers утащили оттуда. И мне очень помогает библиотека Pytils, который подглядели у Rutils оттуда же :-)

[@Osado]

Интересный фреймворк, периодически поглядываю на него, но есть пара проектов на django, а вот что-то написать с использованием pylons как-то руки не доходят…

[@Zagrebelion]

Расскажите для тех, кто не на рельсах, что за маршруты и чем они хороши.

[@zw0rk]

Способ описания связи урлов и «ушей» приложения. Помощней, чем джанговская url.py, т.к. можно управлять маршрутом в зависимости от метода запроса, например. + (если всё как в РоР) можно создавать REST-маршруты «в одну строчку». В кратце так, наверное.

[@Envek]

Урл-маршрутизация — разбор адресов, по которым обращается клиент и в зависимоти от них выполнение различных контроллеров (суть функций).
Так, например, в моём приложении, набрав www.example.com/order/5 можно увидеть заявку №5, а на www.example.com/orders можно увидеть весь список заявок. А на www.example.com/order/5/edit у меня скрывается форма редактирования заяки. Ну и так далее :-)
И этим у меня заведуют следующие строчки в routing.py (первая — не в тему):

map.connect ("startpage", "/", controller="main", action="index")
map.connect ("orderlist", "/orders", controller="order", action="list")
# Заявки
map.connect ("order", "/order/{id}", controller="order", action="view", requirements = {'id': '\d+'})
map.connect (None, "/order/{id}/{action}", controller="order", requirements = {'id': '\d+'})

[@Envek]

Ах, как коротко-то…
Скажу я — фреймворк хорош. Вот только, в отличие от RoR (как я понял) — в полстрочки здесь ничего не пишется. Программисту под контроль изначально отдаётся больше вещей.
И модульность здесь поставили во главу угла изначально, поэтому начинка может отличаться и изменяться. С одной стороны хорошо, а с другой — не очень.
Для заинтересовавшихся есть руководство (на английском): Pylons Book. Там всё расписано (хотя часть информации уже могла устареть и устарела)

Замечание автору: в версии 1.0 фреймворка (а точнее в последней версии Routes) функцию url_for объявили устаревшей и выкинули к чертям. Следует использовать функцию url импортируемую из pylons. Синтаксис аналогичен, начинка и поведение — отличаются.

[@nuclon]

использую этот фреймворк в нескольких своих проектах.
В отличии от django позволяет использовать какой угодно ORM, какой угодно template engine, чем меня и привлёк.

и актуальная документация на ближайший релиз 1.0 уже имеется

[@zw0rk]

С каких это пор джанга запрещает использовать сторонний шаблонизатор и ОРМ?

[@MyGodIsHe]

Да собственно никто не запрещает, с шаблонами просто, а вот ORM… весь contrib идет лесом, хотя можно и одновременно использовать разные ORM. Вообще не суть, у Django просто философия другая. Хотя Pylons с FormAlchemy уже рядом моячет по функциональности.

[@nuclon]

может быть я отстал от жизни, но, насколько я помню, в джанге отвязать родной ORM и привязать SQLAlchemy было невыполнимой задачей. Неужели уже эта задача выполнима?

[@zw0rk]

Еще как выполнима. Кто вам мешает вместо:
class Model(models.Model):
...blah...

писать
class Model(Base):
...blah...

?

Отвалятся контрибы многие, но они не есть часть джанги.

[@MyGodIsHe]

Отвалятся не только contrib, а ещё всякие хорошие расширения. А без этого Django уже теряет все свои прелести быстрой разработки.

[@zw0rk]

Никто не говорил, что будет легко.

Но меж тем, джанга будет работать.

[@nuclon]

ну так а смысл тогда, если не будет легко? :)

перефразирую — «задача смены ORM выполнима, но в этом случае Djangо теряет все свои преимущества».

[@zw0rk]

Есть мнение, что в этом случае получится как раз Pylons :)

[@Co0l3r]

из того, что написано в pylonsbook, можно сделать вывод, что разница в использовании других компонентов в Django и в Pylons всё-таки есть:

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

Предоставляемые инструменты работы с данными могут как автоматически создавать код (scaffold в случае Ruby on Rails), так и создавать интерфейсы форм при запуске (в случае с Django).

Хотя эти фрэймворки поддерживают чистое разделение между кодом моделей, видов и контроллеров, они не такие слабосвязанные как в Pylons, потому что работоспособность приложения как единого целого во многом полагается на соединяющий код, находящийся в фрэймворке. Легко создать простое приложение при помощи этих фрэймворков, но настройка их поведения позднее может быть сложной, потому что это предполагает понимание того, как работает код предоставляемый фрэймворком, перед тем как вы поменяете его поведение. Чтобы было проще использовать фрэймворк, его код часто достаточно сложен, и в результате настройка может быть трудной.

Pylons более слабосвязанный. Поскольку он не предоставляет инструментов для автоматической генерации почти законченного сайта из определения модели, ему не нужен сложный соединяющий код, удерживающий всё вместе. Вместо этого, он предоставляет низкоуровневые API и методологии, позволяющие быстро и просто соединить вместе компоненты, которые вы сами выбираете.

Такой подход к слабому связыванию не означает, что вам нужно создавать код для всех частей. В соглашении по конфигурации Pylons считается, что вы захотите использовать стандартные настройки при создании нового проекта. Их можно легко изменить. Например, по умолчанию Pylons использует фрэймворк для работы с шаблонами Mako для генерации шаблонов из видов, но вы не обязаны его использовать. Вы легко можете использовать любой из других крупных языков шаблонов Python, включая Genshi, Jinja или даже Tal или Breve.

[@igorekk]

Тогда можно и bottle.py использовать.

[@LighteR]

Для SQLAlchemy есть неплохая надстройка Elixir

[@kapers]

в порядке информации к размышлению, а не приглашения к холивару.

имхо, pylons очень мощный и гибкий, но достаточно монстрообразный фреймворк, особенно для небольших проектов. и в этом смысле, напоминает symfony.

думаю, джанга в этом смысле предпочтительнее и даже быстрее.
кроме того, в pylons нельзя использовать raw sql запросы, что иногда создает большие трудности.
по крайней мере, не удалось быстро найти как их использовать.

[@nuclon]

в pylons нельзя использовать raw sql запросы, что иногда создает большие трудности.

а каким боком тут pylons? он не предоставляет DBLayer сам по себе. и вас никто не заставляет пользоваться SQLAlchemy, можно использовать и прямое подключение к БД

[@kapers]

можно. но это уже не гламурно будет

[@nuclon]

почему же это «негламурно»? далеко не всем нужен вообще ORM, поэтому использование SQLAlchemy или любого другого ORM — опционально.

django — скорей подходит под определение «монстрообразный фреймворк» :)

[@MyGodIsHe]

пример raw:

>>> from sqlalchemy.sql import text
>>> s = text("""SELECT users.fullname || ', ' || addresses.email_address AS title
...            FROM users, addresses
...            WHERE users.id = addresses.user_id AND users.name BETWEEN :x AND :y AND
...            (addresses.email_address LIKE :e1 OR addresses.email_address LIKE :e2)
...        """)
sql>>> print conn.execute(s, x='m', y='z', e1='[e-mail]', e2='[e-mail]').fetchall()

Но чаще такое не нужно, это все можно методами описать.
Подробнее про sqlexpression.

[@kapers]

спасибо. именно то, что нужно.

а подскажите еще, пожалуйста, как решается в ORM пробелма с операторами аггрегации?
типа group by
в свое время искал, но так ничего и не нашел.

[@MyGodIsHe]

Подсказываю.
ORM:

>>>session.query(User.name).group_by(User.name).count()  
SELECT count(1) AS count_1 FROM (SELECT users.name AS users_name FROM users GROUP BY users.name) AS anon_1 ()

SQLExpression:

>>> s = select([addresses.c.email_address, addresses.c.id]).distinct().\
...     order_by(addresses.c.email_address.desc(), addresses.c.id)
>>> conn.execute(s).fetchall() 
SELECT DISTINCT addresses.email_address, addresses.id FROM addresses ORDER BY addresses.email_address DESC, addresses.id ()

[@kapers]

супер. спасибо.

[@nuclon]

кстати, начиная с SQLAlchemy 0.6 — вполне возможно использовать raw sql и маппить его:

>>> session.query(User).from_statement(«SELECT * FROM users where name=:name»).params(name='ed').all()
[<User('ed','Ed Jones', 'f8s7ccs')>]

www.sqlalchemy.org/docs/ormtutorial.html#using-literal-sql