Подтвердить что ты не робот

Ruby HAML с Django?

Хорошо, так что я действительно люблю HAML. В частности, мне нравится интеграция с RedCloth и BlueCloth, поэтому я могу использовать Markdown и Textile, смешанные с моей HAML.

Я также люблю Python и Django.

Итак, я хотел бы использовать HAML с Django. Теперь я уже понимаю, что есть некоторые попытки клонирования синтаксиса HAML в Python (SHPAML и другие). Я пробовал их, и пока они не плохие, я обнаружил, что я действительно хочу настоящую HAML. Частично для его синтаксиса, но и для таких вещей, как RedCloth и BlueCloth.

Итак, мой вопрос: как заставить HAML и Django работать вместе?

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

Quesiton 1: Я столкнусь с какими-либо проблемами здесь?

Я также задаюсь вопросом, есть ли способ заставить Python и Ruby играть вместе еще немного. Одна из моих идей заключалась в том, что я искал рубиновые процессы. Это, вероятно, плохая идея, но у кого есть какие-то мысли об этом?

Вопрос 2: Как использовать Python для вызова реального Ruby HAML?

Наконец, если кто-то знает о реализации Python реализации HAML, которая является полной, и которая поддерживает либо Textile, либо Markdown, а также plaintext passthru, тогда дайте мне знать.

Вопрос 3: Есть ли полный перевод HAML на Python, включая поддержку Markdown или Textile?

Спасибо!

4b9b3361

Ответ 1

Вопрос 1: статические файлы HTML должны работать отлично (если вы не планируете использовать функцию оценки рубинов HAML для динамического контента). Я использую аналогичный путь на веб-сайте php с таблицами стилей SASS. Просто убедитесь, что вы запустили HAML в режиме просмотра каталога, прежде чем начинать взламывать;)

Вопрос 2: в то время как разворачивание рубинового процесса для создания HTML-кода возможно, но я не рекомендую его, потому что инициализация рубинового интерпретатора и загрузка необходимых файлов занимает много процессорных времен, поэтому лучше придерживаться статических файлов. Если вам нужна функция оценки рубина, чтобы включить в документ данные, созданные во время выполнения, вам лучше взглянуть на eventmachine и сделать его сервером (поэтому ваше приложение Django может подключиться к нему и запросить генерацию HTML, не открывая новое переводчик каждый раз).

Вопрос 3: может быть, это самое сложное. Там GHRML, который оставлен; SHPAML, который только реализует небольшое подмножество HAML, DMSL, который в настоящее время очень экспериментальный, но уже поддерживает большую часть HAML, а также вызывает код python, но не хватает поддержки Markdown или Textile. Но, видимо, нет альтернативы Ruby HAML, которая поддерживает все необходимые функции.

Ответ 3

В то время как это может стать большим количеством проблем, чем это стоит, возможно, возможно использовать платформу Java или .NET и все еще запускать ваше приложение Django в Jython или IronPython (с некоторыми незначительными корректировками, я уверен), а также иметь возможность использовать Ruby HAML gem через jRuby или IronRuby.

Я уверен, что в этом будут какие-то причуды, но я уверен, что это будет возможно.

Опять же, это, вероятно, намного больше проблем, чем это стоит (учитывая, что вам нужно будет перенести приложение на совершенно новую платформу), но было бы неплохо работать над проектом.

Ответ 4

Я настоятельно рекомендую вам не разблокировать какие-либо процессы из ваших представлений django, потому что накладные расходы значительны.

У вас должен быть постоянный рубиновый процесс для обслуживания ваших шаблонов для вас и вызывать его из вашего кода django. Я оставляю вам технологию IPC, но очевидный выбор будет либо своего рода технологией очередности сообщений, либо говорить HTTP через сокет для рубинового процесса.