LINUX.ORG.RU

Django 1.7

 ,


1

3

Состоялся релиз новой версии популярного web-фреймворка Django, написанного на Python.

Самое ожидаемое нововведение - встроенные миграции! https://docs.djangoproject.com/en/1.7/topics/migrations/

Другие значительные изменения:

Ознакомиться с полным списком изменений можно по ссылке.

>>> Подробности



Проверено: Shaman007 ()

Ответ на: комментарий от menangen

но не намного лучше Django Template Engine

У DTL девиз — создай по кастомному тегу на каждый пук! Он конечно с каждым релизом приближаются к mako/jinja, но еще ползти лет 10. Джанго админка такая дубовая в первую очередь из за негибкости шаблонного движка.

bj
()
Ответ на: комментарий от bj

Ну так в куках хранят только пары: key=value. Set-cookie это просто действие установки такой пары. Про пробросить запрос ничего не понял - куда его пробрасывать? От одного бэкэнд модуля к другому на этом же бэкенде? Берёшь, делаешь токен, сохраняешь в кукис, и по токену вытаскивай из бд то, что ты хочешь делать с клиентом или его данными. К тому же, это всё реализовано в абстракции «сесии», к чему такой изврат?)

menangen ★★★★★
()
Ответ на: комментарий от bj

Я обычно пишу две админки. Одну на джанге для управлением основными users, group, etc. И вторую для клиентов сервиса, где они могут менять/создавать свои профили и т.п. херню по типу своей страницы в контакте. Вторая админка у меня гораздо более навороченная, и вылизывается чуть ли не 1/3 времени написания всего приложения/сайта. Ну, а первую (джанга админ панель) я не кастомизирую, смысла в этом не вижу...

menangen ★★★★★
()
Ответ на: комментарий от vitalif

Вот!

Отсюда простой вывод.

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

Если делаешь свой проект, то лучше без фрейвока.

anonymous
()
Ответ на: Вот! от anonymous

А по мне так, если пишешь один - то ресурсы ограничены - начинать надо с прототипа, и его лучше писать на фреймверке; благо, сейчас куча микрофреймворков, даже на том же php есть годные микрофреймворки, просто такие решения (и многие php'ники даже не в курсе) мало-популярны, т.к. клепают сайтики на джумла и т.п.

menangen ★★★★★
()
Ответ на: комментарий от menangen

Микрофреймворки, кстати, может и поадекватней полновесных. Но я их не щупал до сих пор, только слышал.

vitalif ★★★★★
()
Ответ на: комментарий от menangen

даже на том же php есть годные микрофреймворки, просто такие решения (и многие php'ники даже не в курсе)

Но я их не щупал до сих пор, только слышал.

а этот тип - тот самый парень. Не слышал не видел не хотел.

umren ★★★★★
()

Ещё лет 5 и Django дорастёт до уровня Rails 3.x, главное только ждать и помнить, что «питон быстрый, аминь»! :)

Alve ★★★★★
()
Ответ на: комментарий от ggrn

нинужно

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

anonymous
()
Ответ на: комментарий от Debasher

Но ведь Rails есть

На котором кодили в основном всякие хипстеры несколько лет назад. Наигравшись, они его выбросили и нашли себе новую игрушку — node.js, которую так же через пару лет забудут, наигравшись.

anonymous
()
Ответ на: комментарий от Alve

по невменяемости и неудобности? сомневаюсь, что это вообще реально :)

odii
()
Ответ на: комментарий от Debasher

Рельсовики все больше похожи на бсдишников, гальванизируют все активнее и активнее.

anonymous
()
Ответ на: комментарий от loz

Нечего, просто констатирую факт, ерланг конечно очень оригинальная штука, надеюсь к нему таки допилят jit.

st4l1k ★★
()
Ответ на: комментарий от anonymous

Но ведь Rails есть

На котором кодили в основном всякие хипстеры несколько лет назад. Наигравшись, они его выбросили и нашли себе новую игрушку — node.js, которую так же через пару лет забудут, наигравшись.

А вот питону, кстати, вряд ли это грозит, потому что питон штука универсальная и используется не только в web. Поэтому даже если и случится так что популярность Django упадёт, то только потому что будет более интересный фреймворк на Питоне. Тем более их и сейчас несколько (Фласк и пр.).

anonymous
()
Ответ на: комментарий от st4l1k

О да это видно по быстроте с какой люди мигрировали с питона 2 на 3

А причём тут Питон 3 и миграция на него?

anonymous
()
Ответ на: комментарий от fedorino_gore

Тогда он тебе точно не нужен :-) лучше flask или web2py для новичков.

menangen ★★★★★
()
Ответ на: комментарий от Alve

Ну, если только по количеству дыр, всё остальное есть как отдельные приложения/модули в pip или github.

menangen ★★★★★
()
Ответ на: комментарий от umren

Да народ фапает на Rails тупо по двум штукам:
1. Типа крутой скаффолдинг. Когда командой в консольке генеришь кучу кода, тестинг и прочее. Скаффолдингом же создаёшь модель и прочее. Короче, скафолдинг помогает новичкам нереально.
2. ActiveRecord из Rails. Типа там всё удобно, не нужен SQL и вообще, забудь о базах навсегда, базы пугают многих, особенно народ кайфует после перехода с php, кстати тот же scafolding не хило заточен под activerecord, т.е. новичек пищит от радости, что кода почти не нужно писать.
Короче, это всё даёт возможность писать гостевухи, магазинчики, различные голосовалки, сайты-каталоги-топ (типа топ майнкрафт серверов), за пару тройку часов, что неимоверно доставляет, поэтому любовь к Rails у хипстерят на лицо.

menangen ★★★★★
()
Ответ на: комментарий от menangen

Не знаю, не знаю... Ну тоже ведь - сборище тривиального функционала. Например:

Flight::route('/', function(){ echo 'hello world!'; });

Нафига так делать, чем это лучше? Это же не быстрее: в начале каждого запроса делаются лишние действия - заново устанавливаются все функции ответа. Это не проще и не понятней: 1 функция с if'ами и регэкспами займёт столько же кода. Это не гибче: урлы только парсятся, но не генерятся, и их точно так же нужно хардкодить в шаблонах (в отличие от этого я себе например запилил некий «диспетчер», который разбирает и составляет урлы в обе стороны по одному и тому же описанию, причём делает это быстро, т.к. описание компилится в пхп код).

vitalif ★★★★★
()
Ответ на: комментарий от menangen

Типа крутой скаффолдинг

небольшой плюс в этом есть, но далеко не киллерфича

ActiveRecord из Rails

ничем не лучше django orm

Короче, это всё даёт возможность писать гостевухи, магазинчики, различные голосовалки, сайты-каталоги-топ

на джанге тоже пишется, за то же время

umren ★★★★★
()
Ответ на: комментарий от menangen

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

st4l1k ★★
()
Ответ на: комментарий от menangen

Тебя забанили в Google, о наисветлейший?

я так понимаю, это относится к вопросу о несовместимости WSGI и WebSockets. хорошо, поставим вопрос так. в каком месте WSGI конфликтует с WebSockets?

я лично не занимался вопросами реализации WebSockets поверх WSGI, но коллеги вполне успешно используют комбинацию «обычного» WSGI-приложения с WebSockets именно благодаря гибкости WSGI.

anonymous
()
Ответ на: комментарий от anonymous

Отлично, тогда вам точно стоит почитать автора django-websocket:

https://pypi.python.org/pypi/django-websocket

Disclaimer (what you should know when using django-websocket)

BIG FAT DISCLAIMER - right at the moment its technically NOT possible in any way to use a websocket with WSGI. This is a known issue but cannot be worked around in a clean way due to some design decision that were made while the WSGI stadard was written. At this time things like Websockets etc. didn't exist and were not predictable.

However there are thoughts to extend the WSGI standard to make Websockets possible. Read here for a discussion on the Paste Users mailing list.

But not only WSGI is the limiting factor. Django itself was designed around a simple request to response scenario without Websockets in mind. This also means that providing a standard conform websocket implemention is not possible right now for django. However it works somehow in a not-so pretty way. So be aware that tcp sockets might get tortured while using django-websocket.

https://github.com/jrief/django-websocket-redis/blob/master/docs/introduction...

Due to this workflow, it is almost impossible to add support for long term connections, such as websockets, on top of the WSGI protocol specification. Therefore most websocket implementations go for another approach. The websocket connection is controlled by a service running side by side with the default application server. Here, a webserver with support for long term connections, dispatches the requests from the clients.

menangen ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.