Вышел django 1.0

Зачем оно нужно, если есть глобальный и надежный PHP?

Ну наконец-то! Сколько я ждал этого дня.

Замечательно.

+1

понаизобретали велесипедов. PHP рулит рулит и будет рулить.

>Улучшена поддержка юникода

блядь, уникод или поддержывается или нет. низя быть мальца беременной...

> блядь, уникод или поддержывается или нет. низя быть мальца беременной... Утютю. В питоне есть строки str() и unicode(). А Джанга может использовать как те, так и другие. Лучше помолчать, чем молоть всякую чушь.

понабежало тут быдлопхпшнегов-троллей. Чертоги биореактора открыты господа !

Сегодня просто праздник какой-то! GNU - 25, Django - 1.0!

>В питоне есть строки str() и unicode(). А Джанга может использовать как те, так и другие. Лучше помолчать, чем молоть всякую чушь.

уг детектед. для альтернативно одаренных - "Улучшена поддержка юникода" является манагерско-пеарским баззвордом. какие есть строки и каких нету - внутреннее дело питона. уникод или есть или нету. точка.

>уникод или есть или нету. точка. Ну если например в некоторых частях джанговской автоадминки или скажем в генераторе форм не поддерживались уникод строки, то когда это исправили, в целом говоря про джангу можно сказать что поддержка уникода улучшена, ибо она была, но не везде, а теперь вроде как везде.

чем оно лучше RoR? o_O

>в целом говоря про

в целом по больничке температура нормальная.

python, админка, подключаемые приложения, урлконф на регулярных выражениях. Вы скажите лучше чем РоР лучше джанги :)

> python

Спорное преимущество

Все остальное в роре есть либо делается легким движением руки.

Такой подарок ко Дню рождения. Пасибо :)

>Обещается обратная совместимость со всеми последующими релизами 1.*

неужели? =))

зы чем оно лучше grails-то?

Модель User все так же захардкожена и хрен без monkey patching ее переделаешь? С кривейшим костылем User.profile?

Омерзительно.

Худей.

> С кривейшим костылем User.profile?

И чем же он такой кривой, можно узнать? Пользуюсь уже год, всем доволен.

Слышал говорят, что pylons лучше, это так?

Нет, не так.

> Слышал говорят, что pylons лучше, это так?

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

> И чем же он такой кривой, можно узнать? Пользуюсь уже год, всем доволен.

Во-первых тем, что неудобно работать с двумя моделями там, где достаточно одной. Наследование (в кой-то веки тогда их ORM перестал совсем сильно сливать SQLAlchemy+Elixir, хотя multiple database branch до сих пор в заднице) сделали, а это не поправили.

Во-вторых, очевидно, тем, что вся идея loose coupling нарушена. Или ты пользуешься их auth и получаешь все остальные contrib-компоненты или ты сосешь лапу. Сделал свой auth — или поздоровайся с костылями или забудь про половину джанги. Рекомендуемый в документации костыль, когда миддлварь лезет во внешнюю систему и копирует оттуда данные в локальную БД — именно что костыль. Хотя, конечно, пользоваться и можно, но архитектурно выглядит омерзительно криво.

Нет бы сделали в settings некое USER_MODEL = mystuff.User вместо хардкода вовсюда django.contrib.auth.User. Дальше оговорили что есть два обязательных поля (id, login) и или поле password или метод check_password (или, если нету, скажем, по X.509-сертификатам авторизуем, тога ничего нет, а миддлварь авторизации сам пишешь)... И было бы все куда более по-человечески.

Напиши патч, предложи разработчикам.

Приведи реальный пример.

> Напиши патч, предложи разработчикам.

патч будет больше, чем весь код django, поскольку переделывать надо очень много. то-то они sqlalchemy уже несколько раз прикрутить пытались, да так и не смогли потому, что в django все ко всему прибито гвоздями.

а как там с миграциями? до сих пор нада сносить все и заново вливать в базу? можно конечно ручками, база - то фигня, а то что нада еще модель править - нафик что у нас с деплойментом?

> Напиши патч, предложи разработчикам.

Я в курсе про patches welcome, спасибо.

Но у меня нет столько времени и сил, чтобы перелопатить, по сути, весь contrib.*, и потом еще доказывать что мой патч нужно принять.

> а как там с миграциями? до сих пор нада сносить все и заново вливать в базу?

Не, это они сделали. http://code.djangoproject.com/wiki/SchemaEvolution

используй deseq люк :-)

>Вы скажите лучше чем РоР лучше джанги :)

Тем что РоР ближе к DSL. Это за счет руби, где:

1. Нечувствительность к идентации 2. Возможность использовать obj.meth par1 par2 вместо obj.meth(par1, par2) 3. Возможность модифицировать все объекты, включая такие как классы и стандартные объекты с помощью всяких class_eval, <<, alias и прочего 4. Наличие блоков кода

Все вышеперечисленное позволяет делать нечто DSL-подобное (потому как таких вещей как макросы там нету:) ), насколько это хорошо - вопрос спорный и и ответ на него видимо зависит от личных предпочтений и привычек.

Что касаеться не языка, а технологических решений - нкиак не пойму почему в джанго не сделают миграции аля РоР. Или религия не позволяет?:) А так штуки (РоР/джанго) равно бестолковые.

> Во-первых тем, что неудобно работать с двумя моделями там, где достаточно одной

Абсолютно никаких неудобств не замечено. Всё прозрачно и просто.

> Рекомендуемый в документации костыль, когда миддлварь лезет во внешнюю систему и копирует оттуда данные в локальную БД — именно что костыль.

Определение "костыля" в студию. Мидлварь - вполне логичное решение, ничем не хуже переопределения половины auth только для того, чтобы иметь свою хитрожопую авторизацию с блекджеком и шлюхами.

Ура! Ура! Ура! Наконец таки!

>Не, это они сделали. http://code.djangoproject.com/wiki/SchemaEvolution

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

> Абсолютно никаких неудобств не замечено. Всё прозрачно и просто.

Угу, прозрачно и просто. Логин, имя и e-mail в User, а XMPP и OpenID URI — в Profile. Очень логично.

> Определение "костыля" в студию.

Решение, реализующее функциональность, в обход проблем архитектуры. Как-то так.

> Мидлварь - вполне логичное решение

Я не о том. auth это тоже мидлварь, если на то пошло. Я о том, что эта мидлварь обязана вернуть django.contrib.auth.models.User. Мне не нужна эта модель, она мне неудобна, и вообще мне не интересно дублировать данные в локальной SQL-БД (мне больше подходят, например, запросы к RADIUS-серверу, скажем, и memcached для их кэширования). Но я хочу админку, она хороша и писать свою мне не хочется. Свою плату в виде отсутствия констрейнтов к users.id я отлично знаю и она меня устраивает.

А разгадка одна. Заточено только под классические веб-сайты, к интеграции с другими системами (скажем, с биллингом у провайдера) неудобно. Нескольких БД нет, сменных моделей на практике почти что нет, loose coupling в contrib нет, жизни нет, населена роботами.

> Угу, прозрачно и просто. Логин, имя и e-mail в User, а XMPP и OpenID URI — в Profile. Очень логично.

А, забыл самое великолепное. Отчество — в Profile.

не понимаю, зачем делать столько телодвижений реализуя миграции, когда есть АЛЬТЕР ТЕЙБЛ?

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

> не понимаю, зачем делать столько телодвижений реализуя миграции, когда есть АЛЬТЕР ТЕЙБЛ?

Глупости какие. Вот ты поправил свой models.py. Добавил пять полей, поменял тип у одного, и удалил еще одно. Потом набил ALTER TABLE в консоли, зачем-то повторив то, что ты уже как бы сделал в модели. И продолжил писать код.

А через недели три, когда QC дает добро, ты это пихаешь на другой сервер, на котором пока что крутится старая версия приложения. И знакомишься со своими новыми друзьями — бобром Ангстом и белочкой Шмерц при попытке вспомнить что же ты там делал с базой. Или не ты, а твой коллега-индус. Или вообще хрен знает кто (привет git-bisect(1)!).

А с мигрейшенами ты закатил новый код, сказал sqlevolve и доволен.

> Вы скажите лучше чем РоР лучше джанги :)

ну как минимум тем, что сегодня вышел только первый релиз джанги, а ror 1го июня выпустило версию 2.1, и в ближайшее время ожидается 2.2

тем что из РоР выкинули все лишние вещи типа авторизации и отдали их на откуп плагино-строителям.

Сохранить sql-скрипт религия не позволяет?

Первый релиз джанги был 3 года назад. При этом, на том релизе крутились несколько очень посещаемых сайтов. Так что бредовый аргумент.

> Сохранить sql-скрипт религия не позволяет?

Так миграции *это* и делают.

Есть два типа миграций. Один генерят питоновый код (и SQL из него делают уже в рантайме), другие — SQL. И здесь уже вопрос кому как удобнее, в общем вкус фломастеров. Первые чуть помощнее, т.к. могут еще данные переработать по всякому, второе — проще и более KISS. Но делать все руками — это никак не удобнее.

Про модели — не знаю что там такое злое в рельсах, а в deseb все миграции ложатся отдельными файликами в отдельную директорию и совершенно не мешают. На них, обычно, никто даже не смотрит никогда, все делает автомат сам.

> Первый релиз джанги был 3 года назад.

ага, очень круто программить 3 года на API в котором не гарантируется обратная совместимость с будущими версиями.

релизом считается 1.0, до этого публичный процесс разработки с толпой бесплатных бета-тестеров

>чем оно лучше RoR? o_O

Батенька, вы плохо понимаете что сравниваете. Не растекаясь словами можно ответить коротко : всем!

>чем оно лучше RoR? o_O

Быстрее в раз дцать в работе. Да и возможностей в python больше чем ruby.

> В роре с этими миграциями вообще какой-то ужас.

открой для себя db/schema.rb, генерится автоматом.

>В джанге открыл файл моделс.пи и читаешь, все понятно. А в роре открываешь, а там сотня миграций. И каждую прочитать нужно, и наложить друг на друга. Очень неудобно.

эм... а просмотреть структуру таблицы не?
mysql > desc table_name;
postgresql> \d table_name;

Вам же дали ссылку с различными «плагинами» для миграции. Ставите и будет все так же.

> блядь, уникод или поддержывается или нет. низя быть мальца беременной...

Пройди уже по ссылке и почитай. Хватит троллить.

>Быстрее в раз дцать в работе. Да и возможностей в python больше чем ruby.

Быстрее - да. А вот то что в питоне возможностей больше - в студию! Всегда думал что в руби как раз таки возможностей больше, только индусам им в руки давать опасно. А быдлокодить это руби -> питон -> жава -> пехапе (по поощраемости быдлокодинга). На руби пишу, но все равно быдлячий язчок как никрути:) А на не быдлячем силенок писать не хватит.. Ну да ладно:)

Ах да, насчет - производительности, так тогда Merb вам в руки.