All articles, tagged with “javascript”

python standard libs for sculpt and pycow

Идея следующая — взять pypy, скомпилировать его с помощью pycow и посмотреть что получится. Результатом должен полный набор стандартных библиотек python которые можно будет запользовать как для sculpt так и для pycow .

Единственное что сдерживает — непонятка с алгоритмом работы import. В том плане что ни в sculpt, ни в pycow import не реализован вообще.

И это обоснованно — потому что действительно неочевидно — как организовывать import в удаленный клиент. Плодить кучу файлов и переспрашивать их с помощью XmlHttpRequest — плохо, потому как много запросов. Упаковывать весь python в один файл — тоже ни разу некомильфо, потому как получится один большой файл, в котором будет много лишнего.

Моя борьба с javascript ч.3.

Вроде бы все готово. Для компиляции осталось пару строк функции компрессора, которая является просто враппером для pycow.

pycow_compressor/__init__.py

from django.conf import settings
from pycow.pycow import translate_string

def pycow(*args, **kwargs):
    try:
        return translate_string(args[0], warnings = False)
    except:
        if settings.DEBUG:
            raise
        else:
            return ""

Итого, для прозрачной компиляции python->javascript из шаблонов нужно:

  • Использовать python2.6
  • Установить django-compressor
  • Задать в settings.py такую настройку(там еще добавлена настройка для clevercss)
  • Скачать и установить в проект собственно компилятор pycow
  • Скачать и установить в проект файл pycow_compressor/__init__.py, содержащий указанный выше код (и небольшие дополнения, описанные ниже;) ).

После этого, в базовом шаблоне пишется следующее:

{% compressed “py” “pycow_file”%}

В остальных, унаследованных/включенных шаблонах подключaются .py файлы:

{% compress “py” “media/pycow/somepage_script.py”%}

Которые (алллилууйя-братья-и-сестры-не-забудьте-пожертвовать-нашей-церкви-в-кассе-на-выходе!) будут спакованы и скомпилены в один .js файл и выданы в страничку как тег <script> в том месте, где находится {% compressed "py" "pycow_file"%}

Небольшие дополнения

Если сравнить код указанный в начале поста, и код находящийся по ссылке, можно увидеть что они отличаются. Отличие обусловено тем, что без импорта жить плохо, а в pycow этот вопрос не решен вообще.

Хотелось бы, но модифицированный pycow компрессор тоже ничего ниоткуда не импортирует. Он расширяет класс компилятора таким образом, чтобы идентификаторы, которые были указаны командой import, считались классами и инициализировались с конструкцией new. Таким образом, становится возможным корректно использовать ранее загруженные в браузер классы (например классы эффектов mootools).

Моя борьба с javascript ч.2.

Ок. Компилятор выбран. Однако, это только половина задачи. Вторая половина задачи выходит из того факта, что, если я хочу подключать .py файлы из шаблона — мне нужно кеширование и компиляция кода в зону static. Я совсем не хочу, чтобы при каждом рендере шаблона вызывался довольно тяжелый компилятор. Кроме того, для установки сервера в productive режим, у меня на руках должен оказаться работающий набор скомпилированных скриптов. А еще, я хочу не думать о том, что библиотеки могут загружаться на страницу позже кода. Сопроводительные задачи должен решать робот. Для этой цели собственно и был написан django-compressor.

Вообще, django-compressor довольно спорный tool. Спорный с точки зрения необходимости — гораздо правильнее строить приложение так, чтобы задачи которые решает компрессор, вообще не вставали. Гораздо правильнее использовать CSS для стилей, и скрипт для клиентской части. Но питон силен именно тем, что позволяет быстро делать прототипы. А в прототипе главное не оптимальность. В прототипе главное — быстро и эффективно перейти от этапа создания среды для эксперимента, к собственно эксперименту. Компрессор был написан какраз исходя из того, что сначала должен быть создан прототип, и создан он должен быть быстро.

Про компрессор

Если коротко, то компрессор действует следующим образом — он берет все, что находится между тегами {% compress "group_name" %}{% endcompress %}, и переставляет “это все” в то место, где находится тег {%compressed "group_name" "compiler_name"%}. Перед подстановкой проверяется наличие контрольной суммы в кеше компрессора, и на этом основании принимается решение — нужна ли компиляция с использованием компилятора compiler_name или можно просто вернуть содержимое файла (или путь к файлу) соответствующее контрольной сумме. Компрессор умеет разбирать наследование шаблонов, инклуды, блоки и переменные. Поэтому можно спокойно выстраивать удобную для себя структуру шаблонов, не оглядываясь. Содержимое нескольких тегов {% compress %} будет встречаться в на странице в том же порядке, в котором происходил рендер.

Компилятор задается в settings.py как элемент словаря COMPRESSOR_COMPILERS следующего вида:

"pycow_file":{"result_wrapper":"""<script type="application/javascript" src="%(rendered)s"></script>""", 
                        "returns_url":True,
                        "extension":"js",
                        "compiler":"pycow_compressor.pycow"},

Здесь result_wrapper определяет, какой текст будет окружать результат компиляции. returns_url определяет что надо возвращать — путь в кеше к скомпилированному файлу или содержимое скомпилированного файла. extension определяет какое расширение указывать для скомпилированных в кеш файлов. compiler определяет где взять функцию для компиляции.

Вторым аргументом для функции компилятора будет передан контекст. Так что, если внешний компилятор умеет работать с контекстом — можно приютить и его. Обращаю внимание — контекст будет закеширован после первой компиляции. Отслеживать и кешировать изменения переменных контекста я считаю избыточным. Поэтому, изменения в контексте не будут отражаться в скомпилированном файле, но для верстки стилей с использованием clevercss - сойдет.

Это какбы все. Следует еще добавить, что в реальном мире, никто не захочет держать клиентский (или еще какой) код внутри шаблонов, поэтому есть тег {% compress_file "group_name" "file/path" %}, который позволяет вынести код в отдельный файл. Путь считается относительным к корню проекта.

Производительность компрессора

Особо не вникал, т.к. это утилита времени разработки. Сравнение времени рендера шаблона в 10 строк без компрессора и с ним дало отличие в 4 раза — с 0.018 до 0.056 секунд. Очевиден выиграш в количестве запросов к серверу, но за все надо платить.

Моя борьба с javascript ч.1.

Для моих мозгов сложные синтаксисы — это вообще беда. Потому, что на какомто этапе обдумывания будущего решения, часто случается так, что я понимаю, что не очень осознаю суть задачи и начинаю “ввязываться в бой с наличными силами”. То есть экспериментровать, писать в режиме “что вижу, то пою”. Питон позволяет такой подход (в разумных пределах) т.к. всегда можно без ущерба для психики, вернуться, пересмотреть/отрефакторить/выделить важное и выкинуть ненужное.

По правде говоря — меня раздражают почти все синтаксисы, кроме питонического. Во всех остальных языках, которые я щупал, визуальная сложность написанного кода растет по экспоненте от сложности задачи. В результате, программист, и так пригруженный сложностью задачи, оказывается под завалами собственного кода. А если мысль пошла извилистым, ну да, может не очень правильным путем — последующее распутывание превращается в редкое извращение, на которое скорее всего забьешь.

Выбор средств

Вообщето, задача компиляции python в js изначально выглядит не особенно сложной. Между этими языками много общего. Однако, если в голову приходит мысль насчет компиляции одного языка высокого уровня в другой язык высокого уровня — стоит как минимум проверить гугл, а как максимум — расслабится и перестать заниматься мечтательством. Несмотря на это, поверхностный осмотр гугла предоставил на выбор целых три варианта:

pyjamas

Выглядит привлекательно. Сначала. Пока не распакуешь и не осознаешь. Может быть, он неплох для создания десктопов, я не пробовал. Мне, для создания удаленных псевдодесктопных приложений, вполне годится Mozilla XUL. А для написания средних и малых web решений pyjamas вообще непригоден. Да, он способен превратить каждый браузер в отдельный сервер приложений. Наверно, если изгольнуться — туда можно вставить коннектор работы с БД, или SASL авторизацию. Однако, если перефразировать Петра Первого: “Клиентская станция перед лицом начальствующим должна иметь вид лихой и придурковатый дабы разумением своим не смущать сервер” (кажется, до меня ктото уже так перефразировал). Стремление сего фреймворка накрыть одной компиляцией все аспекты, включая генерацию html и css, слабо коррелируют современными моделями веб приложений.

Skulpt

Вот это то, что я называю “pythonic way”. Это мощная идея. Это будет “окно в браузер” для python. Он станет мостиком, который наконец заставит Mozilla, а потом и остальных, включить поддержку python в стандартный пакет. Но. Это все же еще не python:

>>>print type(object)
error:trying to str() undefined (should be at least null)

Но и не javascript (mootools загружен страницей)

>>>a = Fx.Morph()
завис .....

В общем вывод следующий: отслеживать, возможно поучаствовать, при наличии времени, но пока сыроват.

pycow

В одном из мануалов амбициозного пакета “PyGoWave”, который собирается стать провайдером Wave для всея питонщиков, было показано, как легко и красиво, некий pycow превращает python в javascript. Пакет содержит два простых и однозначных метода — translate_string и translate_file. Работает так, как заявлено, весит немного. Использует прозрачную модель объявления классов и базируется на стандартном модуле ast из python2.6. Использует кроссбраузерную библиотеку mootools. То что надо для web проектов, не претендующих на мировое господство.