Эта «небольшая» статейка является развитием темы затронутой в этой статье.
Как известно, PHP зародился довольно давно и уже тогда возник вопрос, что делать с возникающими ошибками. Perl, который является несомненным прародителем PHP по умолчанию не имел какой-либо системы обработки ошибок. При возникновении любой ошибки сервер выбрасывал 500-ю ошибку и на этом все заканчивалось. Поэтому Warnings, Fatal Errors и Notices были настоящим прорывом в облегчении и без того нелегкого труда программиста. Однако время шло, механизмы PHP не менялись, а технологии, как известно, на месте стоять не любят.

Предыстория

Решив запустить небольшой сервис на подаренном мне хостинге, оказалось, что там нету ни одного xml-парсера: ни SimpleXML, ни DOMXML, а только libxml и xml-rpc. Недолго думая, я решил написать свой. Мне требовался разбор не сложных rss-лент, поэтому хватило достаточно просто класса xml => array.^[1]

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

Постановка задачи

Доступ к элементам у нас будет осуществляться как доступ к свойствам класса, например $xml->element, а доступ к атрибутам элемента, как к массиву, те $xml->element['attr'], также реализуем проверку на существование атрибута при помощи isset() и итерацию по элементам при помощи foreach. И так, начнем.

Возникла мысль сравнить два способа хранения абстрактных данных в виде строк, реализованных в PHP: старая добрая сериализация и относительно недавно поддерживающий в языке формат json.

Для сравнения небольшой скрипт генерирует массив из 1000 элементов, две трети элементов которого — строки, длинной 15 символов (напополам — только буквы и только цифры), а оставшаяся треть — массивы по 50 элементов (также — буквенные и цифровые элементы пополам).

Итог весьма неоднозначен, подробности во второй части.

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

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

Поискал ссылки поиском по хабру, не нашел.

Итак, прежде чем изобретать велосипед, у разработчика часто возникает необходимость посмотреть, какие же продукты уже были реализованы.
Кто-то начинает гуглить — что же, наверное, это правильно.

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

Итак, вот они:
www.hotscripts.com
www.planet-source-code.com
php.resourceindex.com
cgi.resourceindex.com
www.scripts.com/php-scripts
www.phpclasses.org
mymans.org/category/php

И так. Объясняю популярно. Ибо сам пока разобрался потратил ни 10 минут. Делаем на примере условного сайта "Travel".

• Движок CakePHP [cakephp/cake и cakephp/vendors] я перенёс(!) в /var/www/cake.core (/var/www у меня apache wwwroot) — то есть, этот движок будет использоваться для всех проектов и не будет меняться до следующей версии CakePHP.
• Содержимое cakephp/app/webroot переносим(!) в /var/www/travel (в этой папке у нас будут все css, images, js, uploads и т.д.)
• Всё из cakephp/app (там уже нет webroot, мы его прошлым шагом от туда перенесли) переносим(!) в /var/www/travel.app (там у нас будет вся логика и темплейты. MVC то есть).