В каком смысле?

Вот есть параметры пользователя, я их вытащил из базы и засунул в шаблон. Мне лично пофиг какого формата этот шаблон.
При изменении параметра я все равно буду править шаблон и базу и страницы с установками. И объем не меняется.

tenshi 10 мая 2010 в 15:08

а я не буду

Wott 10 мая 2010 в 22:21

Ну тогда в нем параметры останутся прежними.

tenshi 11 мая 2010 в 04:58

с чего бы?

Wott 11 мая 2010 в 16:57

Потому что не измененные

tenshi 11 мая 2010 в 23:35

что они забыли в других местах кроме файла скина??

Wott 11 мая 2010 в 23:48

lol
например в форме для изменения

tenshi 12 мая 2010 в 08:16

в исходниках формы? что в вёрстке забыли конкретные значения полей формы?

Wott 12 мая 2010 в 18:23

я разве сказал в исходниках? в значении полей формы.

tenshi 12 мая 2010 в 21:02

они возьмутся из скина

Wott 12 мая 2010 в 22:41

ок, хотя мои есть в том сомнения что это эффективно.
Как они из формы попадут в новый скин?

tenshi 12 мая 2010 в 22:43

специально обученные обезьянки будут принимать пост запросы и впечатывать их в соответствующие файлы х)

pepelsbey 9 мая 2010 в 07:56

Тем, что это любимая технология автора поста ^_^

tenshi 10 мая 2010 в 15:10

не спроста

sitehound 9 мая 2010 в 06:27

А внешний css можно так же обработать?

tenshi 9 мая 2010 в 06:33

нет. только css трансформированный в xsl

heruvim 9 мая 2010 в 08:04

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

SwampRunner 9 мая 2010 в 08:09

не круто

orloffkirill 9 мая 2010 в 09:41

Читаю вас уже не первый раз, и опять не первый раз убеждаюсь в том, что можно и не использовать 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'].

SwampRunner 9 мая 2010 в 10:14

согласен, всё должно быть просто и красиво.

Grundiss 9 мая 2010 в 11:11

Программные интерфейсы должны быть простыми и красивыми. Здесь они таковыми являются.
Что до внутреннего устройства программы: XSLT-верстарь заценит красоту реализации.
Хотя вообще, я свое мнениениже изложил: habrahabr.ru/blogs/css/93118/#comment_2823530

tenshi 10 мая 2010 в 15:17

абзац про кэширование ты проигнорировал по какой причине?

orloffkirill 10 мая 2010 в 15:29

А где он? Пардон, но на странице я обнаружил два слова, содержащие фразу «кэш» («cache» — вообще отсутствует) — в Похожих публикациях и в твоем посте, но никак не в топике.

Но если насчет кэширования — то тут все просто. Есть туча методов кэширования, например:
— Правильно настроенный апач (mod_expires + mod_headers + ETAG) — css (и не только) будут выходить с ответом «304 Not Modified». Но это, имхо, необходимо реализовывать на большинстве серверов. А чтобы css был новым, всегда когда его обновляем, можно прописать что-то типа: css2.css?20100510.
— Опять же в php можно очень просто подключить memcache и закэшировать все это. Плюс, если уж изврат, то хранить в базе, там кэш тоже есть.

tenshi 10 мая 2010 в 15:35

второй абзац.

правильно реализованное кэширование — не делает запроса к серверу вообще.

orloffkirill 10 мая 2010 в 15:54

Ну как это не делает? Сервер на каждый запрос должен выдать какой-либо ответ — 304 или 200 или даже 302.

А в остальном — в чем проблема-то?

Дефолтный css грузится сначала с site/skin/default/css.css и дает ответ 304, затем грузится другой css с site/skin/newskin/css.css и, где надо, оверайтит дефолтный. Если браузер уже грузил этот файл, ему будет ответ 304.

Как иначе-то? Или я не понимаю вопроса. В топике говорится про неизбежные дополнительные вычисления на сервере, и, в следствие этого, мы вызываем xsl-процессор для вычисления разницы. А только на php мы вызываем php-интерпретатор для получения файла css и Memcache нас спасает.

tenshi 10 мая 2010 в 17:14

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

«где надо» — тяжело поддерживать

orloffkirill 10 мая 2010 в 17:41

Чем же вариант на XSL спасает нас от этого?

Может, я неверно выразился ранее, ибо /default/css.css — это и есть те самые правила, не зависящие от скина. А /newskin/css.css — это скин одного человека. A /newskin2/css.css — это скин другого человека. Можно еще иметь некий — /firstskin/css.css — первоначальный скин, который будет для всех один.

«где надо» — так же тяжело поддерживать, как и в примере в топике, или так сложен сам процесс оверайта?

tenshi 10 мая 2010 в 17:52

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

orloffkirill 10 мая 2010 в 17:55

Можно пример?

tenshi 10 мая 2010 в 17:57

def: p, dl { border: 1px solid steelblue }
skin: p, dl { border-color: red }

надо добавить аналогичный бордер и для blockquote

orloffkirill 10 мая 2010 в 18:05

В данном случае согласен!

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

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

tenshi 10 мая 2010 в 18:56

эм… и это получилось бы проще, чем предложенный мною способ? х)

orloffkirill 10 мая 2010 в 19:54

Парсер, скорее всего, конечно, не проще.

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

Дописываем в файл /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 довольно быстро и просто. Теперь, если полезли в частности, как и ожидалось, вариант усложнился, скрип мозгов стал громче. Двоеточие-скобка

tenshi 11 мая 2010 в 04:58

ты предлагаешь дать юзеру возможность писать напрямую css правила?

orloffkirill 11 мая 2010 в 06:00

Определить список разрешенных селекторов в таблице «Кастом_нью_селектор»: «id | selector_name | default_value».
Создать таблицу связей: «selector_id | user_id | value».
Кстати, вместо user_id может быть, стоит использовать site_id.
И вот теперь уже с помощью одного foreach можно не давать юзеру писать все цсс-правила, а только значения.

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

А вообще — да, предлагаю, но только в платном аккаунте.

tenshi 11 мая 2010 в 06:16

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

orloffkirill 11 мая 2010 в 06:24

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

Но это только в этом случае. А теперь надо представить, что xslt будет обслуживать не только этот момент, но и все остальное, иначе как это — мы используем всю мощь xslt только тут, нафига тогда оно нам надо?

tenshi 11 мая 2010 в 06:37

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

orloffkirill 11 мая 2010 в 06:39

Я к тому, что нам придется загружать XSLT-процессор постоянно или только для выполнения такого маневра.

tenshi 11 мая 2010 в 06:42

он и так постоянно загружен

orloffkirill 11 мая 2010 в 06:46

у меня — нет

tenshi 11 мая 2010 в 06:58

ты пропатчил свой фаерфокс?

orloffkirill 11 мая 2010 в 07:27

Эммм… наверное, не до такой степени

Grundiss 9 мая 2010 в 10:56

По-моему изврат. Элегантно, но — изврат. Не надо использовать XSLT там, где ему не место.
JS, говорите, отключают? Кто? Либо те, кто в этом понимает (а, значит, и понимает, что интерактивности от странички можно не ждать), либо он отключен на рабочем компе админом (ибо нефиг в рабочее время в бложики писать).