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

Ну, во-первых, я теперь не пишу на PHP. Вообще не пишу. И не очень сильно слежу за последними веяниями моды, связанными с этим языком. Да, я все равно иногда появляюсь в группе симфонистов (кому нужен доступ туда - пишите, там новичков любят и на многие нубские вопросы отвечают :) ). Да, я иногда посматриваю на фреймворки, которые сейчас являются популярными в сфере PHP - всякие Yii, ZF, etc. Посматриваю исключительно для того, чтобы быть в курсе происходящего. Учить их и писать на них в общем-то не очень хочется.

На что я променял PHP? Естественно на Ruby. Я не восхищаюсь этим языком, не превозношу его над остальными, просто на работе я пишу на нем (кстати, я работаю над стартапом для бизнесов - WaysGo, запуск будет, я надеюсь, очень скоро) и ни на чем другом желания писать особо не возникает - с точки зрения веб-разработки Ruby меня полностью устраивает. Этот язык удобен и достаточно экспрессивен. А Ruby On Rails - отличное средство для тех, кто хочет писать веб-приложения. Ну, в общем, вы меня поняли. ;)

Кстати говоря, я немного соврал насчет того, что я пишу на Ruby на работе. С начала этой недели я пишу iPhone-приложение на Objective-C и, в связи с этим, шустренько осваиваю Mac, Xcode, сам Objective-C и всякую прочую фигню, которая нужна для разработки под iPhone. Определенного мнения по поводу мака я пока сказать не могу, а вот Objective-C с первого подхода отличается похожестью на руби с точки зрения вызовов методов у объектов и открытых классов, но в то же время отличается несколько некрасивым синтаксисом (квадратные скобки, рррррр). С другой стороны, к синтаксису Ruby у меня тоже изначально было плохое отношение. Это отношение, кстати, не изменилось - я по прежнему считаю, что Ruby - непонятный язык для новичка, и если код на, например, Python можно просто читать, то для того, чтобы почитать код на Ruby придется сначала посмотреть туториалы, или что-то в этом роде, потому что синтаксис кроме выразительности отличается еще и неочевидностью. После пары дней работы с Ruby проблемы отпадают сами собой, так что этот аспект меня уже не очень беспокоит. Собственно, я надеюсь, что рано или поздно я перестану замечать синтаксис Objective-C и буду просто писать код, который делает что мне нужно.

Вот, собственно, и все на сегодня. Вроде ничего не забыл. До скорого! :)

На данный момент это всё находится в ОЧЕНЬ начальной стадии - ничего не работает, да и как будут работать некоторые вещи я еще не решил. Сейчас работа с бд строиться через mysqli, переход на PDO или поддержка других СУБД не планируется (но если кто-нибудь захочет - сделаем, там не так уж и много работы).

Текущее состояние можно будет посмотреть в SVN. Тем, кто захочет помочь, нужно будет зарегистрироваться на Assembla и сказать мне свой логин.

Буду ОЧЕНЬ рад обсудить технические стороны проекта, а также его нужность.

Из интересных мне нововведений:

• В основе Propel 1.3 лежит новый механизм работы с базами данных - PDO, который заменил Creole и привел к ощутимому повышению скорости работы.
• Теперь не нужно вручную загружать классы Propel и свои модели - теперь это делается автоматически (через autoloading в PHP)
• “Object Instance Pooling”, или, как его называет небезызвестный Фаулер - Identity Map. Причем, что самое интересное, это работает не только с retrieveByPk(), но и со всему doSelect*()-методами (в зависимости от переданных аргументов), что позволяет ускорить работу засчет отсутствия лишних запросов к бд, а также ненужности построения одинаковых обьектов несколько раз.
• Связи один-к-одному теперь поддерживаются нативно (блин, хочу много-ко-многим!)
• Куча мелких (и не очень) исправлений и улучшений

Поподробнее можно прочитать на RedoTheWeb, в также на офсайте Propel.

PS. Сам еще не юзал, но нужно будет попробовать. На мой взгляд, самый интересный момент связан с тем, можно ли переопределить фетчинг записей, например - выбирать только записи с is_hidden = false, да так, чтобы переопределять пришлось только одну функцию.

Update: Как написали на официальном блоге Symfony - “Object Instance Pooling is not an Identity Map because the database request is still needed”. Нужно будет изучить этот вопрос.

• ICQ: 625585
• Jabber: fxposter@gmail.com
• Skype: fxposter

$array = array(1, 2, 3);
$array = array_map(function($v) { return $v * $v; }, $array);
var_dump($array);

array(3) {
  [0]=>
  int(1)
  [1]=>
  int(4)
  [2]=>
  int(9)
}

I like that!

Не выдержал и проверил - поставил себе PHP 5.3:

C:\Program Files\PHP>php -v
PHP 5.3.0-dev (cli) (built: Jul 22 2008 12:21:12)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2008 Zend Technologies

Накидал простенький скриптец для тестов:

$lambda = function () { echo "Hello World!\n"; };
var_dump($lambda);

$lambda = create_function('', 'echo "Hello World!\n";');
var_dump($lambda);

И запустил его:

C:\Program Files\PHP>php test.php
object(Closure)#1 (0) {
}
string(9) " lambda_1"

Как видите - теперь функции являются полноценными обьектами (”Closure - is simply an additional class”), что, на мой взгляд, просто замечательно! Даешь функции высших порядков в PHP!

DOM - это мощный компонент PHP для работы с Document Object Model. Почитать о его возможностях можно здесь (php manual). Я же хочу заострить внимание на том, что это расширение, в отличии от SimpleXML, например, может работать как с HTML, так и с XML.

DomDocument - один из классов компонента DOM, который отвечает за полный XML или HTML-документ.

И вот хотелось бы поговорить и показать, как этот DomDocument работает с кодировками и символами, отличными от латиницы.

Для начала - небольшое отступление: DomDocument я создаю вот так: new DomDocument('1.0', 'UTF-8'), указывая в качестве кодировки (”The encoding of the document as part of the XML declaration.”) UTF-8, так как, судя по моему опыту - указание кодировки здесь не дает вообще ничего.

Рассказывать тут особо нечего, поэтому я приведу код и результаты, а потом их проанализирую.

Весь текст в скриптах в кодировке UTF-8.

Код класса “тестов”

class Test_DomDocument_HTML_Charset {
  protected $dom;

  protected $html =
        '<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">
        <html>
        <head>
          <meta http-equiv="Content-type" content="text/html; charset=UTF-8">
          <title>Тестовая страничка</title>
        </head>
        <body>
          <p>Привет</p>
        </body>
        </html>';

  protected $html_without_charset =
        '<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">
        <html>
        <head>
          <title>Тестовая страничка</title>
        </head>
        <body>
          <p>Привет</p>
        </body>
        </html>';

  protected function checkTestFunction($function)
  {
    return (strpos($function, 'test') === 0);
  }

  public function execute($callback) {
    $functions = get_class_methods(get_class($this));
    $functions = array_filter($functions, array($this, 'checkTestFunction'));
    foreach($functions as $function) {
      $this->setUp();
      $result = $this->$function();
      $callback($result, $function);
      $this->tearDown();
    }
  }

  protected function setUp() {
    $this->dom = new DomDocument('1.0', 'UTF-8');
  }

  protected function tearDown() {
  }

  /**
   * Возвращает кодировку документа.
   * Используется документ, в котором не указана кодировка.
   *
   * @return string
   */
  protected function testWithoutCharset() {
    $this->dom->loadHTML($this->html_without_charset);
    return $this->dom->encoding;
  }

  /**
   * Возвращает документ, после обработки его DomDocument'ом.
   * Используется документ, в котором не указана кодировка.
   *
   * @return string
   */
  protected function testWithoutCharsetHtml() {
    $this->dom->loadHTML($this->html_without_charset);
    return $this->dom->saveHTML();
  }

  /**
   * Возвращает кодировку документа.
   * Используется документ, в котором указана кодировка.
   *
   * @return string
   */
  protected function testWithCharset() {
    $this->dom->loadHTML($this->html);
    return $this->dom->encoding;
  }

  /**
   * Возвращает документ, после обработки его DomDocument'ом.
   * Используется документ, в котором указана кодировка.
   *
   * @return string
   */
  protected function testWithCharsetHtml() {
    $this->dom->loadHTML($this->html);
    return $this->dom->saveHTML();
  }

}

Код, показывающий результаты

function echoHTMLResult($result, $function)
{
  echo "<h3>$function</h3>\n";
  echo '<pre><code>';
  if(is_string($result))
    $result = str_replace('<', '&lt;', str_replace('>', '&gt;', $result));
  var_dump($result);
  echo '</code></pre>';
}

<?php $test = new Test_DomDocument_HTML_Charset(); ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">
<html>
<head>
  <meta http-equiv="Content-type" content="text/html; charset=UTF-8">
  <title>Тестовая страничка</title>
</head>
<body>
<?php $test->execute('echoHTMLResult') ?>
</body>
</html>

Результаты

Выводы

Как можно понять из результатов - кодировка документа при использовании HTML определяется исключительно через тег meta, а точнее - через charset, который там указан:

<meta http-equiv="Content-type" content="text/html; charset=UTF-8">

При отсутствии указанного тега/charset’а в нём - $dom->encoding будет равен NULL (что можно с успехом использовать).

В общем-то всё, в ближайшие дни еще будет статья про кодировку в XML-документах, где всё немного интереснее.

• класс базы данных (относледовался от mysqli, pdo использовать было нельзя)
• класс таблицы, хранящий в себе бд, и отвечающий за CRUD записей
• класс записи, перенаправляющий методы CUD классу таблицы

Примерное использование:

$table = new ArticleTable();
$record = $table->fetchOneWhere("slug = 'hello'"); // получаем существующую запись
$record->name = 'Fucking Article!';
$record->save(); // вызывает insert/update в зависимости от того, новая ли это запись
$record = $table->create(); // создаем новую запись
$record->name = 'Fucking Article2!';
$record->slug = 'fucking_article';
// ...
$record->save();

И что-то мне это очень сильно напомнило, а именно - Zend_Db: Zend_Db_Table / Zend_Db_Table_Row. Недолго думая - выкинул нафиг свою систему и залил в проект кусок Zend Framework’а (если нужно - потом скажу, какие именно файлы нужны для полноценной работы всего компонента Zend_Db), а также решил почитать, что сейчас вообще есть в этой Zend_Db, а есть, как оказалось - довольно много:

• Хорошая абстракция работы с бд
• Классы записи/таблицы
• Поддержка fetch’инга связанных обьектов
• Поддержка many-to-many связей (этого даже в Propel нет)

На самом деле - еще есть вещи, коотрые бы можно было добавить, чтобы они работали автоматически:

• Валидаторы в зависимости от типов полей таблицы
• Возможность сразу fetch’ить данные из нескольких таблиц (точнее - получить такие данные довольно легко, но вот разбрасывать их по разным обьектам и связывать эти обьекты сейчас нужно ручками, если я не ошибаюсь, но опять же - это проблем не составляет)

Вроде всё. Общее впечатление - просто замечательная система. Использовать легко и приятно. :)

Пример:
Сначала пойдут мои супертипы слоя (кто читал Patters of EAA - поймет):

class Db_Table extends Zend_Db_Table_Abstract {
  /**
   * @return Zend_Db_Table_Rowset_Abstract
   */
  public function fetchAllBy($key, $value) {
    $where = $this->getAdapter()->quoteInto("$key = ?", $value);
    return $this->fetchAll($where);
  }

  /**
   * @return Zend_Db_Table_Row_Abstract
   */
  public function fetchRowBy($key, $value) {
    $where = $this->getAdapter()->quoteInto("$key = ?", $value);
    return $this->fetchRow($where);
  }

  public function __call($name, $arguments) {
    if(strpos($name, 'fetchRowBy') === 0) {
      array_unshift($arguments, substr($name, 10));
      return call_user_func_array(array($this, 'fetchRowBy'), $arguments);
    }

    if(strpos($name, 'fetchAllBy') === 0) {
      array_unshift($arguments, substr($name, 10));
      return call_user_func_array(array($this, 'fetchAllBy'), $arguments);
    }

    throw new Exception("Undefined method $name");
  }
}

class Db_Record extends Zend_Db_Table_Row_Abstract {
}

А теперь - пример использования:

class Item extends Db_Table {
  protected $_name = 'items';
  protected $_rowClass = 'ItemRecord';
  protected $_referenceMap = array(
      'Group' => array(
        'columns'       => 'groupid',
        'refTableClass' => 'Group',
        'refColumns'    => 'groupid',
      )
    );
}

class ItemRecord extends Db_Record {
}

class Group extends Db_Table {
  protected $_name = 'groups';
  protected $_rowClass = 'GroupRecord';
  protected $_dependentTables = array('Item');
}

class GroupRecord extends Db_Record {
}

$itemTable = new Item();
$item = $itemTable->fetchRowBySlug('hello');
$group = $item->findParentGroup();

Согласитель - всё просто и удобно, не так ли?

Для заинтересовавшихся - очень советую проштудировать полностью главу о Zend_Db из документации Zend Framework’а. А также - мой пост про Zend_Db_Table, посвященный его улучшению (правда, я не знаю, насколько он сейчас актуален, проверять нет времени :( ).

• Новая архитектура. Явное улучшение - компоненты теперь меньше зависят друг от друга.
• Новая система конфигурирования. К счастью, конфигурация через YAML-файлы никуда не делась. Просто сама структура конфигов переделана.
• “The new object-oriented form framework“. Звучит действительно круто. А смысл такой - генерация форм динамически, вместо статических хелперов (которые, кстати, остались), а также - вся работа с формами (указание полей, их валидаторов, настройка свойств показа формы и прочее)  теперь делается в одном месте, что очень удобно. Есть интеграция форм с Propel, например - автоматическая генерация форм по модели.
• Новая система консольных комманд. Честно сказать - если вы не разрабатываете плагины, то разницу вы увидите только в том, что некоторые комманды поменяли своё название.
• Новый парсер YAML. Разве что изменили выдачу инфы об ошибках. Ну и кое-что добавили. Как по мне - для конечного девелопера разница очень мала.
• Теперь плагины - это обычные пакеты PEAR, со всеми вытекающими последствиями, из которых главным, на мой взгляд, является возможность указаниязависимостей от других плагинов.
• Теперь можно выдавать различные вьюхи в зависимости от того, какоt значение принимает хедер Accept. Поподробнее - здесь.
• Собствено, ORM теперь полностью вынесен в плагины. Symfony 1.0 содержала в себе Propel 1.2, и была возможность заменить его на Propel 1.3/Doctrine через плагины. Теперь же и Propel 1.2 вынесен в отдельный плагин. Скорее всего эта возможность пришла вследствии пункта №1.
• Для того, чтобы приложения, написанные на Symfony 1.0 запускались на версии 1.1 был сделан sfCompat10Plugin, который, насколько я понял, в версии 1.2 уберут совсем. К сожалению, проекты всё таки прийдется дорабатывать, чтобы они работали на Symfony 1.1, подробнее об этом можно прочесть здесь.
• Переписан класс routing’а. Теперь все пути кешируются + от этого класса можно отнаследоваться и переделать, от чего бы я не отказался.

А теперь посмотрите и скажите - что из этого может реально пригодится? ИМХО:

• Form Framework
• Зависимости в плагинах
• Различные вьюхи в зависимости от того, какоt значение принимает хедер Accept

Причем последние два пункта лично я пока не использовал бы нигде. Просто нет необходимости. К чему это я клоню - этот релиз чуть ли не официально был признан “промежуточным” - минимум новых интересных фич и очень сильная переработка кода, причем зачастую внутреннего, для облегчения дальнейшей поддержки и добавления новых фич в будущем. В частности - в версии 1.2 нововведений меньше, но они гораздо больше коснуться конечных пользователей фреймворка (коснуться - в хорошем смысле). Кстати говоря, версия 1.2 выйдет уже в октябре, через 3 месяца… Но это уже несколько друга история, о которой мы поговорим, скорее всего завтра.

Тем временем Fabien (главный разработчик Symfony) разродился кучкой постов:

• Изменение структуры директорий в проектах на Symfony 1.1.
• Отсылка писем в Symfony 1.1 с помощью Swift Mailer. В версии 1.0 для этого использовался PHP Mailer, обернутый в симфониевский декоратор.
• Как создать оптимизированную под iPhone версию вашего сайта с помощью Symfony. За неприглядным (как по мне) названием лежит интересный рассказ о форматах представления и mime-type’ах. Советую почитать, очень интересно. Ах да, про iPhone всё-таки не забыли. :)