Внесение кода¶
Как и любой проект с открытым исходным кодом, django CMS всегда ищет мотивированных людей для внесения вклада в его исходный код.
В двух словах¶
Вот как вкратце выглядит процесс внесения взносов:
Форк нашего репозитория GitHub, https://github.com/django-cms/django-cms.
Работайте локально и вносите изменения в свой репозиторий.
Когда вы почувствуете, что ваш код достаточно хорош для включения, отправьте нам запрос на перенос.
После этого, пожалуйста, присоединитесь к Slack Channel> нашей рабочей группе Pull Request Review (#workgroup-pr-review). Эта группа дружественных членов сообщества занимается рассмотрением запросов на доработку. Сообщите о своем PR и найдите «pr review buddy», который будет рассматривать ваш запрос.
Получите признание сообщества django CMS за свой вклад
Подробное описание этого процесса см. в документе Как внести свой вклад в исправление how-to document.
Основные требования и стандарты¶
Если вы заинтересованы в разработке новой функции для CMS, рекомендуется сначала обсудить её на Discourse forum, чтобы не делать работу, которая в любом случае не будет слита.
Код будет проверен и протестирован как минимум одним разработчиком ядра, желательно несколькими. Другие члены сообщества могут оставлять отзывы.
Код должен быть протестирован. Ваш запрос на исправление должен включать юнит-тесты (которые охватывают часть кода, которую вы представляете, очевидно)
Документация должна отражать ваши изменения, если они уместны. Нет ничего хуже, чем недействительная документация.
Обычно, если юнит-тесты написаны, проходят, и ваше изменение актуально, то оно будет слито.
Поскольку мы размещаемся на GitHub, django CMS использует git в качестве системы контроля версий.
Книга GitHub help очень хорошо написана и поможет вам в мгновение ока начать использовать git и GitHub. Это бесценный ресурс как для новичков, так и для старожилов.
Синтаксис и условные обозначения¶
Python¶
Мы стараемся максимально соответствовать PEP8. Несколько основных моментов:
Отступ должен составлять ровно 4 пробела. Не 2, не 6, не 8. 4. Кроме того, табуляция - это зло.
Мы стараемся (не очень строго) придерживаться длины строки в 79 символов. Обычно правило гласит: «Это должно хорошо выглядеть в редакторе на базе терминала» (например, vim), но мы стараемся не быть слишком гибкими в этом вопросе.
HTML, CSS и JavaScript¶
Начиная с версии django CMS 3.2, мы используем те же рекомендации, которые описаны в Aldryn Boilerplate.
Код фронтенда должен быть отформатирован для удобства чтения. Если вы сомневаетесь, следуйте существующим примерам или спрашивайте.
Процесс¶
Так вы исправляете ошибку или добавляете функцию:
fork нас на GitHub.
Проверьте свою вилку.
Хак хак хак хак, тест тест тест тест, коммит коммит коммит коммит, снова тест.
Надавите на вилку.
Откройте запрос на исправление.
И в любой момент этого процесса вы можете добавить: discuss discuss discuss discuss, потому что всегда полезно для всех передавать идеи и смотреть на вещи вместе.
Выполнение и написание тестов действительно важно: запрос на исправление, который уменьшает охват нашего тестирования, будет принят только по очень веской причине; исправляющие ошибку патчи должны демонстрировать ошибку с помощью теста, чтобы избежать регрессий и проверить, что исправление работает.
У нас есть Slack Channel, Discourse forum, и, конечно, механизм отзывов кода на GitHub - используйте его.
Frontend¶
Важно
Когда мы говорим здесь о фронтенде, мы только имеем в виду фронтенд интерфейса администратора/редактора django CMS.
Фронтенд сайта django CMS, который видят его посетители (т.е. опубликованный сайт), полностью независим от этого. django CMS не накладывает практически никаких ограничений на фронтенд - если сайт можно описать на HTML/CSS/JavaScript, он может быть разработан в django CMS.
Для того чтобы иметь возможность работать с фронтенд-инструментарием, входящим в состав django CMS, вам необходимо установить следующие зависимости:
Node версия 6.10.1 (установит также npm 3.10.10). Мы рекомендуем использовать NVM, чтобы получить правильную версию Node.
gulp - см. Gulp’s Getting Started notes
Локальные зависимости
npm install
Стили¶
Мы используем Sass для наших стилей. Файлы расположены внутри cms/static/cms/sass и могут быть скомпилированы с помощью libsass реализации компилятора Sass через gulp.
Для компиляции таблиц стилей вам нужно выполнить эту команду из корня репозитория:
gulp sass
Во время разработки можно также запустить наблюдатель, который компилирует файлы Sass при изменении:
gulp
По умолчанию карты исходников не включаются в скомпилированные файлы. Чтобы включить их при разработке, просто добавьте опцию --debug:
gulp --debug
Иконки¶
Мы используем gulp-iconfont для генерации веб-шрифтов иконок в cms/static/cms/fonts/. Это также создает _iconography.scss в cms/static/cms/sass/components, который добавляет все классы иконок и в конечном итоге компилируется в CSS.
Для компиляции веб-шрифта необходимо выполнить:
gulp icons
Это просто берет все SVG в пределах cms/static/cms/fonts/src и встраивает их в веб-шрифт. Все классы будут автоматически добавлены в _iconography.scss, как уже говорилось ранее.
Кроме того, мы создали SVG-шаблон внутри cms/static/cms/font/src/_template.svgz, который следует использовать при конвертации или создании дополнительных иконок. Он назван svgz, чтобы не компилироваться в шрифт. При использовании Adobe Illustrator обратите внимание на following settings.
JS Bundling¶
Файлы JavaScript разделены для облегчения разработки, но в конечном итоге они собраны вместе и минифицированы, чтобы уменьшить количество выполняемых запросов и повысить производительность. Для этого мы используем бегунок задач gulp, в котором доступна команда bundle. Мы используем Webpack для пакетирования JavaScript файлов. Конфигурация для каждой связки хранится внутри webpack.config.js и их соответствующих точек входа. CMS раскрывает только одну глобальную переменную с именем CMS. Если вы хотите использовать код JavaScript, предоставленный CMS, во внешних приложениях, вы можете использовать только пакеты, распространяемые CMS, а не исходные модули.