Капучино, Django, AJAX и все это вместе - рассмотрите мою архитектуру! - PullRequest
Новая
       18

Капучино, Django, AJAX и все это вместе - рассмотрите мою архитектуру!

6 голосов
/ 25 октября 2009

Я пытаюсь разобраться с капучино. Я бы хотел, чтобы мои коллеги из StackOverview рассмотрели нижеприведенную архитектуру и посмотрели, имеет ли она смысл - цель состоит в том, чтобы использовать уникальные преимущества Django и Cappuccino, не удваивая при этом, где технологии перекрываются ...

Когда веб-браузер запрашивает «дружественный» URL (например, /, / статьи и т. Д.):

  • DJango's urls.py соответствует этому Посмотреть.
  • Вид, а не делать DJangos типичная работа по заполнению шаблон с местным населением,
    возвращает маленький HTML-код заглушки, используемый в приложение капучино напрямую.
  • Клиент получает Капучино HTML
  • Клиент запрашивает Objective J JS URL, упомянутые в заглушке HTML
  • Приложение для конечного пользователя выполняется и отображается в браузере

В браузере теперь есть работающее приложение. Когда пользователь делает что-то запрашивает что-то с сервера:

  • Браузер отправляет XMLHTTPRequest на URL.
  • URL-адрес Django соответствует этому Посмотреть.
  • Представление работает, возможно, взаимодействует с моделью БД. Но вместо того, чтобы возвращать шаблон, Django возвращает немного JSON.
  • Клиент получает JSON, и делает все, что нужно.

Имеет ли это смысл? У нас все еще есть преимущество дружественных URL-адресов и базы данных, которая создается для того, чтобы мы смоделировали наш код. Однако вместо того, чтобы использовать шаблоны, мы предоставляем страницы-заглушки Cappuccino и ответы JSON, чтобы дать пользователям нечто большее, чем настоящее приложение, а не механизм HTML-шаблонов.

Возможно, есть лучший способ сделать что-нибудь? Что используют другие Pythonistas? Спасибо за ваш отзыв.

1 Ответ

4 голосов
/ 25 октября 2009

Для сайта с низким трафиком было бы неплохо использовать слой маршрутизации Django, но если вы планируете получать значительный объем трафика, вы можете рассмотреть возможность использования заглушками вашего прокси-сервера.

В остальном, это работает, и сообщество TurboGears делает это годами (я был комментатором TG, так что я обычно использую). Архитектура TG по возврату словаря в шаблон делает это тривиальным, поскольку вы просто установили json в качестве механизма шаблонов.

Делать то же самое в Django не намного сложнее. Просто используйте инструменты serialization , чтобы записать результат в ответ, вместо использования шаблонных вызовов.

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

FWIW, я считаю, что с Sproutcore легче работать, чем с Cappuccino, если вы заинтересованы в более тяжелых средах с непрогрессивными улучшениями.

...