Передающие Данные Python к JavaScript через Django

LINQ к SQL на самом деле действительно хорош к модульному тесту, поскольку это имеет способность создать базы данных на лету из того, что определяется в Вашем DBML.

Это делает действительно хорошим протестировать уровень ORM путем создания DB через DataContext и наличия его пустой для начала.

я покрываю его на своем блоге здесь: http://web.archive.org/web/20090526231317/http://www.aaron-powell.com/blog/may-2008/unit-testing-linq-to-sql.aspx

52
задан Peter Mortensen 11 December 2009 в 03:02
поделиться

5 ответов

nb см. Обновление 2018 внизу

Я рекомендую не помещать много JavaScript в ваши шаблоны Django - его, как правило, сложно писать и отлаживать, особенно по мере расширения вашего проекта. Вместо этого попробуйте записать весь свой JavaScript в отдельный файл сценария, который загружает ваш шаблон, и просто включите в шаблон только объект данных JSON. Это позволяет вам делать такие вещи, как запускать все ваше приложение JavaScript через что-то вроде JSLint , минимизировать его и т. Д., И вы можете протестировать его с помощью статического файла HTML без каких-либо зависимостей от вашего приложения Django. Использование такой библиотеки, как simplejson, также экономит ваше время, затрачиваемое на написание утомительного кода сериализации.

Если вы не предполагаете, что создаете приложение AJAX, это можно просто сделать так:

В представлении:

from django.utils import simplejson


def view(request, …):
    js_data = simplejson.dumps(my_dict)
    …
    render_template_to_response("my_template.html", {"my_data": js_data, …})

] В шаблоне:

<script type="text/javascript">
    data_from_django = {{ my_data }};
    widget.init(data_from_django);
</script>

Обратите внимание, что тип данных имеет значение: если my_data - это простое число или строка из контролируемого источника, не содержащая HTML, например отформатированная дата, никакой специальной обработки не требуется. Если есть возможность получить ненадежные данные, предоставленные пользователем, вам необходимо очистить их, используя фильтры вроде escape или escapejs , и убедитесь, что ваш JavaScript обрабатывает данные безопасно, чтобы избежать межсайтовый скриптинг атаки.

Что касается свиданий, вы также можете подумать о том, как вы проводите свидания. Я почти всегда считал, что проще всего передать их как временные метки Unix:

В Django:

time_t = time.mktime(my_date.timetuple())

В JavaScript, если вы сделали что-то вроде time_t = {{time_t}} с результатами фрагмента выше:

my_date = new Date();
my_date.setTime(time_t*1000);

Наконец, обратите внимание на UTC - вы хотите, чтобы функции даты Python и Django обменивались данными в формате UTC, чтобы избежать неприятных сдвигов от местного времени пользователя.

РЕДАКТИРОВАТЬ: Обратите внимание, что setTime в javascript выражается в миллисекундах, тогда как вывод времени .mktime - секунды. Вот почему нам нужно умножить на 1000

Обновление 2018: мне все еще нравится JSON для сложных значений, но за прошедшее десятилетие API данных HTML5 достиг почти универсальной поддержки браузеров , и это очень удобно для передачи простых значений (не из списка / dict), особенно если вы хотите, чтобы правила CSS применялись на основе этих значений, и вас не волнуют неподдерживаемые версии Internet Explorer.

<div id="my-widget" data-view-mode="tabular">…</div>

let myWidget = document.getElementById("my-widget");
console.log(myWidget.dataset.viewMode); // Prints tabular
somethingElse.addEventListener('click', evt => {
    myWidget.dataset.viewMode = "list";
});

Это удобный способ предоставить данные CSS, если вы хотите установить начальное состояние просмотра в шаблоне Django и автоматически обновлять его, когда JavaScript обновляет атрибут data- . Я использую это для таких вещей, как скрытие виджета выполнения до тех пор, пока пользователь не выберет что-то для обработки, или для условного отображения / скрытия ошибок на основе результатов выборки или даже для чего-то вроде отображения количества активных записей с использованием CSS, например # some-element :: after {content: attr (данные-активные-передачи); } .

после {content: attr (данные-активные-передачи); } .

после {content: attr (данные-активные-передачи); } .

78
ответ дан 7 November 2019 в 09:10
поделиться

Встраивание Java Script в шаблон Django скорее всегда плохая идея.

Скорее , потому что из этого правила есть некоторые исключения.

Все зависит от вашего сайта с кодом Java Script и его функциональности.

Лучше иметь отдельные статические файлы, такие как JS, но проблема заключается в том, что каждому отдельному файлу нужен другой механизм подключения / получения / запроса / ответа. Иногда для маленького, двухлинового кода os JS, чтобы поместить это в шаблон, затем используйте механизм django templatetags - вы можете использовать его в других шаблонах;)

Об объектах - то же самое. Если на вашем сайте есть конструкция AJAX / web2.0, вы можете добиться очень хорошего эффекта, добавив некоторые операции подсчета / математики на стороне клиента. Если объекты небольшие - встраиваются в шаблон,

1
ответ дан 7 November 2019 в 09:10
поделиться

Вы можете включить