Не вижу. Я вижу другое — нет смысла использовать что-то немерянно-громоздкое там, где можно прекрасно без этого обойтись. Данная ситуация — это большая частность, в которой xslt, возможно, немного выигрывает в каком-то моменте.
Но это только в этом случае. А теперь надо представить, что xslt будет обслуживать не только этот момент, но и все остальное, иначе как это — мы используем всю мощь xslt только тут, нафига тогда оно нам надо?
Определить список разрешенных селекторов в таблице «Кастом_нью_селектор»: «id | selector_name | default_value».
Создать таблицу связей: «selector_id | user_id | value».
Кстати, вместо user_id может быть, стоит использовать site_id.
И вот теперь уже с помощью одного foreach можно не давать юзеру писать все цсс-правила, а только значения.
Но, в принципе, а чем я хуже людей, сделавших Social Engine? В этом движке каждый пользователь может писать css-правила. Не блогохостинг, но соцсеть.
А вообще — да, предлагаю, но только в платном аккаунте.
Это значение $admin_custom_zone, конечно, тоже можно хранить в $STOR (БД или файл) для удобного доступа из админки.
Собственно, дополнительную часть скина ($STOR->user_custom_zone) храним в БД или в файле, не суть.
Теперь при добавлении blockquote, он добавится во все css, а юзеру позже придется в своей «user_custom_zone» добавить
blockquote{border-color: red;}
, он сохраняется в $STOR, а при следующей загрузке обновляется.
Твой способ, конечно, где-то проще, но он находится на границе с очень редковстречаемой частностью. Но городить для этой частности XSL и все связанное — по-моему, как уже неоднократно употреблялось здесь, изврат.
Вообще, изначально, предложенный мною вариант был создан с целью показать, что все можно сделать без XSL довольно быстро и просто. Теперь, если полезли в частности, как и ожидалось, вариант усложнился, скрип мозгов стал громче. Двоеточие-скобка
В PHP либо надстройка над css-файлом, которая прописывает все стили, которые будут добавлены. Но опытный программист (как и опытный верстальщик) должен учитывать практически все варианты. Это как с проектированием БД — если после долгого использования ты изменяешь БД — это неправильно (опять же, есть исключения).
Если бы необходимо было дописать еще один селектор в уже рабочий проект, я написал бы генератор или парсер css-файлов юзеров на PHP. А с новым можно подольше позаморачиваться.
Может, я неверно выразился ранее, ибо /default/css.css — это и есть те самые правила, не зависящие от скина. А /newskin/css.css — это скин одного человека. A /newskin2/css.css — это скин другого человека. Можно еще иметь некий — /firstskin/css.css — первоначальный скин, который будет для всех один.
«где надо» — так же тяжело поддерживать, как и в примере в топике, или так сложен сам процесс оверайта?
Ну как это не делает? Сервер на каждый запрос должен выдать какой-либо ответ — 304 или 200 или даже 302.
А в остальном — в чем проблема-то?
Дефолтный css грузится сначала с site/skin/default/css.css и дает ответ 304, затем грузится другой css с site/skin/newskin/css.css и, где надо, оверайтит дефолтный. Если браузер уже грузил этот файл, ему будет ответ 304.
Как иначе-то? Или я не понимаю вопроса. В топике говорится про неизбежные дополнительные вычисления на сервере, и, в следствие этого, мы вызываем xsl-процессор для вычисления разницы. А только на php мы вызываем php-интерпретатор для получения файла css и Memcache нас спасает.
А где он? Пардон, но на странице я обнаружил два слова, содержащие фразу «кэш» («cache» — вообще отсутствует) — в Похожих публикациях и в твоем посте, но никак не в топике.
Но если насчет кэширования — то тут все просто. Есть туча методов кэширования, например:
— Правильно настроенный апач (mod_expires + mod_headers + ETAG) — css (и не только) будут выходить с ответом «304 Not Modified». Но это, имхо, необходимо реализовывать на большинстве серверов. А чтобы css был новым, всегда когда его обновляем, можно прописать что-то типа: css2.css?20100510.
— Опять же в php можно очень просто подключить memcache и закэшировать все это. Плюс, если уж изврат, то хранить в базе, там кэш тоже есть.
Читаю вас уже не первый раз, и опять не первый раз убеждаюсь в том, что можно и не использовать XSLT. Пост в очередной раз задел за живое, поэтому продолжаю попытки избежать использования XSLT с помощью PHP.
Создаем для красоты три файла и пользуемся стандартным набором PHP:
1. css.php
из кода все понятно, но все же кратенько:
css.php — основной шаблон, в котором подключается все остальное,
css2.php — перечень переменных,
css2.css — собственно файл css.
Насчет скорости работы сказать не могу — возможно, есть более быстрые решения с RegExp, или использование str_replace или в написании собственного парсера. Но при увеличении размера XML-файла время обработки тоже увеличится. Конечно, стоит добавить несколько проверок, например, на наличие файла. Этот так-называемый-парсер был создан за пару минут, но показывает, что все возможно банальным PHP еще даже 4ой версии, с которой я чертовски давно начинал. Ну, и конечно, все это можно подключить в еще один файл или использовать этот для создания конструкции вида
Если верить Firebug::net, то подключение к серверу составляло 6 секунд
Что на ХЦ, что на Агаве, что на Логоле сайты у меня открываются очень быстро, а вот с Кейвебом вышло так
Перечитал.
Согласен, выглядит немного рекламно. Но, скорее это живая антиреклама ХЦ.
И заметьте, не даю ни одной ссылки.
По крайней мере, хорошо там, где я теперь есть.
Если пойти коротким путем, то можно заметить, что часть первоначального урла совпадает с урлом той самой картинки, что нам нужна. Дальше надо найти урл следующей страницы и парсить до конца.
Но это только в этом случае. А теперь надо представить, что xslt будет обслуживать не только этот момент, но и все остальное, иначе как это — мы используем всю мощь xslt только тут, нафига тогда оно нам надо?
Создать таблицу связей: «selector_id | user_id | value».
Кстати, вместо user_id может быть, стоит использовать site_id.
И вот теперь уже с помощью одного foreach можно не давать юзеру писать все цсс-правила, а только значения.
Но, в принципе, а чем я хуже людей, сделавших Social Engine? В этом движке каждый пользователь может писать css-правила. Не блогохостинг, но соцсеть.
А вообще — да, предлагаю, но только в платном аккаунте.
Но, поскрипев мозгами (чего стоит делать, несомненно, чаще), предлагаю такой способ:
Дописываем в файл /newskin/css.css следующее:
$admin_custom_zone $STOR->user_custom_zone .BODY__P{/*..style..*/}В файл, где хранятся все дефолтные значения скина css2.php
'$admin_custom_zone' => 'blockquote{border: 1px solid steelblue;}'Это значение $admin_custom_zone, конечно, тоже можно хранить в $STOR (БД или файл) для удобного доступа из админки.Собственно, дополнительную часть скина ($STOR->user_custom_zone) храним в БД или в файле, не суть.
Теперь при добавлении blockquote, он добавится во все css, а юзеру позже придется в своей «user_custom_zone» добавить
blockquote{border-color: red;}, он сохраняется в $STOR, а при следующей загрузке обновляется.Твой способ, конечно, где-то проще, но он находится на границе с очень редковстречаемой частностью. Но городить для этой частности XSL и все связанное — по-моему, как уже неоднократно употреблялось здесь, изврат.
Вообще, изначально, предложенный мною вариант был создан с целью показать, что все можно сделать без XSL довольно быстро и просто. Теперь, если полезли в частности, как и ожидалось, вариант усложнился, скрип мозгов стал громче. Двоеточие-скобка
В PHP либо надстройка над css-файлом, которая прописывает все стили, которые будут добавлены. Но опытный программист (как и опытный верстальщик) должен учитывать практически все варианты. Это как с проектированием БД — если после долгого использования ты изменяешь БД — это неправильно (опять же, есть исключения).
Если бы необходимо было дописать еще один селектор в уже рабочий проект, я написал бы генератор или парсер css-файлов юзеров на PHP. А с новым можно подольше позаморачиваться.
Может, я неверно выразился ранее, ибо /default/css.css — это и есть те самые правила, не зависящие от скина. А /newskin/css.css — это скин одного человека. A /newskin2/css.css — это скин другого человека. Можно еще иметь некий — /firstskin/css.css — первоначальный скин, который будет для всех один.
«где надо» — так же тяжело поддерживать, как и в примере в топике, или так сложен сам процесс оверайта?
А в остальном — в чем проблема-то?
Дефолтный css грузится сначала с site/skin/default/css.css и дает ответ 304, затем грузится другой css с site/skin/newskin/css.css и, где надо, оверайтит дефолтный. Если браузер уже грузил этот файл, ему будет ответ 304.
Как иначе-то? Или я не понимаю вопроса. В топике говорится про неизбежные дополнительные вычисления на сервере, и, в следствие этого, мы вызываем xsl-процессор для вычисления разницы. А только на php мы вызываем php-интерпретатор для получения файла css и Memcache нас спасает.
Но если насчет кэширования — то тут все просто. Есть туча методов кэширования, например:
— Правильно настроенный апач (mod_expires + mod_headers + ETAG) — css (и не только) будут выходить с ответом «304 Not Modified». Но это, имхо, необходимо реализовывать на большинстве серверов. А чтобы css был новым, всегда когда его обновляем, можно прописать что-то типа: css2.css?20100510.
— Опять же в php можно очень просто подключить memcache и закэшировать все это. Плюс, если уж изврат, то хранить в базе, там кэш тоже есть.
«Silence, I kill you!»
Создаем для красоты три файла и пользуемся стандартным набором PHP:
1. css.php
<html><head><title>TEST CSS</title> <style type="text/css"> <?php require_once 'css2.php'; $file = file_get_contents('css2.css'); echo str_ireplace(array_keys($style_array), array_values($style_array), $file); ?> </style> </head> <body> <p class="body__p">TEST</p> </body> </html>2. css2.php
3. css2.css
.body__p{ font-size: $BODY__P-font-size; color: $BODY__P-color; }из кода все понятно, но все же кратенько:
css.php — основной шаблон, в котором подключается все остальное,
css2.php — перечень переменных,
css2.css — собственно файл css.
Насчет скорости работы сказать не могу — возможно, есть более быстрые решения с RegExp, или использование str_replace или в написании собственного парсера. Но при увеличении размера XML-файла время обработки тоже увеличится. Конечно, стоит добавить несколько проверок, например, на наличие файла. Этот так-называемый-парсер был создан за пару минут, но показывает, что все возможно банальным PHP еще даже 4ой версии, с которой я чертовски давно начинал. Ну, и конечно, все это можно подключить в еще один файл или использовать этот для создания конструкции вида
Если есть желание, все это можно переписать под объекты и использовать что-то типа или, к примеру
Но как ни назови, все равно — 6 секунд там, и 50мс здесь — это ощутимо.
Что на ХЦ, что на Агаве, что на Логоле сайты у меня открываются очень быстро, а вот с Кейвебом вышло так
Согласен, выглядит немного рекламно. Но, скорее это живая антиреклама ХЦ.
И заметьте, не даю ни одной ссылки.
По крайней мере, хорошо там, где я теперь есть.
А то я попробовал недавно keymachine.de — пинги просто ужасные!
Загрузка страниц начиналась от 6 секунд
Большая просьба, Вы когда в Хетцнер перейдете, отпишитесь здесь, хорошо?
Как оно там?
— открываем любой ГОСТ на любой странице
— ищем там строчку типа — заглядываем в этот файлик и видим —
.face { background-image : url(image.ashx?page=C6155677-1BA4-4363-A33A-9B0E5405419A); }— сохраняем этот файлик как gost-XXX-p-X.jpgЕсли пойти коротким путем, то можно заметить, что часть первоначального урла совпадает с урлом той самой картинки, что нам нужна. Дальше надо найти урл следующей страницы и парсить до конца.
IE6 — 4/4
Тема интересная, обязательно пишите — я вот уверен, что по низкочастотникам можно выйти в топ просто так — правильная страница — и все.