Pull to refresh

Comments 57

Только в сафари 4.0.5 (win7) не захотело работать, в отличии от вашего примера из предыдущей статьи.
А так все норм, спасибо за хорошие рецепты.
UFO just landed and posted this here
А чем отличается от дополнительного стиля, который перекрывает дефолтные, кроме того что грузит клиента?
В каком смысле?

Вот есть параметры пользователя, я их вытащил из базы и засунул в шаблон. Мне лично пофиг какого формата этот шаблон.
При изменении параметра я все равно буду править шаблон и базу и страницы с установками. И объем не меняется.
Ну тогда в нем параметры останутся прежними.
Потому что не измененные
что они забыли в других местах кроме файла скина??
lol
например в форме для изменения
в исходниках формы? что в вёрстке забыли конкретные значения полей формы?
я разве сказал в исходниках? в значении полей формы.
они возьмутся из скина
ок, хотя мои есть в том сомнения что это эффективно.
Как они из формы попадут в новый скин?
специально обученные обезьянки будут принимать пост запросы и впечатывать их в соответствующие файлы х)
Тем, что это любимая технология автора поста ^_^
А внешний css можно так же обработать?
нет. только css трансформированный в xsl
круто, возможно пригодится. спасибо автору, очень интересны статьи на эту тематику, раньше никто про это не писал.
Читаю вас уже не первый раз, и опять не первый раз убеждаюсь в том, что можно и не использовать XSLT. Пост в очередной раз задел за живое, поэтому продолжаю попытки избежать использования XSLT с помощью PHP.

Создаем для красоты три файла и пользуемся стандартным набором 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
абзац про кэширование ты проигнорировал по какой причине?
А где он? Пардон, но на странице я обнаружил два слова, содержащие фразу «кэш» («cache» — вообще отсутствует) — в Похожих публикациях и в твоем посте, но никак не в топике.

Но если насчет кэширования — то тут все просто. Есть туча методов кэширования, например:
— Правильно настроенный апач (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 нас спасает.
есть правила, которые не зависят от скина. и при посещении блогов 10 разных людей мы получим 10 кратную загрузку этих правил

«где надо» — тяжело поддерживать
Чем же вариант на XSL спасает нас от этого?

Может, я неверно выразился ранее, ибо /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
В данном случае согласен!

В PHP либо надстройка над css-файлом, которая прописывает все стили, которые будут добавлены. Но опытный программист (как и опытный верстальщик) должен учитывать практически все варианты. Это как с проектированием БД — если после долгого использования ты изменяешь БД — это неправильно (опять же, есть исключения).

Если бы необходимо было дописать еще один селектор в уже рабочий проект, я написал бы генератор или парсер css-файлов юзеров на PHP. А с новым можно подольше позаморачиваться.
эм… и это получилось бы проще, чем предложенный мною способ? х)
Парсер, скорее всего, конечно, не проще.

Но, поскрипев мозгами (чего стоит делать, несомненно, чаще), предлагаю такой способ:

Дописываем в файл /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-правила. Не блогохостинг, но соцсеть.

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

Но это только в этом случае. А теперь надо представить, что xslt будет обслуживать не только этот момент, но и все остальное, иначе как это — мы используем всю мощь xslt только тут, нафига тогда оно нам надо?
пхп ты тоже на всю мощь используешь? у тебя все скрипты многопоточные? ведь там есть такая возможность.
Я к тому, что нам придется загружать XSLT-процессор постоянно или только для выполнения такого маневра.
он и так постоянно загружен
ты пропатчил свой фаерфокс?
Эммм… наверное, не до такой степени
По-моему изврат. Элегантно, но — изврат. Не надо использовать XSLT там, где ему не место.
JS, говорите, отключают? Кто? Либо те, кто в этом понимает (а, значит, и понимает, что интерактивности от странички можно не ждать), либо он отключен на рабочем компе админом (ибо нефиг в рабочее время в бложики писать).
причём тут интерактивность и бложики?
Мда, у вас конечно очень интересные идеи в постах, но почему всюду надо использовать этот богомерзкий нечитабельный XML??
Пардон за оффтопик, но напомнило
«Silence, I kill you!»
альтернатива, я так понимаю, json со своими закрытиями объектов и массивов аля ]]}]]}}]}}}?
я специально добавляю слили через аттрибут и использую 2 хака — один для ИЕ, другой — для вебкита. именно для того, чтобы в цсс небыло xml-я
UFO just landed and posted this here
оборачивание в style, ибо он не поддерживает data-uri
Sign up to leave a comment.

Articles