Показаны сообщения с ярлыком php. Показать все сообщения
Показаны сообщения с ярлыком php. Показать все сообщения

воскресенье, октября 21, 2007

светлое будущее, наконец, наступило!

помните, с чего началась вся эта эпопея с xml, xsl, xhtml и прочими иксами?

сначала был html, представляющий из себя кашу из данных, оформления и поведения.
потом появились такие технологии как css и javascript, которые позволяли отделить от данных оформление и поведение, но в данных всё-равно оставалось много мусора - семантически незначимых конструкций, а представлять данные требовалось так как их может воспринять браузер - ограничиваясь весьма жёсткими рамками html.

тогда появился xml - формат не накладывающий ограничений на структуру данных. в нём можно использовать свои тэги, вкладывать так как считаешь правильным и многое другое.
естественно, браузеру всё-таки надо было объяснить как эти данные следует отображать. css был недостаточно функционален для отображения произвольных данных, поэтому был разработан xsl, который весьма прохладно был воспринят создателями браузеров. тем не менее, его младшему брату xslt повезло больше: ввиду того, что он не требует переписывать весь браузерный движок, а выступает в качестве посредника, трансформирующего исходный xml в html уже понятный браузеру, его поддержка довольно быстро появилась в ИЕ, мозилле и сафари - основной троице браузерных движков. последней, сравнительно недавно, к ним подключилась и опера (девятая версия).

что мы получили в итоге? получили мы возможность на запрос клиента отдавать только данные в удобной нам форме. если браузер не знает что эти данные означают - он качает xslt и трансформирует их в xhtml. если он не знает как они должны выглядеть - качает css и показывает. если же он не знает как они должны себя вести - качает javascript. xslt, css и javascript качаются один раз и оседают в кэше. при каждом запросе передаётся только экстакт данных в формате xml.

более-менее продвинутый читатель, наверно, уже заметил, что формирование xml ничем принципиально не отличается от формирования html. отчасти это так. если мы формируем документ-ориентированный xml, то придётся вручную вставлять данные в нужные места. но, если наша цель - формирование xml ориентированного на данные, то его формирование можно возложить на автоматику, которая преобразует родные для языка программирования объекты в неродное xml дерево.

чтобы не быть голословным, предлагаю реализацию на php:
function native2xml( $var, $name='root' ){
$xml= '';
if( is_object( $var ) || is_array( $var ) ):
foreach( $var as $n => $v )
$xml.= native2xml( $v, $n );
else:
$xml= htmlspecialchars( $var, ENT_NOQUOTES, 'UTF-8' );
endif;
if( is_numeric( $name ) ) $name= 'item';
return '<'.$name.'>'.$xml.'';
}


просто передайте этой функции дерево объектов и получите на выходе xml-строку.

тут вы можете скачать рабочий пример, демонстрирующий вывод формы и локализацию основанную на xslt (приглядитесь, в xml пересылаются английские фразы, но отображаются они в браузере на русском языке).

из минусов такого подхода:
1. мы ограничиваемся исключительно языком xslt, о недостатках которого я уже писал.
2. для поисковиков и устаревших браузеров нужно производить эти трансформации на сервере.

есть ещё два варианта "объяснения" браузеру как работать с данными:
1. javascript - трансформирование с его помощью - редкостный изврат.
2. OWL - очень мощная технология, но на данный момент никем не поддерживаемая. есть подозрение, что её ждёт та же учесть, что и XSL (-_-)

среда, сентября 26, 2007

php -> javascript -> ...

кто сказал, что в php нет ни динамического, ни множественного наследования?
уже есть: http://php.ru/forum/viewtopic.php?t=7870

и пусть только кто-нибудь после этого скажет, что в php слабый ООП... |_(~_~)_/

воскресенье, августа 19, 2007

Кодестайл против собаки

- вы должны каждое слово начинать с большой буквы
- ну.. это ж тянуться к шифту без конца
- это хороший стить
- чем же он хорош?
- позволяет отделять слова друг от друга
- а пробелы разве не для этого?
- пробелы - это плохой стиль
- что за бред?
- это потенциальный источник ошибок: слова можно написать настолько близко друг к другу, что можно не заметить существование пробела, к тому же иногда межбуквенный интервал можно принять за пробел.
- а что мешает использовать интервалы нормальной длинны?
- мне лень такому дауну как ты что-либо доказывать - любой здравомыслящий человек поймёт, что пробелы нельзя использовать нигде и никогда, потому как получается говнокод - нужно использовать "синтаксический сахар" в виде заглавных букв.
- но это не удобно, ужасно смотрится и некоторые заглавные буквы можно спутать со строчными!
- бан бы тебе, с аргументом "непросветлённый"! тема закрыта.

навеяно этим: http://phpclub.ru/talk/showthread.php?s=&threadid=101915

среда, августа 15, 2007

php и замыкания

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

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

однако, в пыхе есть и поруганное многими исключение - директива global позволяющая импортировать переменные из глобального контекста. как говорится: "мысля была хорошей, но родилась она в заднице" :) вместо директивы global лучше бы ввели директиву extern, позволяющую импортировать переменные из родительского контекста - получились бы эдакие "контролируемые замыкания".

интересно, существуют ли уже языки с "контролируемыми замыканиями"?

среда, июня 27, 2007

inc и onc - братья универсалы

Разродился статьёй по поводу давно используемых мной двух функций для подгрузки и выполнения кода на php.
это и темплейтный движок, и фабрика, и реестр, и организация пакетов...
и всё это в двух флаконах суммарным объёмом в 25 строчек! =^_^=

подробности: http://php.ru/forum/viewtopic.php?t=6406

воскресенье, июня 03, 2007

Деревья теперь и в MySQL

написал драйвер для mysql и на той же страничке выложил их сравнительное тестирование.

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

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

пока адаптировал DirecTree под мускул весь на мат изошёл...
1. мускул требует либо указывать для полей имена таблиц, либо брать имена таблиц в бэктики, которые не совместимы с другими БД.
2. мускул не позволяет сделать модификацию таблицы, если в запросе используется подзапрос вытягивающий данные из этой же таблицы. идиотизм какой-то...

вроде поборол, но, смотря на код, самому тошно... надо будет переписать...

функцию install под мускул пока не тестировал - остальные вроде работают нормально.

ссылка та же: http://dark-demon.jino-net.ru/directree/ тока не злоупотребляйте рефрешем ^_8

пятница, июня 01, 2007

Организация деревьев в реляционных базах данных

сага об изобретении велосипеда: http://php.ru/forum/viewtopic.php?t=5303
и вот к чему это в итоге привело: http://dark-demon.jino-net.ru/directree/

не буду особо распространяться относительно подробностей реализации разных алгоритмов огранизации деревьев (при необходимости вы легко найдёте их в гугле), только приведу их краткий список:
1. таблица смежности - каждый узел хранит ссылку на родителя. фиг выберешь поддерево одним запросом. как следствие - тормоза при больших вложениях, особенно, если sql-сервер стоит на отдельной машине.
2. материализованный путь - каждый узел хранит ссылки на предков в строковой переменной. поиск по подстроке - забудьте о скорости и глубоких деревьях.
3. вложенные множества - все узлы выстроены в линию и каждый узел хранит свой номер и номер последнего потомка. очень большой плюс - естественное упорядочивание дерева. очень серьёзный минус - необходимость перелопачивать половину базы данных при изменениях.
4. таблица смежностей + кэш связей. в кэше хранятся все линки предок-потомок. большая избыточность при глубоких деревьях.

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

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

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

суббота, мая 12, 2007

логи и php - две вещи не совместимые.

всё началось с того, что я на php используя лямбда-функции реализовал кэширование исполняемого php кода. работало всё просто замечательно - один и тот же файл можно было инклудить хоть по сотне раз без особых потерь в скорости.
проблема в том, что в процессе написания скриптов неизбежны ошибки и в логах было бы неплохо, если бы писалось в каком файле она находится, а не в каком была создана лямбда-функция, которая создаётся в одном и том же файле. поковырявшись с отловом ошибок получилась такая вот замечательная штука, которая заносит расширенную информацию об ошибке в sqlite базу: http://dark-demon.jino-net.ru/samples/demologs/
всё бы хорошо, да вот самые главные ошибки - фатальные - средствами php не отловить (@_@). разве что ошибки парсинга...
в общем, время потрачено впустую (#_#) поэтому для кэширования скриптов остаётся юзать APC, либо его аналогов.

можете записывать меня в php-ненавистники.

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