О плохих шаблонизаторах

Для меня стало неприятным открытием что многие до сих пор используют для шаблонизации таких уродцев как XTemplate, либо пишут свой такой же велосипед с квадратными колёсами.
И так, давайте рассмотрим принципы их работы.
Первоочередной задачей шаблонизации является разделение бизнес логики и логики представления. Говоря человеческим языком, для того чтобы изменить отображение страницы нужно изменить лишь часть, отвечающую за отображение, так называемый шаблон.
Что такое шаблон. Обычно это html код со вставкой специальных элементов разметки, которые позволяют добавлять динамические данные.
На первом этапе создаётся массив данных, которые нужно передать в шаблон, а затем выводится сам шаблон и делаются замены спец вставок, на данные полученные в первом этапе.
Для обнаружения и подмены вставок, обычно используются два способа - функция str_replace и регулярные выражения. Первый вариант довольно шустрый, но имеет рад ограничений, второй из-за использования регулярок довольно трудоёмок.
И так, что происходит внутри. Берётся файл с шаблоном, загружается в память, затем обрабатывается с помощью строковых функций и делаются замены. Парсинг целого шаблона штука довольно трудоёмкая, а главное бесполезная. У нас для шаблонов уже есть РНР, который позволяет писать этакий код:

<h1><?=$title?></h1>
<ul>
    <? foreach $items AS $item { ?>
    <li><?=$item?></li>
    <? } ?>
</ul>

А теперь представьте шаблон  пару сотен кода, в котором должны делаться замены, которых можно было легко избежать, подумайте, насколько упадёт производительно?
Для чего же тогда написана такая громадная библиотека как smarty и его аналоги, если уже есть готовые средства.
И так, рассмотрим второй подвид шаблонизаторов. Смартиподобные шаблонизаторы имеет ещё одну прослойку - компиляция. То есть, как и у первых, берётся шаблон, но не делается замена вставка - значение переменной, а вставка - переменная, после это всё записывается в файловую систему, чтобы при повторном обращении не делать лишних преобразований. В итоге, мы получает php шаблон. Но скорость даже подобных шаблонизаторов хуже чем, ежели бы обошлись без них.
И на кой нам это?
Первое преимущество - безопасность. Убрав из шаблонов РНР мы делаем шаблоны безвредными.
Второе тесно связано с первым. Теперь изменением дизайна могут заниматься не программисты, нужно лишь не нарушать разметку.
Третье - автоматизация. Люди ленивы, а жизнь коротка. поятому нужно стараться не делать дважды отдно и тоже. Допустим в смарти есть элемент html_options, который позволяет создать список единого выбора, есть escape, который поваляет обезопасить вывод, избавившись от потенциально опасных тегов.
Четвёртое..... А ну его, додумайте сами.
Результаты.
Шаблонизания на основе компилируемых шаблонов, помогает сэкономить кучу системных ресурсов, по сравнению с дермошаблонизаторами, при этом расширяемость позволяет выходить за рамки логики отображения, но хорошо это или плохо, решать каждому для себя. Пользуйтесь качественным кодом.
P.S. Некоторые умеют летать, а другие сё ещё "залетают".© Кто-то умный.

Всемогущий Google

Последнее время я, как и большинство айтишников и простых пользователей подсел на сервисы Google. Очень удобно и главное собрано в воедино. Но последнее время начали раздаваться тревожные возгласы, предупреждающие, что google - это не добрый дядюшка, а корпорация образца microsoft, нацеленная на получение прибыли. Я довольно скептически отношусь к угрозе быть загугленым, я человек добрый и честный, мне скрывать нечего.

Но для любителей теории всеобщего заговора и просто любознательных поделюсь ссылкой на забавный и симпатичный проект http://masterplanthemovie.com/

Flash сообщения/

Часто бродя по сайтам и заполняя формы встречаю некоторые типичные недоработки при обработке форм.
Например, после обработки забывают сделать редирект, в итоге при нажатии "Обновить", данные посылаются повторно, что очень неприятно.
Поэтому, не забываем
header('Location: ' . $url);

Теперь появляется новая проблема - как сообщить о результатах обработки. Для этого воспользуемся так называемыми flash сообщениями.

Я приведу один из вариантов.

В начале сценария мы создаём объект $flash, при этом данные из $_SESSION['flash'] копируем в закрытую переменную класса и очищаем $_SESSION['flash'].

С помощью магических методо мы работаем с флэш данными:

1. __set() используем для занесения переменной в сессию.

2. __get() для извлечения флэш данных.

3. __isset() для проверки на сущестование данных.

<?php
error_reporting(E_ALL);
$flash = Amdy_Flash::Singleton();
if (isset( $flash->test ) ) echo 'true - ' , $flash->test;
else echo 'false';
$flash->test = 'ok';
class Amdy_Flash {
public static $instance;
protected $_data = array();
/**
 * @return Amdy_Flash $instance
 */
public static function Singleton()
{
    if (!isset(self::$instance)) {
        $c = __CLASS__;
        self::$instance = new $c();
    }
    return self::$instance;
}
public function __construct() {
if (!session_id()) session_start();
    if ( isset($_SESSION['flash']) ) {
        $this->_data = $_SESSION['flash'];
        unset($_SESSION['flash']);
    }
}

public function __set($varName, $varValue) {
    $_SESSION['flash'][$varName] = $varValue;
}
public function __get($varName) {
    return (isset($this->_data[$varName]) ? $this->_data[$varName] : null);
}
public function __isset($varName) {
    if (isset($this->_data[$varName])) return true;
    else return false;
}
}
?>

Кодировки

Как это не странно, но до сих пор очень часто многие начинающие задают вопрос о кодироках, вернее о "неправильном" отображении русских буковок. Постараю описать все по порядку, следуя данному списку инструкций у меня никогда не возникало проблем с кодировками.

Перый шаг - настройка вашего любимого редактора. Ищем пункт encoding (кодировки) и ставим utf-8. Очень советую использоать именно юникод, чтобы избежать проблем в дальнейшем. Конечно, у юникода есть ряд недостатков, но пользы гораздо больше. Ах, да, ещё пару советов по настройке редактора. Выстовте конец строки в стиле unix  - \r. И используйте 4 пробела вместо табов.

Второй шаг - HTML. Добавляем строку

 <meta equiv="Content-Type" content="text/html; charset=utf-8"> 

в <head></head>.

Третий шаг - РНР. Некоторые браузеры пренебрегают  Content-Type и используют кодироку, посылаемую сервером, обычно по умолчанию iso-8859-1(latin1). Значит мы посылаем нужную нам -

header('Conten-type: text/html; charset=utf-8');

Четвёртый шаг - базы данных. Обычно данные берутся из базы данных, поэтому при создание таблиц и полей не забываем указывать нужную кодировку - utf8_general_ci. Обратите внимание, что именно general_ci, а не bin, как любят многие, это позволяет работать с данными как со строками, а не с двоичными данными. Но хостере и здесь заготовили подвох, и по умолчанию чаще стоит другая кодировка. Поэтому предупредим MySQL, что собираемся работать именно с utf-8, для этого сразу после подключения посылаем запрос:

SET NAMES utf8

Обратите внимание, что в названии кодировки нету дефиса. Некоторые советуют посылать ещё парочку, но у меня такой надобности не возникало.

Пятый шаг - если таки данные берутся из другой кодироки, для этого используется функция iconv(), которая конвертирует данные из одной кодировки в другую. На некоторых хостингах нету сего полезного расширения, но я предлогаю игнорировать хостинги с ненастроенным РНР и неустановленными популярными расширениями.

Дерзайте, все неудачные попытки конспектируйте и задавайте вопросы.