PHP *

Учитывая наличие интереса к этой теме у сообщества, продолжаю знакомить со своими плагинами для Smarty. С первой частью можно ознакомиться здесь.

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

Выражения — это краеугольный камень PHP. Почти все, что вы пишете в PHP, является выражением. Самое простое и точное определение выражения — «все что угодно, имеющее значение». (с сайта php.net)

UPD: Статья только о том, как МОЖНО делать в некоторых случаях, когда это оправданно. В большинстве случаях (и тем более повсеместно) описанную практику применять не стоит ни в коем случае, так как она сильно усложняет код. Цель статьи — расказать о возможностях языка, не более того.

Данный пост посвящается любителям typehint'ов и строгой типизации, которой у PHP нет по определению.

копаясь недавно в мануалах по PHP, набрел на раздел о typehint'инге, и совершенно случайно полез в комментарии, где и нашел великолепное (хотя и тяжелое) решение для PHP5, как сделать язык строго типизированным. Под катом решение.

Часто ли вам приходилось сожалеть о том, что в PHP нет перечислений как таковых?

Да, кто-то обходился конвенцией именования и получалось нечто вроде:

define( 'COLOR_RED', 'F00' );
define( 'COLOR_GREEN', '0F0' );
define( 'COLOR_BLUE', '00F' );

Или нечто вроде:

// данную переменную ЗАПРЕЩЕНО модифицировать
$colors = array(
    'red' => 'F00',
    'green' => '0F0',
    'blue' => '00F',
);

Но оба подхода имеют существенные недостатки:

• В первом случае члены перечисления не образуют явной группировки
• Во втором случае есть риск что переменная будет изменена
• И в обоих этих случаях мы не можем делать проверку на тип переменной (type hinting)

Под катом предлагаю решение без вышеописанных недостатков…

<?php

/**
* Пример реализации Generic-класса
*
* Возможности:
* 1. Осуществляет доступ к параметрам класса через методы get* set* (accessors/mutators)
*     Пример: $object->setName('Dima'); $object->getName();
*     При изменении стандартного поведения метода (добавление дополнительной логики)
*     можно просто определить его в классе при этом не изменяя интерфейс класса.
* 2. Поддерживает встроенную валидацию данных с возможностью использовать или заранее
*     определенные типы данных (numeric, string, email, date и др.)
*     или регулярные выражения.
* 3. Имплементирует паттерн Lazy initialization для инициализации объектов.
*     Позволяет загружать параметры объекта из БД (например) не сразу при инициализации,
*     а только при первом запросе.
*
* Видимые недостатки:
* 1. Отсутствует возможность использовать автокомплит в IDE, так как методы явно не определены
*
* Плюсы:
* 1. Позволяет избежать дублирования кода при определении однотипных методов set и get
* 2. Сокращает код классов и централизует управление параметрами
* 3. При необходимости можно расширить функциональность. Например, добавив callback функции
*     или принудительную фильтрацию данных.
* 4. Избавляет от рутинных обязанностей проверки входящих данных, тем самым
*     обеспечивая некоторый уровень безопасности.
*     Это совсем не дает 100% гарантии — не стоит забывать об этом.
* 5. Не вносит коррективы в интерфейс классов. Можно легко сочетать обычные классы и классы
*     наследующие GenericObject без видимых различий для клиентов класса. При необходимости
*     можно легко отказаться от использования просто переопределив все гетеры и сетеры.
* 6. Упрощает работу с классами, предоставляя удобный и естественный способ
*     инициализации объектов:
*     $obj1 = new Class(123);
*     $obj2 = new Class(array(
*         'param1' => 'value1',
*         'param2' => 'value2')
*     ));
*/

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

Я не буду вдаваться в подробности распределения нагрузки, а отпишу лишь основные правила при соблюдении которых Ваша CMS будет легко масштабироваться.

Отсебятина

Кросс-пост четвертого перевода туториалов по Google Maps API из моего блога.

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

Не буду останавливаться на вопросе, что такое веб-сервисы и зачем они нужны. В сети очень много статей на эту тему. Просто постараюсь вкратце показать, каким простым способом возможно создание клиента к любому веб-сервису на php.

О чем это?

Возможно ли узнать более детальную информацию о браузере посетителя кроме строки, содержащейся в $_SERVER[«HTTP_USER_AGENT»]: поддерживает ли яву, апплеты, таблицы стилей и фреймы? А может это вообще гуглобот зашел?

Недавно в блоге PHP пролетала статья про наследование шаблонов в Smarty, которая навела меня на мысль: я уже на протяжении нескольких лет использую Smarty в качестве основного шаблонизатора и у меня накопилось множество написанных мною плагинов для расширения базового функционала. Почему бы не поделиться с сообществом своими наработками и послушать других? Я думаю, у многих есть чем поделиться по этой теме…

Данная статья рассматривает одну из проблем хранения PHP-сессий в memcached: отсутствие их блокировки.

Введение

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

Отсебятина

А вот и перевод третьего урока по Google Maps API. Этот урок — как видно из названия — посвящен созданию карт при помощи данных, хранящихся в БД. Как и предыдущие — кросс-пост из моего блога.

В очередной раз ковыряясь в чужом коде, понимаю насколько больная тема — стандарты кодирования в PHP…

По следам хабратопика Наследование шаблонов в Smarty хочу рассказать как около полутора лет назад я решил подобную задачу. В оличие от marazmiki с Django я знаком не был (хотя сейчас занимаюсь изучением именно его). Но крайне поверхностно был знаком с механизмом Master Pages из ASP.NET. Механизм заключается в том, что у нас есть практически полноценная страница, у которой отсутствует только блок с основным контентом.

Немного прикинув придумалось решение через стандарные функции Smarty и механизм наследования в PHP.

Системы кеширования, с которыми я сталкивался, разработаны по принципу: задай объекту Cache параметры кеширования и работай с объектом Cache. До определенного времени меня устраивала подобная работа с кешем. Однако время не стоит на месте и однажды мне понадобился более удобный способ работы с кешем. В итоге появилась собственная реализация, основанная на тикетах. Суть ее состоит в том, что надо у объекта Cache запрашивать тикет, у тикета уже выставлять параметры (ключ, префикс и т.п.), и тикет должен уметь сохранять данные и извлекать их из кеша.
Это решило проблемы конфликтов при кешировании, когда кто-то начал работать с объектом Cache, выставлял какие-то параметры и передавал управление в метод, который тоже работает с кешем. Появилась возможность обмениваться тикетами.

Реализация для PHP, кеш ориентирован на хранение и извлечение данных из файловой системы: code.google.com/p/ewgra/source/browse/#svn/trunk/cache

В последних версиях PHP появились namespace'ы — пространства имен.

У них есть очевидные преимущества:
— помогают сократить названия классов;
— позволяют избежать конфликтов имен;
— помогают лучше структурировать классы.

Но, помимо этого, есть еще преимущество, на которое не так часто обращают внимание: namespace'ы помогают разработчику видеть зависимости того или иного класс, причем это не приводит к какому-либо оверхеду. Поясню.

Помните, как в PHP4 мы писали перед объявлением класса:
require_once "MyClassParent.php";
require_once "MyClassDependency.php";

Потом пришел PHP5, появился __autoload() и spl_autoload_register() — мы убрали безусловные подключения файлов и вместе с ними оверхед. Все хорошо, да вот только теперь не так очевидно стало, какие же другие классы/файлы нужны для нашего класса, чтобы он нормально функционировал.

И тут — появляется батут php-5.3. Теперь, без лишнего оверхеда мы можем, и даже не только можем, но и в определенных случаях должны — указывать зависимости нашего класса:
use myns::MyClassParent;
use anotherns::MyClassDependency;

Отметим, что при использовании use не происходит подключения файлов с классами.
Теперь, как говорится, и программисты волки сыты, и харды овцы целы.

Когда-то, давным-давно, мне пришлось использовать небезызвестный шаблонизатор Smarty. Сначала я, понятное дело, возмущался и кричал, какая же гадость эта заливная рыба Smarty, а потом «распробовал» и втянулся. Те удобства, которые он давал, с лихвой компенсировали мысли о том, что есть и более быстрые шаблонные движки.

Шаблоны я обычно строил с помощью инклюдов: в начале подключался header.tpl, в конце — footer.tpl, в середине ещё что-нибудь нужное. В целом разметка получалась довольно аккуратной, но не проходило ощущение, что не хватает чего-то важного. Окончательно понимание этого чего-то появилось, когда мне случилось написать простенькое приложение на Django. И это «что-то», как все поняли, оказалось наследованием шаблонов. Простая, как и всё гениальное, идея позволяла существенно упростить шаблоны и избавиться от дублирующих блоков.

Подборочка ошибок начинающих PHP разработчиков…

Приветствую всех читателей!

Я начал заниматься SEO недавно, и сразу же столкнулся с задачей определения позиций продвигаемых сайтов по ключевым словам в поисковиках. Задача тривиальная и решается на ура различным ПО, которое у всех SEO-специалистов на устах: Semonitor, AllSubmitter, etc. Помимо проприетарности, которой попахивает от всех подобного рода программ, в них есть, как это не парадоксально, ряд технических моментов, из-за которых хочется выбросить компьютер в окно.
Я бы не прочь купить Semonitor, но попользовав демо-версию, решил от этой идеи отказаться — на оф.сайте программы доступная для скачивания версия у меня глючила, требовала обновить себя, а после выпрошенного у меня обновления и вовсе отказывалась заниматься анализом позиций. Самому настроить, как Вы понимаете, нельзя.
AllSubmitter в этом плане получше, позволяет даже кастомизировать регулярные выражения для поисковиков, что вроде как делает этот софт устойчивым к смене формата выдачи, однако и с ним не все слава богу — когда 18.08.2008г. Яндекс вдруг изменил формат выдачи результатов поиска, вместе с тем поменяв и URL ссылок (возможно, эксперименты с вводом учета переходов, подробнее об этом писалось здесь), то и AllSub оказался бессилен. Правда, на следующий день Яндекс снова вернулся к старому формату выдачи, но прецедент, тем не менее, произошел.