Стандарты разработки
- ОБЯЗАТЕЛЬНО! нужно проверять результат совершения операций, которые взаимодействуют с внешней средой, например:
- Открытие соединения с базой данных;
- Открытие соединения с NNTP-сервером;
- Запись файла;
- Выполнение запроса в БД;
- Посылка письма
- Все сервисы должны стартовать автоматически после аварийной перезагрузки сервера.
- В программный код не зашиваются даты, календари должны работать нормально в високосный год.
- В коде на бэкендах нельзя использовать хэш %ENV – в нем некорректные значения.
- Все переменные должны обнуляться перед использованием.
- Надо проверять относительные урлы на валидность в разных браузерах, часто в листалках, если файл страницы не является DirectoryIndex, например: ../../gallery.html, а ссылка в нем относительная, напр: , то IE перейдет на ../../gallery.html?param=1, а NN (4.x) перейдет на ../../?param=1, а еще лучше вообще отказаться от относительных урлов.
- 404-е страницы не должны возвращать 200 статус.
- Ссылки не должны быть длиннее 200 символов, GET – запрос переданный этим методом имеет ограниченую длину (в старом HTTP)
- Cсылки на директории сайта должны заканчиваться слэшом – /.
- Все скрипты, кроме крайней необходимости, разрабатываются в режиме:
use strict;
use warnings;
- По возможности объявление всех переменных выносится в <%INIT>..., также как и большинство данных для вывода подготавливаются заранее.
Например, если при отрисовки таблицы используется массив @rows, то этот массив должен быть полностью подготовлен в блоке <%init>, в HTML коде должен быть только цикл for/foreach без каких-бы то ни было дополнительных преобразований элементов массива.
- При создании сложных конструкций вроде:
< a href="<% defined $model_search && $model_search ne '' ? '&model_search='.$model_search : () %>" >
не используйте их напрямую, лучше будет создать переменную в которую записать значение, а потом уже использовать. Сложность объясняется тем что этот код невозможно без переделки передать параметром в другую компоненту.
Правильно:
% my $link = defined $model_search && $model_search ne '' ? '&model_search='.$model_search : ();
<& /inc/link.msn, link=>$link &>;
- Путь к компонентам указывается абсолютный, а НЕ относительный.
- В проектах на Contenido используются только ШЕСТЬ глобальных переменных:
| $request |
в этот хэш заносится все, что имеет отношение к этому конкретному запросу; |
| $user |
это текущий пользователь и всего его свойства; |
| $state |
состояние проекта. Переменная для настроек; |
| $project |
все, что относится к проекту. Это и есть $project_conf – не надо его дублировать! |
| $keeper |
объект для связи с базой данных. |
| $session |
текущая сессия. Переменная с временем жизни в один запрос; |
- Cброс кэшей на странице производится с помощью определенного параметра expire.
Например, если при запросе страницы http://xxx.rambler.ru/page.html данные берутся из кэша, то при запросе http://xxx.rambler.ru/page.html?expire=1 кэш должен сброситься (пересчитаться заново).
- Автоматически сгенерированные компоненты и написанные вручную должны быть разнесены.
- Приветствуется размещение компонент в различных директориях, не только /components/. Как правило есть 2 стандартных директорий для компонентов:
| /subs/ |
здесь размещены компоненты которые занимаются получением, подготовкой и кэшированием данных но которые не выводят HTML |
| /comps/ |
компоненты из которых собираются WWW страницы (то есть html+mason c преобладанием html) |
- Старайтесь писать понятный структурированный код. Строчки вида
map { очень длинное и сложное выражение } grep { еще одно длинное и сложное выражение } $keeper->get_documents ( 10 фильтров );
сложны для дальнейшей модификации и понимания. Разбивайте их на простые блоки.
- Старайтесь не выдавать HTML из секции <%INIT> и не вызывать оттуда компонентов выдающих HTML
(то есть $m->out(...) или $m->comp(...) в init идея плохая).
- Если в subs создаются компоненты которые работают не только с ядром Contenido а и с какими либо внешними сервисами (внешняя sql-база, почта, внешний www-сервер) это признак того что этот код лучше вынести в отдельный модуль Perl.
- Необходимо проверять все входные параметры на формат и допустимость значений.
- Если вы используете пользовательский ввод при отрисовке страницы обязательно обертывать в escape все символы '<' '>' и '&' (иначе легко использовать различного рода < script >, такие фрагменты могут быть даже вредоносными). Это связано с многими вещами, в том числе с используемой нами системой кэширования.
- Компоненты самого высокого уровня должны иметь расширение .html. Все остальные компоненты, к которым пользователь напрямую ходить не должен должны иметь расширение .msn.
- Если файл не является компонентой Mason и не доступен пользователю для прямого скачивания, то его не должно быть в директориях /comps/*. Для прегенеренных данных используйте директорию данных – $state->{data_dir} или /i/.
- Не делайте больших компонент.
- Минимизируйте использование процедур внутри компонентов (из-за сложностей с компиляцией и обработкой их Mason’ом);
- Если запрашивается несуществующий или некорректный документ, то используйте функцию abort404();
- Мы не используем copy/paste в программировании.
- Если работаете в файлами на основе пользовательских данных (будь то query или cookie или еще что вполть до referer/user agent) то будьте очень аккуратны (необходимо чистить данные от '/' '.' '\' '*').
- Старайтесь получать от keeper только те документы, которые вам нужны. Не стоит получать половину базы и потом перебором отбирать нужные вам.
- Cтарайтесь не делать большие по размеру компоненты высокого уровня к которым обращается клиент. В них же ОБЯЗАТЕЛЬНО в <%ARGS> описывайте ВСЕ принимаемые параметры.
- Если используется много статичного JavaScript — вынесите его в отдельный файл и положите там, где он не будет обрабатываться Mason'ом.
- Мы не прописываем в компонентах прямые пути к файлам и директориям. Всегда и везде пляшите от переменных, хранящихся в $state (их достаточно для удовлетворения любых нужд).
Смотрите также:
|
- Организация запросов к БД
- Начальная структура данных проекта
- Объектная модель данных. Интеграция таблиц в Contenido
- Стандарты разработки
- Стандарты оформления
|
