Архив метки: php

Можно ли использовать Gettext?

Вопрос: можно ли кому-либо, когда-либо, при каких-либо обстоятельствах использовать Gettext?

Ответ: нет.

Заменил на php-gettext, для моих целей достаточно (но это может быть и Zend_Translate).

Использую самым примитивным образом:

require_once('gettext.inc');
// ...
T_setlocale(LC_MESSAGES, $locale);
$domain = 'messages';
T_bindtextdomain($domain, $locales_dir);
T_bind_textdomain_codeset($domain, 'UTF-8');
T_textdomain($domain);

Это дает нам функцию T_() для использования вместо _(). Если расширение gettext не будет найдено, то _() все равно будет работать, но через эмуляцию. Чтобы полностью уйти от gettext, у себя везде заменил _()на T_().

Разумеется, сколько-то мы теряем в скорости, но «сколько — никто не знает».

PHP-библиотеки для работы с Твиттером

Иногда занимаюсь изобретением велосипеда, иногда нет. По настроению. В данном случае — нет: из существующих библиотек, на которые ссылается dev.twitter.com, более других понравилась twitteroauth. Там, по крайней мере, не единый неразделимый комбайн, как это часто бывает, а отдельный скрипт подключения и отдельный callback. Моя специфика этого требует, да и вообще так больше нравится, потому что иногда человек пишет библиотеку и думает, что этот сервис — Твиттер в данном случае — поставлен во главу угла и сайт без него прямо не проживет. Подобное решение бывает сложно интегрировать (или проще все переписать самому).

URL как ключ массива в PHP

Видимо, что-то не так с использованием URL в качестве ключа массива в PHP — это вопреки часто встречающемуся мнению, что любую разрешенную строку можно использовать как ключ. Нет времени разбираться, но у меня при этом вываливается «PHP Warning:  Illegal offset type in isset or empty» (PHP 5.4.21).

Решено простейшим образом: не $array[$url], а $array[md5($url)].

Тормоза Facebook API

Facebook API оказался нереально медленным. Сидя в России, конечно, чувствуешь, как немного медленнее, чем хотелось бы, Фейсбук работает для пользователя, но вот его API просто побил все рекорды. Я забираю сопоставимый набор информации из ВКонтакте и из Фейсбука. В обоих случаях есть возможность объединить несколько запросов в один. Про VK уже писал, и там информация немного устарела — теперь выполняется не два запроса, а один составной, в среднем за 0,15...0,2 с. С Фейсбуком получается 2...2,5 с, что совершенно неприемлемо. Мне и полсекунды много, а тут две. Даже когда запускаешь какой-нибудь FQL-запрос в Graph API Explorer, видно, как мучительно он соображает.

Тяжеловесно, да.

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

Лечение тормозов при обращении к API внешних сервисов

В любом проекте, где есть обращения к внешним API, именно их следует в первую очередь рассматривать как причину тормозов. Тормозит не коннект к базе, не ваша логика, не загрузка локальных файлов — все это мелочи по сравнению с любыми обращениями вовне. Поэтому важно минимизировать их количество.

Очень просто и некрасиво замерить временные интервалы в PHP можно так. Можно грубо оценить, что выполняется быстро, что — медленно; понять порядок величин.

В моем случае работа с API ВКонтакте состояла из 5 обращений к нему, что в сумме занимало (в среднем) почти 0,5 с. Если скорость загрузки страницы критически важна, это очень много. К счастью, у них в API есть замечательный метод execute, позволяющий не только объединять несколько запросов в один, но и использовать промежуточные результаты, не загружая их к себе (там несложный скриптовый язык). Сокращение 5 обращений до 2 дало двукратный выигрыш в скорости.

Шаблонизатор на XML/XSLT: нет пути?

На прошлой неделе убил, наверное, целый день на то, чтобы сделать специфический шаблонизатор на XML/XSLT (сам проект на PHP). Все красиво и замечательно, но вот проблема: когда мы включаем содержимое внешнего файла конструкцией вида

<xsl:copy-of select="document('/include/something.html')" />,

надо иметь в виду, что содержимое этого файла обязано пройти валидацию. А если речь идет о том, чтобы включить что-то чужое (например, счетчик на JavaScript), валидацию оно как раз и не пройдет. Реальная жизнь — она такая.

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

В итоге отказался от этой затеи, сами страницы оставил в XML, а шаблоны — классика, HTML с примесью PHP. Загружаю XML в DOMDocument и едем.

PHP, XML: изменение SimpleXMLElement с помощью XPath

Предположим, в переменной $item у нас хранится некий SimpleXMLElement, который мы хотим изменить. Самый прямолинейный способ выглядит примерно так:

$item->subitem->param->value = 'NewValue';

Однако если названия элементов содержат спецсимволы (например, двоеточие), то менять значения таким образом не получится. В таком случае можно экспортировать весь узел из SimpleXMLElement в DOMElement, затем изменить то, что нужно, с помощью XPath и импортировать назад. Пример:

$dom = new DOMDocument();
$dom_sxe = dom_import_simplexml($item);
$dom_sxe = $dom->importNode($dom_sxe, true);
$dom_sxe = $dom->appendChild($dom_sxe);
$xpath = new DOMXPath($dom);

$result = $xpath->query('Element:with:a:funky:name');
$result->item(0)->nodeValue = 'NewValue';

$item = simplexml_import_dom($dom);

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