Одна из неочевидных, но очень сильных сторон Django в том, что он заставляет проектировать веб-приложение правильно. В основном путем отказа включения в фреймворк вещей, которые слишком легко использовать неправильно.
Один из ярких примеров — отказ включать "поддержку ajax". Я взял это в кавычки, потому что это оксюморон: ajax не нуждается ни в какой особенной поддержке со стороны серверного кода. В подавляющем большинстве случаев, когда люди просят такую поддержку, они имеют в виду "я не знаю javascript, поэтому хочу чтобы фреймворк сделал все за меня". И несмотря на то, что это, наверное, хорошая цель сама по себе, на данный исторический момент это скорее всего выльется в то, что рано или поздно разработчик столкнется с тем, что автоматически сгенерированный javascript либо работает не так, как надо, либо не работает вообще.
Другой пример нашел только что в рассылке: некто написал middleware для вызова Django'вских view из приложения на Flash. Первые же два отзыва — "this is great!"
Почему-то я уверен, что ни один из тех людей, которые пойдут это использовать, потому что "this is great!", не будет задумываться, что сама идея полного, не регулируемого контроллером доступа к внутренней логике прямо из презентационного кода нарушает модель работы веба как таковую. Я не говорю, что так никогда нельзя делать, но это тот случай, когда надо четко себе представлять, как работает HTTP, как не поломать кеширование, кнопку "Назад", занесение закладок... Но скорее всего из этого получится очередной "монстрик", слепленный из самых модных трехбуквенных сокращений, который будет бесполезен, и которого невозможно развивать без полного переписывания кода.
Я надеюсь, что такая штука не попадет в официальный пакет приложений Django.
Комментарии: 12
Вы правы, Иван. Для таких вещей, как ajax есть свои фреймворки: YUI или Django
greg, оговорка прям по Фрейду. Наверное, имелось ввиду dojo?
Согласен, но с оговорками. Некоторые приложения изначально предпологают работу с AJAX и, естественно, поддержка этой возможности со стороны сервера естественна. К пимеру Divmod'овская Athena. При запросе клиента к активной странице, Nevow (это фреймворк Divmod) создает экземпляр класса (реализующий функционал активной страницы), который существует до тех пор, пока клиент в этом заинтересован (открыта страница или нет иного прерывания связи).
..bw
В особенной не нуждается, но, например, не мешало
бы IMHO добавить стандартную библиотеку для JSON
прямо в Django. Что-нить типа JOSN_Response(object).
По поводу генерации автоматического JavaScript
кода из питона. Во-первых есть совсем не плохой
проект pype с его javascript backend. Во-вторых JS2
очень сильно приближает JS к питону. С таким же
успехом можно предлагать не использовать С++ а
писать асме т.к. например под винду MSVC компилер
иногда очень сильно грешит. Ошибки возможно будут, но
скорее, я думаю, что-нить типа pycheker заточат,
что-бы он проверял насколько выданный питон код
может быть адекватно преобразован в JS.
Место про flash вообще не понял ((.
Причем там закладки,назад-вперед? Во flash ничего
этого и так не работает. И не будет. Знать "как
работает HTTP" для этого вообще не нужно - ровно как и
при написании AJAX приложений, ну а над кешированием
промежут. данных ни flash ни Ajax вообще никогда не
заморачивались. Пусть делают как могут - если оно
будет нужно потом доведут до ума кэширование.
Как это "не регулируемого"? Снаружи доступны только
те методы, которые Вы туда выставите. Не может же
flash сказать "исполни мне ф-цию get_tempo_data со
строки 10 по 25 и верни переменную tempo_results".
Он просто вызовет один из торчащих наружу методов.
И разве AJAX это не то-же самое? Его аналог для flash нужен и соотв. поддержка таких механизмов в Django не
помешает.
P.S. flash ненавижу. Но используется он много
и его поддержка была-бы неплохим подспорьем в
продвижении Django.
Питоновский simplejson полностью включен в Django. Django использует его в своем модуле сериализации, где кроме json поддерживается еще XML и Питон. Причем, сериализовать можно удобно прямо Django'вские queryset'ы.
Я не про синтаксис, он может быть каким угодно. Я о том, что текущее положение дел в javascript'е таково, что его автоматическая генерация на сервере может приводить и приводит к проблемам. На нее нельзя полагаться как на всегда работающую. А значит не изучать, как это работает, нельзя.
Иван, а как на Ваш взгляд должна выглядеть примерная архитектура django-based приложения с клиентом на flash?
Не могу ответить прямо, потому что никогда ничего такого не делал. Если речь идет о вебе, то я всеми силами советую вообще отказаться от идеи закрытого клиента (Flash, XUL и т.п.) Веб-приложения очень много теряют, когда начинают игнорировать экосистему веба. Для них перестают работать extension'ы, пользовательские скрипты всякие, они выключаются из поисковых механизмов и т.п. Если же речь о каком-то локальном решении, например для интранета или какого-то киоска, то тут, в общем-то, можно действовать по принципу "что хочу, то ворочу". Но, повторюсь, я с этим не работал.
Спасибо за ответ. Суть проблемы, на мой взгляд, в том, что Flash-анимация обладает притягательностью, которую на HTML'е не достичь. Отделы маркетинга, например, flash очень любят. И интерес к стандартым решениям (flash frontend + web base backend) достаточно велик.
В отличии от пользователей.
Верно.
Ненавижу флэш. ( Пока для Линукса девятый плэер не сделают , тут ответ однозначный )
Сделают, не сделают... Флэш действительно нужен очень редко. Фактически, я могу назвать только один случай, когда без него не обойтись - YouTube (и подобные).
Да не ставится Ваш Django нифига.
Уже пробую, с перерывом в полгода - воз и ныне там.