После почти года разработки вышла (https://www.djangoproject.com/weblog/2013/feb/26/15/) стабильная версия популярного фреймворка Django 1.5 (https://docs.djangoproject.com/en/1.5/releases/1.5/), написанного на языке Python и предназначенного для разработки веб-приложений. Выпуск Django 1.5 примечателен обеспечением поддержки Python 3 (https://docs.djangoproject.com/en/1.5/topics/python3/).
Несмотря на то, что работа под управлением Python 3 пока имеет экспериментальный статус, в целом код отмечен как стабильный, но требующий расширенного тестирования в реальных проектах. При подготовке следующих выпусков ошибки, связанные с совместимостью с Python 3, отныне будут рассматриваться как блокирующие выпуск новых релизов и требующие оперативного исправления. В качестве побочного эффекта адаптации для Python 3 является прекращение поддержки ветки Python 2.5, в качестве минимально поддерживаемой версии заявлен выпуск Python 2.6.5, а в качестве рекомендуемой - Python 2.7.3.
Из других изменений (https://docs.djangoproject.com/en/1.5/releases/1.5/) отмечается обеспечение средств для использования собственных моделей для организации хранения параметров пользователей и задействования данных моделей в системе аутентификации Django. Создание собственных моделей хранения данных может понадобиться например при необходимости работы с логинами, превышающими 30 символов или при желании добавить дополнительные поля, такие как идентификаторы пользователя в Twitter или Facebook, или сохранить имена пользователей в формате отличном от "Имя/Фамилия".
Коме того в новом выпуске добавлена (https://docs.djangoproject.com/en/1.5/releases/1.5/#support-...) возможность сохранить подмножество полей модели хранения данных, реализуемая через перечисление требуемых для сохранения полей при вызове метода Model.save() (https://docs.djangoproject.com/en/1.5/ref/models/instances/#...) с указанием нового аргумента update_fields. Обеспечена возможность работы GeoDjango (https://docs.djangoproject.com/en/1.5/releases/1.5/#geodjango) с PostGIS 2.0. Добавлен новый класс StreamingHttpResponse (https://docs.djangoproject.com/en/1.5/ref/request-response/#...) с реализацией улучшенной поддержки обработки потоковых запросов. Для блокирования экранирования элементов JavaScript-кода в шаблонах Jango добавлен новый тег "{% verbatim %} (https://docs.djangoproject.com/en/1.5/ref/templates/builtins...)".Значительно переработан раздел документации (https://docs.djangoproject.com/en/1.5/), упрощён поиск интересующих разделов и статей. Добавлены новые руководства, описывающие расширенные области использования Django, такие как руководство (https://docs.djangoproject.com/en/1.5/intro/reusable-apps/) по использованию кода приложения в разных проектах. Переработана документация (https://docs.djangoproject.com/en/1.5/topics/class-based-views/) по представлениям на основе классов. По возможности разработчики попытались сохранить совместимость API с прошлыми выпусками, но тем не менее отмечается (https://docs.djangoproject.com/en/1.5/releases/1.5/#backward...) ряд незначительных изменений, нарушающих совместимость, и перевод некоторых возможностей в разряд устаревших.
URL: https://www.djangoproject.com/weblog/2013/feb/26/15/
Новость: http://www.opennet.me/opennews/art.shtml?num=36237
Наконец! Долго ждал.
Давно пора.
Собственно уже работаем на Python3, на Django 1.5
Правдо очень не хватает под Py3 этого:
https://github.com/django-debug-toolbar/django-debug-toolbar
https://github.com/django-debug-toolbar/django-debug-toolbar...
Python3
>JangoЭто опечатка?
One... two... jango.
:)"Django Unchained": 'The 'D' Is Silent' (или можно вообще не писать, как в тексте новости)
http://news.moviefone.com/2012/06/06/django-unchained-traile...
местами хороший фильм.
Со слащавым ДиКаприо, у которого тоже бабушка русская? :) Btw, а он к академику еще не ездил на поклон?
One Piece FTW!
Шел 2013 год, а горе вебмастера, выпучив глаза от натуги и роняя пачки долларов на оплату все растущих серверных ферм, продолжают генерить HTML на серверной стороне.
а если нет, что делать при динамическом контенте с noscript?
да, только:
а) если генерить хтмл целиком в жаваскрипте, никакое СЕО вас не найдёт.
б) если аякс должен модифицировать не только 1 элемент, а хотя бы 2 в разных частях хтмл-страницы, то это офигеешь программировать
в) что-что там за экономия на серваках на выводе хтмл? было 10% нагрузки, стало 9%? Или было 99%, стало 98%? Знаете ли, если у вас str.replace(x,context[x]) генерирует ТАКУЮ загрузку на сервак, что речь об экономии идёт... то пора уже поменять 386SX на хотя бы пентиум3.
г) ну да, у вас прыщавые задроты программируют, ниасилили server-side шаблоны, вот ваша главная экономия.
> б) если аякс должен модифицировать не только 1 элемент, а хотя бы
> 2 в разных частях хтмл-страницы, то это офигеешь программировать? почему?
>> б) если аякс должен модифицировать не только 1 элемент, а хотя бы
>> 2 в разных частях хтмл-страницы, то это офигеешь программировать
> ? почему?да потому, что если таких штук много разных, то это будет либо повторение кода по 10 раз (т.е. быдлокодинг), либо сложная система зависимостей, и в любом случае это будет работать только для конкретного DOM. Изменится шаблон -- и все эти зависимости переписывайте заново.
Да и вообще аякс хорош там, где ты точно знаешь, что и как юзер должен делать. В админках, во всяких планировщиках и т.п. На обычном сайте аякс - это зло, потому что обработка ошибок практически невозможна. Невозможно остановить запрос аякс (юзеру), да и он вообще не понимает, что происходит. А если таймаут запроса, то что? Юзер может понять, что такое 404, но когда ему на той же странице выводится alert(404 ...) - у него когнитивный диссонанс. И т.д.
Невозможно опять же работать с СЕО, потому что гугл не будет аякс запросы выполнять :)
> а) если генерить хтмл целиком в жаваскрипте, никакое СЕО вас не найдёт.всё наоборот. если робот получает ТОЛЬКО контент, без оформления -- то ему становится очень просто.
> б) если аякс должен модифицировать не только 1 элемент, а хотя бы 2 в разных частях хтмл-страницы, то это офигеешь программировать
объектно-ориентированная модель для [объект_страница] с наследованием виджетов -- делается на Javascript на много более естественным образом, чем формирование плоского HTML-текста
>> а) если генерить хтмл целиком в жаваскрипте, никакое СЕО вас не найдёт.
> всё наоборот. если робот получает ТОЛЬКО контент, без оформления -- то ему
> становится очень просто.здрасте, а что такое контент и что такое оформление? Контент - это шаблон хтмл. Оформление - это CSS и графика. И где тут ваше ЖС?
>> б) если аякс должен модифицировать не только 1 элемент, а хотя бы 2 в разных частях хтмл-страницы, то это офигеешь программировать
> объектно-ориентированная модель для [объект_страница] с наследованием виджетов -- делается
> на Javascript на много более естественным образом, чем формирование плоского HTML-текстаона-то делается, но это затраты времени на компе юзера (который необязательно xeon 4GHz), подходит не для всех типов контента и к тому же весьма привязано к конкретике. Захотели изменить шаблон (хотя бы какой-нить новый див вставить) - велкам к переписке всего вашего ЖС. Либо заранее извращайтесь и пишите мегабайты ЖС. Шаблон составить и поддерживать куда проще.
> здрасте, а что такое контент и что такое оформление? Контент - это шаблон хтмл. Оформление - это CSS и графика. И где тут ваше ЖС?нажми CTRL+U и увидешь там кучу HTML-кода, который ни каким боком не относится к контенту :)
да. я согласен с тем что АБСОЛЮТНО весь HTML-код нельзя генерировать только на клиентской стороне. тот HTML-код который относится к <main>...</main> ( http://www.sitepoint.com/html5-main-element/ ) -- придётся всёже генерировать на сервере [в простом виде, а затем усложнять на клиентской стороне].
так-что не будем тут так сказать максималистами :)
> да, только:И ещё когда сайт жрёт батарейку как полоумный, закрывается он ближе к моментально.
ды не надо ни каких <noscript>...</noscript>! :)на каждого подобного извращенца не напасёщся заглушек! :-D
кто-то отключил скрипты... а кто-то другой отключил куки... а ещё кто-то другой отключил localStorage....
а ЗАЧЕМ они вообще это отключают-то? профит-то какой от отключения? :)
ну раз сам отключил чего-то -- то сам получи белый экран (вместо странички сайта), и сам думай почему не работает :-) ..
> кто-то отключил скрипты... а кто-то другой отключил куки... а ещё кто-то другой
> отключил localStorage....
> а ЗАЧЕМ они вообще это отключают-то? профит-то какой от отключения? :)
> ну раз сам отключил чего-то -- то сам получи белый экран (вместо
> странички сайта), и сам думай почему не работает :-) ..Поднимите руки, кто на веб-сервере делает фильтрацию, подобную osf, по фильтру Windows?
> Поднимите руки, кто на веб-сервере делает фильтрацию, подобную osf, по фильтру Windows?в каком смысле? чтоб никто кроме Windows не заходил? или наоборот? :)
> а ЗАЧЕМ они вообще это отключают-то? профит-то какой от отключения? :)Немерянный.
> Шел 2013 год, а горе вебмастера, выпучив глаза от натуги и роняя
> пачки долларов на оплату все растущих серверных ферм, продолжают генерить HTML
> на серверной стороне.полностью подписываюсь!
сегоднящняя ситуация совершенно нелепа!
очевидно что оформительская часть сайтов должна формироваться именно на клиентской стороне. почему этого до сих пор нет (когда уже даже победили монополию MsIE) -- я что-то затрудняюсь ответить даже %)
> почему этого до сих пор нет (когда уже даже победили монополию MsIE) -- я что-то затрудняюсь ответить даже %)Когда все делают одно движение, Вася делает три. :)
ну может быть из-за этого. может ты тут и прав
>> Шел 2013 год, а горе вебмастера, выпучив глаза от натуги и роняя
>> пачки долларов на оплату все растущих серверных ферм, продолжают генерить HTML
>> на серверной стороне.
> полностью подписываюсь!может ещё и подкакиваетесь? %)
> сегоднящняя ситуация совершенно нелепа!
> очевидно что оформительская часть сайтов должна формироваться именно на клиентской стороне.
> почему этого до сих пор нет (когда уже даже победили монополию
> MsIE) -- я что-то затрудняюсь ответить даже %)и как это будет выглядеть? "пожалуйста, скачайте 500К жаваскрипта и 20М шаблонов, и браузер вам всё сгенерит через полчаса"?
Вы не знаете элементарных вещей. Ту же jquery, которая 100К минимизирована, браузер парсит 1-2 сек. jquery-ui - ещё пару сек. Если ещё добавить к этому генерацию всего хтмл из загружаемых шаблонов (а каким образом? динамически подгружать по одному? или сразу всё?) за это время клиент проблюётся на ваш loading.gif и удалит ваш сайт из истории посещений.
Спасибо, это очень круто -- сэкономить 1% нагрузки сервака на генерацию шаблонов и потерять 90% клиентов, у которых нет желания дожидаться непонятно чего непонятно сколько времени.
И это ещё без учёта СЕО -- гугл и тындекс вряд ли будет ваши скрипты выполнять.
> Ту же jquery, которая 100К минимизирована, браузер парсит 1-2 сек.вся объектная модель УЖЕ есть в vanille-js .
скачайте этот фреймворк от сюда -- http://vanilla-js.com/?download
> И это ещё без учёта СЕО -- гугл и тындекс вряд ли будет ваши скрипты выполнять.
контент страницы (без оформления) -- сёравно роботы будут получать как надо.
js -- только для оформления. также как и CSS
> и как это будет выглядеть? "пожалуйста, скачайте 500К жаваскрипта и 20М шаблонов, и браузер вам всё сгенерит через полчаса"?
тоесть по вашему -- клиентская стороная такая прям тормознутая, что аж пол часа генерирует, а серверу это раз плюнуть? :-) [или думаете что Javascript-тормазнутее чем PHP? лол]
ды вообще-то реальность такова что зачастую сервера в несколько раз слабее чем клиентская сторона :-)
зайди на страничку Google App Engine например и узнай какие там выделяются мощности для хостинга сайтов :)
(а если хоститься на shared-хостингах -- то там обычно разрешают использовать не более 1~3% от ядра процессора. и это кстате издевательство!)
> скачайте этот фреймворк от сюда -- http://vanilla-js.com/?downloadВы не понимаете значения слова "фреймворк". И его назначения.
> Вы не понимаете значения слова "фреймворк". И его назначения.у тебя есть хоть чуть-чуть чуство юмора? или ты ещё до сих пор не проснулся? :)
> у тебя есть хоть чуть-чуть чуство юмора? или ты ещё до сих пор не проснулся? :)Чувство юмора - вроде есть... наверное, если опять где-то не оставил. Но я на этом фреймворке делал сайты ещё 11 лет назад, и мне не до смеха. Фишка в том, что это НЕ ФРЕЙМВОРК. Он не делает лучше, проще и совместимее. Он делает непонятнее, сложнее и с проблемами совместимости.
> Но я на этом фреймворке делал сайты ещё 11 лет назад, и мне не до смехану 11 лет назад там даже не было ``document.querySelector()'' :)
>тоесть по вашему -- клиентская стороная такая прям тормознутая, что аж пол часа генерирует, а серверу это раз плюнуть? :-) [или думаете что Javascript-тормазнутее чем PHP? лол]Ну не хочу чтоб какая-то там клиентская сторона, чей код можно модифицировать прямо в браузере, а то и на подлете к браузеру, лазила ко мне напрямую в базы данных и выполняла на сервере команды. И не понимаю в чем профит от отсылки кода, который генерит страницу, вместо самой страницы, объем кода и статики никак не меньше.
>>тоесть по вашему -- клиентская стороная такая прям тормознутая, что аж пол часа генерирует, а серверу это раз плюнуть? :-) [или думаете что Javascript-тормазнутее чем PHP? лол]
> Ну не хочу чтоб какая-то там клиентская сторона, чей код можно модифицировать
> прямо в браузере, а то и на подлете к браузеру, лазила
> ко мне напрямую в базы данных и выполняла на сервере команды.до этого ещё не дошло вроде, но вообще интересно:
$.get( javascript.mysql_query("SELECT ***") ... )
$.get( "/etc/passwd" ... )> И не понимаю в чем профит от отсылки кода, который генерит
> страницу, вместо самой страницы, объем кода и статики никак не меньше.да вот я тоже чего-то не понимаю.
Наверно есть настолько фанаты жавасрипта, что написать шаблон на шаблонизаторе религия не позволяет. Или знания %)
Тут спорят о том что отдавать с сервера html или json + статику, а вы тут со своими детскими страхами. Успокойтесь никто вам в базу не залезет.
>И не понимаю в чем профит от отсылки кода, который генерит страницу, вместо самой страницы, объем кода и статики никак не меньше.Что вы нихрена не понимаете я уже заметил. Что непонятного в том что если пользователь нажимает "отсортировать по цене" в одном случае скрипт на сервере лезет в базу данных и с нуля генерит страницу и посылает ее клиенту, а в другом не нужен даже сетевой запрос?
>>И не понимаю в чем профит от отсылки кода, который генерит страницу, вместо самой страницы, объем кода и статики никак не меньше.
> Что вы нихрена не понимаете я уже заметил. Что непонятного в том
> что если пользователь нажимает "отсортировать по цене" в одном случае скрипт
> на сервере лезет в базу данных и с нуля генерит страницу
> и посылает ее клиенту, а в другом не нужен даже сетевой
> запрос?это похоже вы не понимаете. Речь была о замене генерации шаблонов на сервере генерацией их в жавасрипте. Если шаблон с сервака пришёл, кто мешает там хоть сортировку, хоть анимацию, хоть ж*** показать с ЖС? Но другое дело, если с сервака приходит непонятно что, из которого нужно всю страницу слепить.
Есть разница? или вы всё ещё не понимаете?
> Тут спорят о том что отдавать с сервера html или json +
> статику, а вы тут со своими детскими страхами. Успокойтесь никто вам
> в базу не залезет.Про json не было разговора. Ну раз зашел. В чем профит?
> Что вы нихрена не понимаете я уже заметил.
А понятно, очередное хамло.
> Что непонятного в том
> что если пользователь нажимает "отсортировать по цене" в одном случае скрипт
> на сервере лезет в базу данных и с нуля генерит страницу
> и посылает ее клиенту, а в другом не нужен даже сетевой
> запрос?А разве сейчас не так? Вы тут с революцией web2.0 лет на 20 опоздали, dhtml вначале, а позже ajax давным давно это позволяют. Яркий пример вашему описанию: http://www.datatables.net/ .
Только вот наличие клиентской стороны никак не отменяет серверную сторону.
> Только вот наличие клиентской стороны никак не отменяет серверную сторону.Надо в браузеры торрент встраивать. Эх, опера опередила своё время.
>> Только вот наличие клиентской стороны никак не отменяет серверную сторону.
> Надо в браузеры торрент встраивать. Эх, опера опередила своё время.Да чего там, уже пару лет как виртуалка в браузерах есть, можешь свой сервер в браузере запустить, а то и облако.
Там - это где? В Опере? Или вообще в браузерах?
http://bellard.org/jslinux/tech.html
>> Ту же jquery, которая 100К минимизирована, браузер парсит 1-2 сек.
> вся объектная модель УЖЕ есть в vanille-js .таки сколько весит это чудо?
>> И это ещё без учёта СЕО -- гугл и тындекс вряд ли будет ваши скрипты выполнять.
> контент страницы (без оформления) -- сёравно они будут получать как надо.
> js только для оформленияпардон, не понял. Для меня оформление - это CSS и графика. Что делает ЖС в данном случае?
>> и как это будет выглядеть? "пожалуйста, скачайте 500К жаваскрипта и 20М шаблонов, и браузер вам всё сгенерит через полчаса"?
> тоесть по вашему -- клиентская стороная такая прям тормознутая, что аж пол
> часа генерирует, а серверу это раз плюнуть? :-) [или думаете что
> Javascript-тормазнутее чем PHP? лол]1. Представьте себе, серверу это раз плюнуть. Когда на серваке RAID и пара десятков гигов ОЗУ, то выполнение операции str.replace(x, context[x]) в сотни раз быстрее, чем работа с объектной моделью DOM, типа какой-нить поганый ИЕ, который на каждый div выделяет 5М памяти. (Да и на обычном компе эта операция быстрее, если не в сотни, то в 10-ки раз).
Жаваскрипт сам по себе может и быстрее, но вы ж работаете с DOM. И да, 100К jquery парсится может и быстрее, чем 100К РНР, но всё равно долго Ж)> ды вообще-то реальность такова что зачастую сервера в несколько раз слабее чем
> клиентская сторона :-)зачастую да, но сайт не может "зачастую работать". Либо работает, либо вы лох.
> зайди на страничку Google App Engine например и узнай какие там выделяются
> мощности для хостинга сайтов :)да ты б ещё про narod.ru упомянул.
если нужно, чтобы сайт нормально работал, то не жалко и нормальный выделенный сервак, который 100$/мес стоит-то всего-то. А если жалко бабла на хостинг, то о каких там ЖС-фреймворках говорить, пишите на жумле млин.> (а если хоститься на shared-хостингах -- то там обычно разрешают использовать не
> более 1~3% от ядра процессора. и это кстате издевательство!)Во-первых, 1-3% не от мгновенной нагрузки, а суммарной статистической. Т.е. каждая задача получает столько проца, сколько возможно, если за сутки оно не превысило 1-3%. Во-вторых, ещё раз повторю, что парсинг шаблона - это настолько быстрая операция, что сравнится с парсингом самого похапэ (у кого похапэ). Так что нет смысла экономить на спичках, знаете ли.
> Для меня оформление - это CSS и графика.ну может быть ты являешься именно тем одарённым программистом, который способен написать даже Тетрис на CSS.
в этом случае может быть JS тебе и не нужен :)
другие некоторые люди -- даже используют less (lesscss.org) для того чтобы не видеть в глаза чистый CSS :) ...
и да -- сайт написанный с использованием less вместо css -- считай что написан с оформлением на Javascript (как минимум на 70% всей оформительской работы).
> И да, 100К jquery парсится может и быстрее, чем 100К РНР, но всё равно долго Ж)
и да, не пиши пожалуйста больше про jquery (в контексте сугубо шаблонизатора).
потому что зайди на http://www.linux.org.ru и зацени что там тоже подгружается jquery... ОДНАКО сайт там шаблонизируется сёравно на сервере а не на клиенте.
вопрос -- зачем же тогда они погрузили (по твоему "лишние") 100К? ммм?
ответ -- потомучто jquery бывается часто нужен совсем даже и не для целей шаблонизации :)
>> Для меня оформление - это CSS и графика.
> ну может быть ты являешься именно тем одарённым программистом, который способен написать
> даже тетрис на CSS.
> в этом случае может быть JS тебе и не нужен :)не передёргивайте)) речь не о динамике на стринице, а о замене ШАБЛОНОВ жавасриптом.
> другие некотоыре люди -- даже используют less (lesscss.org) для того чтобы не
> видеть в глаза чистый CSS :) ...другие некотоыре люди, даже большинство пожалуй, для этой цели используют других некотоыре люди)))
> и да -- сайт написанный с использованием less вместо css -- считай
> что написан с оформлением на Javascript (как минимум на 70% всей
> оформительской работы).ну можно вспомнить и javascript stylesheet.
Это только не меняет главного - необходимость хтмл-шаблона.А речь была, напомню, о замене ШАБЛОНОВ жавасриптом.
> А речь была, напомню, о замене ШАБЛОНОВ жавасриптом.окей. уговорил меня.
наймём на работу бомжа на официальную должность директора. будем платить ему 5 тысяч рублей в месяц и просить подписывать все нужные нам бумажки без прочтения им.
....и говорить (между собой) что это наш настоящий директор фирмы!
[аналогия: директор_фирмы -- шаблонизация_на_сервере]
>> А речь была, напомню, о замене ШАБЛОНОВ жавасриптом.
> окей. уговорил меня.
> наймём на работу бомжа на официальную должность директора. будем платить ему 5
> тысяч рублей в месяц и просить подписывать все нужные нам бумажки
> без прочтения им.
> ....и говорить (между собой) что это наш настоящий директор фирмы!
> [аналогия: директор_фирмы -- шаблонизация_на_сервере]очень уместная аналогия.
я не понял, что ты хотел сказать.есть хтмл верстальщик, который стоит 20тр/мес. Есть жаваскрипт программер, который стоит ещё 20тр.
Есть хостинг, который стоит 200р/мес. Есть VPS за 1000р/мес. Выделенный сервак - 3000р.
Теперь вопрос: при том, что в случае генерации шаблонов на стороне клиента кол-во работы верстальщика не изменится (кто-то ж должен верстать), а кол-во работы жс-програмера увеличится пусть даже на 50%, то что ты сэкономишь на хостинге? Или ты и есть тот самый директор за 5тыс, который тока бумажки подписывает и всем говорит, как хорошо заниматься ерундой?кстати то что ты свои посты правишь - очень неудобно читать и понимать что ж ты там хотел сказать.
> кстати то что ты свои посты правишь - очень неудобно читать и понимать что ж ты там хотел сказать.а думаешь мне самому удобно -- когда то одна мысль в голове, то сразу другая?
> кол-во работы жс-програмера увеличится пусть даже на 50%
ну вобщем-то я делаю вывод -- что я обозначил проблему, но не указал эффективные способы её решения.
проблема: делать оформление надо на клиентской стороне, а не на серверной.
способ решения, который не увеличит савакупную трудоёмкость для коллектива трудящихся -- я не знаю, на сегодняшний момент.
может быть завтра кто-то уже придумает решение, которое позволит делать это, не заставляя JS-программиста трудиться больше чем нужно.
* * * * * * * * * * * * * * * * * *
вот вы вообще сранные люди! я написал например что "что-то-не-так, это надо исправлять!", а вы сразу накидываетесь на меня со словами "не трогай, мы работаем так уже много лет и не хотим ничего менять!"
ну работали вы как работали, фиг с вами. но завтра например кто-то сделает новую рационализацию на эту тему, а вы останитесь в Ж^Wхвосте прогресса.
думайте немножко шире! может быть даже вы сами сделаете эту рационализацию, а не кто-то другой! в случае если не будете пытаться загонять себя в рамки "мы так работали уже долго и не будем ничего менять".
> а думаешь мне самому удобно -- когда то одна мысль в голове, то сразу другая?ну это и видно. Это значит только, что ты сам не знаешь что хочешь сказать))
> ну вобщем-то я делаю вывод -- что я обозначил проблему, но не указал эффективные способы её решения.
не обозначил проблему, а указал неэффективный способ создать себе кучу гемора. имхо.
> проблема: делать оформление надо на клиентской стороне, а не на серверной.
нет такой проблемы, потому что оформление (не путать с анимацией и всякой мелочёвкой) - не имеет к клиенту, а следовательно, к ЖС, никакого отношения. Клиент нужен, чтобы РЕНДЕРИТЬ оформление. А не для того, чтобы его генерировать.
> способ решения, который не увеличит савакупную трудоёмкость для коллектива трудящихся -- я не знаю, на сегодняшний момент.
> может быть завтра кто-то уже придумает решение, которое позволит делать это, не заставляя JS-программиста трудиться больше чем нужно.да, представь себе, уже придумано -- и придумано до того, как появился жавасрипт: делать шаблоны на сервере =))))
> вот вы вообще сранные люди!
я надеюсь ты имел в виду "странный", а не сранный. Смысл немного разный, не?
> я написал например что "что-то-не-так, это надо исправлять!",
нет, ты написал, "сегоднящняя ситуация совершенно нелепа!" -- забыл? Это не похоже на "что-то не так", а похоже на то, что кругом одни бараны, а ты один умный.
И ответил ты это на
>продолжают генерить HTML на серверной стороне.То есть, ты предложил, очевидно, генерить HTML на клиентской стороне. Точнее, "полностью подписался".
а потом ты уже забыл и про это. И ушёл в философию. Не надо думать, что всё старое -- дерьмо только потому, что оно старое. И не надо думать, что ты самый умный, а остальные -- бараны, которые ничего не хотят менять.
> я надеюсь ты имел в виду "странный",да. извините.
> нет, ты написал, "сегоднящняя ситуация совершенно нелепа!" -- забыл?
ну разумеется нелепая, что до сих пор всё так (2013 год уже как ни как)
> кругом одни бараны, а ты один умный.
ну эт уже ваши фантазии. я бараном никого не называл :) [ну если не считать опечатку в слове "странные" :)]
>> И да, 100К jquery парсится может и быстрее, чем 100К РНР, но всё равно долго Ж)
> и да, не пиши пожалуйста больше про jquery (в контексте сугубо шаблонизатора).не тыкай мне пожалуйста больше что мне писать, что мне нет.
> потому что зайди на http://www.linux.org.ru и зацени что там тоже подгружается jquery...
> ОДНАКО сайт там шаблонизируется сёравно на сервере а не на клиенте.
> вопрос -- зачем же тогда они погрузили (по твоему "лишние")
> 100К? ммм?так это к тебе вопрос, друг шаблонизатор.
который сам так и не ответил на вопрос, зачем нужны шаблоны на жавасрипте, если всё равно хтмл генерится на серваке.
Динамика на клиенте нужна для контента, а не для оформления. Что это вообще за "оформление"?
>продолжают генерить HTML на серверной стороне.А какие аргументы против этого? Хочется понять, ибо я уверен, что так и должно быть, а не моя личная сборка текста с помощью конструктора от всякого сайта, который я посещаю.
а что не так? Генерация html на стороне сервера занимает микросекунды, а на клиенте - десятки миллисекунд.
Все так пока пользлвателей не становится больше, по вашему расчету, 10000*количество ядер сервера. Что в современных реалиях обычное явление.
при чем тут 10000 ядер? Со 100к уников/сутки влегкую справляется один обычный сервак. Если у вас миллионы в сутки - вам всё-равно менять архитектуру придётся и шаблоны на JS будут лишь незначительной частью контента. Владельцы бложиков с низким трафиком, такие смешные, вечно ждут наплыва фанатов.
Лол рельсы генерят страницу на сервере медленнее чем хром на клиенте. Они и запускаются несколько минут.
Не знаю как джанго.
> Лол рельсы генерят страницу на сервере медленнее чем хром на клиенте. Они
> и запускаются несколько минут.
> Не знаю как джанго.Проблемы апачей шерифа не волнуют. Машинисты бронепоезда - отдельная каста)
> рельсы [...] и запускаются несколько минутОткопать, что ли, первый пентиум и посмотреть, сколько они там на самом деле стартуют...
на нём наверно уже Linux загрузиться не сможет :(
> на нём наверно уже Linux загрузиться не сможет :(Сможет. И на 486 сможет. Да, современный. Хотя на 486 я последний раз slackware 11.0 запускал. на p1 запускал squeeze, натуральную, без каких-либо изменений. с иксами и приложениями.
ну ладно, набор x86-инструкций -- это тоже интересная тема.а сколько щаз нужно оперативки для загрузки ванильного ядра (чтобы доковылять до момента когда оно подключит swap) ?
одно время помню, для Fedora нужно было минимум 64M -- что впрочем уже много (во времена пентиумов 1 -- было по 16M на компьютерах в среднем. Windows98 работал с большими тормозами)
Абстрактный Линукс сможет, а подавляющее большинство нынешних дистрибутивов - нет, не сможет. Даже не поставятся.
> Абстрактный Линукс сможет, а подавляющее большинство нынешних дистрибутивов - нет, не сможет. Даже не поставятся.Подавляющее большинство дистрибутивов я не знаю. Есть моя персональная большая четвёрка. Это Debian, Ubuntu, Slackware, Archlinux.
Debian поставится, вариант EmDebian ещё больше память экономит благодаря сборке "без никто". ArchLinux - только 686. Slackware - поставится ли новейшая - не знаю, но 11.0 точно поставится и будет работать.
То, что кто-то пишет системы, где "1 гб не хватит на всех", и кто-то этим пользуется, это не значит, что linux не может так работать. ЛУЧШЕ МЕНЬШЕ, ДА ЛУЧШЕ.
При генерации HTML на стороне клиента:
1) Как можно разрешить проблему со справочниками, расположенными в памяти? Если не хочется всё время писать JOINы. Например, пользователи по кодам удобно хранить в памяти. Обращение за каждым пользователем будет значительно медленнее.
2) Если используется ORM с "ленивой" выборкой. Как предугадать, что запросит шаблон?
3) Существует ли на JS хороший движок шаблонов подобный JSP с JSTL? Чтобы не получать HTML склейкой текста.
По вопросу со справочниками проблема более общО: как заменить объекты, доступные по ссылкам в памяти в серверном шаблонизаторе на JSON объекты? Т.е. есть у нас 100 записей, ссылающихся на некого пользователя. В серверном шаблоне это один объект в памяти, к которому можно обращаться, получать поля и выводить нужные. На стороне клиента как я понимаю можно передать только копию привязанную к каждой из записей.
в шаблонах Jango - D пропало.
над по-больше таких новостей, где есть слово ``Python 3''......чтобы у разработчиков новых python-библиотек НЕ возникало ощущения что мир сидит всё ещё на Python 2.X :)
# P.S.: например недавно вышел ``Bind 10'', и в заголовке новости о нём тоже надо было большими буквами написать ``Python 3'' :-)
Ой, да ладно, по хорошему на python 2.7 можно ещё 10 лет прожить. Потому что сложно быть идеальнее. :)
точно точно! вот именно так некоторые люди и думают :-)только вот ты щаз сарказм написал, а некоторые люди думают так без сарказма :)
> точно точно! вот именно так некоторые люди и думают :-)Я именно так и думаю. Меня устраивает python 2.7. Правда. Я ничего не теряю, пользуясь им. :)
ты меня режишь беж ножа
>> точно точно! вот именно так некоторые люди и думают :-)
> Я именно так и думаю. Меня устраивает python 2.7. Правда. Я ничего
> не теряю, пользуясь им. :)Кроссплатформенность страдает. В pyhton3 по умолчанию юникод, даже в винде. В python2 русские и другие национальные тексты linux <-> windows страдают. Ну и не нужно писать:
#-*-coding:utf8-*-
from __future__ import division .....
arg1 = sys.argv[1].decode(locale.getpreferredencoding())path1 = os.path.join(os.path.dirname(__file__.decode(sys.getfilesystemencoding())), arg1)
# о нет! когда же эти мучения закончатся!!!!
# P.S.: это просто мысли вслух, а не ответ камраду nn
>
> arg1 = sys.argv[1].decode(locale.getpreferredencoding())
> path1 = os.path.join(os.path.dirname(__file__.decode(sys.getfilesystemencoding())),
> arg1)
> // о нет! когда же эти мучения закончатся!!!!
>Контекстная проблема. Проще исправить две таких проблемы в год, с помощью одной строчки, чем по такой мелочи переделывать вообще всё.
> Контекстная проблема. Проще исправить две таких проблемы в год, с помощью одной
> строчки, чем по такой мелочи переделывать вообще всё.ды, я согласен вобщемто! но есть два "но":
1. исправить проще, но зачстую почему-то люди не исправляют. например путают где должно быть ``locale.getpreferredencoding()'' а где должно быть ``sys.getfilesystemencoding()'', а ещё чаще -- вообще оперируют с utf-8-байтовыми строками, вместо unicode-строк. добавляя при этим столько мусора в код, что его уже не разгрести никогда в жизни!
2. полностью переписать что-то на python-3 сложно! поэтому лучше сразу начать делать что-то для python-3 , чем плодить python-2-сущности.
пока мы тут болтаем -- наверняка сегодня уже кто-то сдал пару новых велосипедов на python.. и вот интересно, если он выбрал python-2 а не python-3 -- то печаль
> 1. исправить проще, но зачстую почему-то люди не исправляют.Какие люди?
> 2. полностью переписать что-то на python-3 сложно!
А почему непременно нужно переписывать? Сейчас работает? Работает. Хорошо работает? Хорошо. И все модули на месте. Куда бежать? Технология не должна быть ради технологии, это хорошо, что есть ветка для бегущих, и ветка для тех, кому и постоять неплохо...
> пока мы тут болтаем -- наверняка сегодня уже кто-то сдал пару новых
> велосипедов на python.. и вот интересно, если он выбрал python-2 а
> не python-3 -- то печаль... ну да, и debian stable тоже не нужен, все должны сидеть на транках. :)
в debian steble, кстати, вообще 2.6 :)
>> 1. исправить проще, но зачстую почему-то люди не исправляют.
> Какие люди?библиотеками которых мы пользуемся. (для python2 очень много готовых библиотек).
>> 2. полностью переписать что-то на python-3 сложно!
> А почему непременно нужно переписывать? Сейчас работает? Работает. Хорошо работает? Хорошо.
> И все модули на месте. Куда бежать? Технология не должна быть
> ради технологии, это хорошо, что есть ветка для бегущих, и ветка
> для тех, кому и постоять неплохо...друг. ды не надо переписывать! :)
ты главное новый проект постарайся не начинать на python2 :) .. это всё о чём я тебя прошу
> ты главное новый проект постарайся не начинать на python2 :) .. это
> всё о чём я тебя прошуМне не нужна идеальность для всех. Мне нужна та идеальность, которая есть в python2. Он уже умеет всё, что нужно мне.
>> ты главное новый проект постарайся не начинать на python2 :) .. это
>> всё о чём я тебя прошу
> Мне не нужна идеальность для всех. Мне нужна та идеальность, которая есть
> в python2. Он уже умеет всё, что нужно мне.Я думаю проблема надумана.
Python2.7 + __future__ = Python3.3 , практически.
Библиотеки подтягиваются потихоньку, другие имплементации вроде pypy,jython тоже.
Ну а связи с переходом Гвидо в Dropbox, думаю в версии 3.4,3.5 будет революция, у Dropbox очень много наработок по управлению памятью.
> в debian steble, кстати, вообще 2.6 :)а так же 3.1
но лучше ориентироваться на 3.2 и 3.3Debian Wheezy уже Release Candidate:
http://www.debian.org/devel/debian-installer/News/2013/20130217
>>Таки и в django тоже. И web2py тоже. И в play (java) и liferay (java).
> man GIL$man GIL
Нет справочной страницы для GIL>это по поводу django и web2py.
это по поводу "слышал звон, да не знаю где он".
> play это вообще для Scala которая сама по себе напрягает.
Play это для java, но если хотите то можно и для scala.
>liferay это вообще для порталов на java.
liferay -- это конструктор, можете и сайт на нем сделать, можете портал, можете отдельное webapp.
>Java как язык тут не котируется
Тут это где?
>вообще т.к. на нём дольше писать.
Чем на чём?
>>Какой ужас :). А еще оборудование сервера не устойчиво к взрывам мощностью более мегатонны в тортиловом эквиваленте.
> ну ты похоже тут потролить пришёл, а я серьёзно. Ммы тестировали, 10
> тыс. конектов для tornado потолок.Ну раз ты серьезно, то представься. Я такой-то вот Ф.И.О.из такой вот серьезной конторы (№ школы), вот ссылка на мою контрольную работу по информатике.
В общем качество вброса страдает.
Многие научные проекты уже перешли на python3, и именно из этой сферы сейчас идут многие оптимизации по скорости.http://www.scipy.org/FAQ#head-288204f886c0a120754d189f434864...
http://pandas.pydata.org/pandas-docs/stable/install.html
http://matplotlib.org/users/whats_new.html#python-3-x-support
http://ipython.org/Да кстати:
PyPy уже преодолел рубеж 65% прохождений тестов на регрессию относительно текущего CPython(Py3k)Если посмотреть Py-багтрекер, все оптимизации направлены только на Python3.XX версии, так что переход будет ускоряться по мере их принятия.
PS:
Лично для меня, даже если просто работать со стандартной библиотекой python3, то просто приятней и понятней с ней работать в отличии от бардака который в python2. Не знаю как другим.
Для забеглых некростудентов: бесполезно рекламировать своё трупьё тем, кто предпочитает живое.PS 2 nn re #84: тред пересклеился, но сами же видите -- эти чудики сюда не за тем ходят...
PPS re #94: так точно, но Ваше сообщение уж больно хорошо резюмировало :)