Комментарии 57
Только в сафари 4.0.5 (win7) не захотело работать, в отличии от вашего примера из предыдущей статьи.
А так все норм, спасибо за хорошие рецепты.
А так все норм, спасибо за хорошие рецепты.
НЛО прилетело и опубликовало эту надпись здесь
А чем отличается от дополнительного стиля, который перекрывает дефолтные, кроме того что грузит клиента?
проще в поддержке
В каком смысле?
Вот есть параметры пользователя, я их вытащил из базы и засунул в шаблон. Мне лично пофиг какого формата этот шаблон.
При изменении параметра я все равно буду править шаблон и базу и страницы с установками. И объем не меняется.
Вот есть параметры пользователя, я их вытащил из базы и засунул в шаблон. Мне лично пофиг какого формата этот шаблон.
При изменении параметра я все равно буду править шаблон и базу и страницы с установками. И объем не меняется.
Тем, что это любимая технология автора поста ^_^
А внешний css можно так же обработать?
круто, возможно пригодится. спасибо автору, очень интересны статьи на эту тематику, раньше никто про это не писал.
не круто
Читаю вас уже не первый раз, и опять не первый раз убеждаюсь в том, что можно и не использовать XSLT. Пост в очередной раз задел за живое, поэтому продолжаю попытки избежать использования XSLT с помощью PHP.
Создаем для красоты три файла и пользуемся стандартным набором PHP:
1. css.php
2. css2.php
3. css2.css
из кода все понятно, но все же кратенько:
css.php — основной шаблон, в котором подключается все остальное,
css2.php — перечень переменных,
css2.css — собственно файл css.
Насчет скорости работы сказать не могу — возможно, есть более быстрые решения с RegExp, или использование str_replace или в написании собственного парсера. Но при увеличении размера XML-файла время обработки тоже увеличится. Конечно, стоит добавить несколько проверок, например, на наличие файла. Этот так-называемый-парсер был создан за пару минут, но показывает, что все возможно банальным PHP еще даже 4ой версии, с которой я чертовски давно начинал. Ну, и конечно, все это можно подключить в еще один файл или использовать этот для создания конструкции вида
Если есть желание, все это можно переписать под объекты и использовать что-то типа
Создаем для красоты три файла и пользуемся стандартным набором 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
<?php $style_array = array( '$BODY__P-font-size' => '68px', '$BODY__P-color' => '#FF6600' ); ?>
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ой версии, с которой я чертовски давно начинал. Ну, и конечно, все это можно подключить в еще один файл или использовать этот для создания конструкции вида
<link rel="stylesheet" href="/css.php" type="text/css" />.
Если есть желание, все это можно переписать под объекты и использовать что-то типа
$body->p->maintext->colorили, к примеру
$body->p->font['size'].
согласен, всё должно быть просто и красиво.
Программные интерфейсы должны быть простыми и красивыми. Здесь они таковыми являются.
Что до внутреннего устройства программы: XSLT-верстарь заценит красоту реализации.
Хотя вообще, я свое мнениениже изложил: habrahabr.ru/blogs/css/93118/#comment_2823530
Что до внутреннего устройства программы: XSLT-верстарь заценит красоту реализации.
Хотя вообще, я свое мнениениже изложил: habrahabr.ru/blogs/css/93118/#comment_2823530
абзац про кэширование ты проигнорировал по какой причине?
А где он? Пардон, но на странице я обнаружил два слова, содержащие фразу «кэш» («cache» — вообще отсутствует) — в Похожих публикациях и в твоем посте, но никак не в топике.
Но если насчет кэширования — то тут все просто. Есть туча методов кэширования, например:
— Правильно настроенный апач (mod_expires + mod_headers + ETAG) — css (и не только) будут выходить с ответом «304 Not Modified». Но это, имхо, необходимо реализовывать на большинстве серверов. А чтобы css был новым, всегда когда его обновляем, можно прописать что-то типа: css2.css?20100510.
— Опять же в php можно очень просто подключить memcache и закэшировать все это. Плюс, если уж изврат, то хранить в базе, там кэш тоже есть.
Но если насчет кэширования — то тут все просто. Есть туча методов кэширования, например:
— Правильно настроенный апач (mod_expires + mod_headers + ETAG) — css (и не только) будут выходить с ответом «304 Not Modified». Но это, имхо, необходимо реализовывать на большинстве серверов. А чтобы css был новым, всегда когда его обновляем, можно прописать что-то типа: css2.css?20100510.
— Опять же в php можно очень просто подключить memcache и закэшировать все это. Плюс, если уж изврат, то хранить в базе, там кэш тоже есть.
второй абзац.
правильно реализованное кэширование — не делает запроса к серверу вообще.
правильно реализованное кэширование — не делает запроса к серверу вообще.
Ну как это не делает? Сервер на каждый запрос должен выдать какой-либо ответ — 304 или 200 или даже 302.
А в остальном — в чем проблема-то?
Дефолтный css грузится сначала с site/skin/default/css.css и дает ответ 304, затем грузится другой css с site/skin/newskin/css.css и, где надо, оверайтит дефолтный. Если браузер уже грузил этот файл, ему будет ответ 304.
Как иначе-то? Или я не понимаю вопроса. В топике говорится про неизбежные дополнительные вычисления на сервере, и, в следствие этого, мы вызываем xsl-процессор для вычисления разницы. А только на php мы вызываем php-интерпретатор для получения файла css и Memcache нас спасает.
А в остальном — в чем проблема-то?
Дефолтный css грузится сначала с site/skin/default/css.css и дает ответ 304, затем грузится другой css с site/skin/newskin/css.css и, где надо, оверайтит дефолтный. Если браузер уже грузил этот файл, ему будет ответ 304.
Как иначе-то? Или я не понимаю вопроса. В топике говорится про неизбежные дополнительные вычисления на сервере, и, в следствие этого, мы вызываем xsl-процессор для вычисления разницы. А только на php мы вызываем php-интерпретатор для получения файла css и Memcache нас спасает.
есть правила, которые не зависят от скина. и при посещении блогов 10 разных людей мы получим 10 кратную загрузку этих правил
«где надо» — тяжело поддерживать
«где надо» — тяжело поддерживать
Чем же вариант на XSL спасает нас от этого?
Может, я неверно выразился ранее, ибо /default/css.css — это и есть те самые правила, не зависящие от скина. А /newskin/css.css — это скин одного человека. A /newskin2/css.css — это скин другого человека. Можно еще иметь некий — /firstskin/css.css — первоначальный скин, который будет для всех один.
«где надо» — так же тяжело поддерживать, как и в примере в топике, или так сложен сам процесс оверайта?
Может, я неверно выразился ранее, ибо /default/css.css — это и есть те самые правила, не зависящие от скина. А /newskin/css.css — это скин одного человека. A /newskin2/css.css — это скин другого человека. Можно еще иметь некий — /firstskin/css.css — первоначальный скин, который будет для всех один.
«где надо» — так же тяжело поддерживать, как и в примере в топике, или так сложен сам процесс оверайта?
сложен процесс синхронизации изменений. когда изменив селектор в дефолтном стиле тебе придётся изменить этот же селектор и во всех скинах.
Можно пример?
def: p, dl { border: 1px solid steelblue }
skin: p, dl { border-color: red }
надо добавить аналогичный бордер и для blockquote
skin: p, dl { border-color: red }
надо добавить аналогичный бордер и для blockquote
В данном случае согласен!
В PHP либо надстройка над css-файлом, которая прописывает все стили, которые будут добавлены. Но опытный программист (как и опытный верстальщик) должен учитывать практически все варианты. Это как с проектированием БД — если после долгого использования ты изменяешь БД — это неправильно (опять же, есть исключения).
Если бы необходимо было дописать еще один селектор в уже рабочий проект, я написал бы генератор или парсер css-файлов юзеров на PHP. А с новым можно подольше позаморачиваться.
В PHP либо надстройка над css-файлом, которая прописывает все стили, которые будут добавлены. Но опытный программист (как и опытный верстальщик) должен учитывать практически все варианты. Это как с проектированием БД — если после долгого использования ты изменяешь БД — это неправильно (опять же, есть исключения).
Если бы необходимо было дописать еще один селектор в уже рабочий проект, я написал бы генератор или парсер css-файлов юзеров на PHP. А с новым можно подольше позаморачиваться.
эм… и это получилось бы проще, чем предложенный мною способ? х)
Парсер, скорее всего, конечно, не проще.
Но, поскрипев мозгами (чего стоит делать, несомненно, чаще), предлагаю такой способ:
Дописываем в файл /newskin/css.css следующее:
В файл, где хранятся все дефолтные значения скина css2.php
Собственно, дополнительную часть скина ($STOR->user_custom_zone) храним в БД или в файле, не суть.
Теперь при добавлении blockquote, он добавится во все css, а юзеру позже придется в своей «user_custom_zone» добавить
Твой способ, конечно, где-то проще, но он находится на границе с очень редковстречаемой частностью. Но городить для этой частности XSL и все связанное — по-моему, как уже неоднократно употреблялось здесь, изврат.
Вообще, изначально, предложенный мною вариант был создан с целью показать, что все можно сделать без XSL довольно быстро и просто. Теперь, если полезли в частности, как и ожидалось, вариант усложнился, скрип мозгов стал громче. Двоеточие-скобка
Но, поскрипев мозгами (чего стоит делать, несомненно, чаще), предлагаю такой способ:
Дописываем в файл /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 довольно быстро и просто. Теперь, если полезли в частности, как и ожидалось, вариант усложнился, скрип мозгов стал громче. Двоеточие-скобка
ты предлагаешь дать юзеру возможность писать напрямую css правила?
Определить список разрешенных селекторов в таблице «Кастом_нью_селектор»: «id | selector_name | default_value».
Создать таблицу связей: «selector_id | user_id | value».
Кстати, вместо user_id может быть, стоит использовать site_id.
И вот теперь уже с помощью одного foreach можно не давать юзеру писать все цсс-правила, а только значения.
Но, в принципе, а чем я хуже людей, сделавших Social Engine? В этом движке каждый пользователь может писать css-правила. Не блогохостинг, но соцсеть.
А вообще — да, предлагаю, но только в платном аккаунте.
Создать таблицу связей: «selector_id | user_id | value».
Кстати, вместо user_id может быть, стоит использовать site_id.
И вот теперь уже с помощью одного foreach можно не давать юзеру писать все цсс-правила, а только значения.
Но, в принципе, а чем я хуже людей, сделавших Social Engine? В этом движке каждый пользователь может писать css-правила. Не блогохостинг, но соцсеть.
А вообще — да, предлагаю, но только в платном аккаунте.
наверно тем, что не видишь к какому гигантскому геморрою приводит твоя боязнь использовать xslt.
Не вижу. Я вижу другое — нет смысла использовать что-то немерянно-громоздкое там, где можно прекрасно без этого обойтись. Данная ситуация — это большая частность, в которой xslt, возможно, немного выигрывает в каком-то моменте.
Но это только в этом случае. А теперь надо представить, что xslt будет обслуживать не только этот момент, но и все остальное, иначе как это — мы используем всю мощь xslt только тут, нафига тогда оно нам надо?
Но это только в этом случае. А теперь надо представить, что xslt будет обслуживать не только этот момент, но и все остальное, иначе как это — мы используем всю мощь xslt только тут, нафига тогда оно нам надо?
По-моему изврат. Элегантно, но — изврат. Не надо использовать XSLT там, где ему не место.
JS, говорите, отключают? Кто? Либо те, кто в этом понимает (а, значит, и понимает, что интерактивности от странички можно не ждать), либо он отключен на рабочем компе админом (ибо нефиг в рабочее время в бложики писать).
JS, говорите, отключают? Кто? Либо те, кто в этом понимает (а, значит, и понимает, что интерактивности от странички можно не ждать), либо он отключен на рабочем компе админом (ибо нефиг в рабочее время в бложики писать).
Мда, у вас конечно очень интересные идеи в постах, но почему всюду надо использовать этот богомерзкий нечитабельный XML??
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Препроцессинг CSS на клиенте