Пока все обсуждают HTML5 я тут пошевелил извилинами и придумал, в общем-то, тривиальную, но полезную концепцию и решение всех ваших проблем с языками разметки. Оно работает уже сейчас в Mozilla, WebKit и Opera.

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

Зато на это способен XML. Теоретически xhtml2 как раз и является воплощением идей модульности и расширяемости. Но есть одна проблема: все равно вам требуется ждать, пока браузеры начнут его поддерживать. Я сейчас возьму на себя смелость сказать следующее: браузер вообще не должен учиться новому языку разметки и разработчики не должны ждать, пока он ему научится. Все что должен уметь браузер — это обрабатывать xml, css и Javascript.

Концепция проста: полностью разделить структуру документа, представление и поведение. Это именно то, что уже сегодня можно сделать используя соответственно xml, css и Javascript. Сценарий выглядит следующим образом:

1. Браузер парсит xml-документ
2. Браузер парсит css-стили, которые говорят как должны выглядеть элементы, и применяет стили к документу
3. js-движок браузера выполняет Javascript, в котором описано, как должен вести себя каждый элемент страницы.

Обратите внимание, что без стилей браузер не знает, что делать с элементом <strong> например. А без описания поведения js-скриптом браузер не знает как себя вести, когда пользователь щелкает по ссылке. Этот подход можно, наверное, назвать DSRB — Document Structure-Representation-Behavior.

А теперь я покажу вам, собственно, страницу, сделанную описанным выше образом, работает в Mozilla, WebKit и Opera (в Опере есть небольшой непонятный глюк с заголовком) — посмотрите в исходный код обязательно. Недостаток данного подхода состоит в том, что браузеры не хотят выполнять Javascript, если они думают, что перед ними XML-документ. По этой причине мне пришлось указать пространство имен xhtml и избегать стандартных элементов HTML, чтобы браузеры не определяли для них дефолтные стили и поведение. Если браузеры начнут поддерживать Javascript для XML-документов, проблема будет решена.

В чем преимущество?

Сообразительные читатели уже догадались, что таким вот способом реализовать HTML5 можно уже хоть сегодня. При этом вы можете добавить в документ нужный вам доктайп или написать свой собственный DTD. Без доктайпа документ будет представлять из себя well-formed XML, что тоже неплохо.

В будущем, если идея приживется, полагаю, появится множество в чем-то схожих языков разметки. 2-3 из них, видимо, будут самыми популярными. Но, самое главное, что DSRB позволит создавать языки разметки, которые начнут работать в браузерах сразу же.

Введение

Хранение иерархических данных (или попросту — деревьев) в реляционных структурах задача довольно нетривиальная и вызывает некоторые проблемы, когда разработчики сталкиваются с подобной задачей.

В первую очередь, это связано с тем, что реляционные базы не приспособлены к хранению иерархических структур (как, например, XML-файлы), структура реляционных таблиц представляет из себя простые списки. Иерархические же данные имеют связь «родитель-наследники», которая не реализована в реляционной структуре.

Тем не менее, задача «хранить деревья в базе данных» рано или поздно возникает перед любым разработчиком.

Ниже мы подробно рассмотрим, какие существуют подходы в организации хранения деревьев в реляционных БД, а также рассмотрим инструментарий, который нам предоставляет ORM Doctrine для работы с такими структурами.

Введение

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

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

Думаю, многие из вас видели плагин для wordpress. Симпатичный шарик привлек мое внимание и мне захотелось его поковырять...
Разочарованию не было предела ― он оказался на флэше(против флэша ничего не имею). Ладно, флэш так флэш нагуглил исходники, распаковал архивчик, а там… А там море файлов с кодом, файлы для настройки с парой десятков опций, несимпатичный фалик для вывода всего этого, для генерации xml'ки.
С этим я мириться уже никак не хотел и решил написать тоже самое, но на javascript. Привык я работать с jQuery поэтому решил сделать в качестве плагина для него.

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