Несколько советов для PHP-разработчиков

//хардкод «магических чисел»— это дурные привычки, которых надо избегать
Не покушайтесь на любимую 0x5f375a86! :)

Php + Cache + Tags = phpCacheTag

И еще баг репорт(помимо того, что класс для кеширования не кеширует):

example.php:
Notice: Undefined index: user in CacheTag.class.php on line 290
Warning: array_diff() [function.array-diff]: Argument #1 is not an array in CacheTag.class.php on line 290

Php + Cache + Tags = phpCacheTag

Что-то странное. Дефолтный конфиг из свн и следующий код:

error_reporting(E_ALL);
require_once("CacheTag.class.php");

function f()
{
  return 2;
}

CacheTag::SetBackend('Memcache');
CacheTag::SetFunction('f');
CacheTag::SetTags(CacheTag::TAG_PRODUCT);
$res = CacheTag::Fetch().'<br>';

echo $res;


Генерируют вот такую цепочку вызовов:

SetBackend abstract class CacheTag
SetFunction abstract class CacheTag
GetInstance abstract class CacheTag
ImportBackend abstract class CacheTag
Memcache construct
__construct abstract class CacheTag
Memcache Get
SetTags abstract class CacheTag
GetInstance abstract class CacheTag
Fetch abstract class CacheTag
GetInstance abstract class CacheTag
Prepare abstract class CacheTag
GetVarName abstract class CacheTag
Memcache Get
IsRegistered abstract class CacheTag
GetFunctionValue abstract class CacheTag
ApplyTagsChange abstract class CacheTag
Memcache Set
ResetSettings abstract class CacheTag
2
__destruct abstract class CacheTag
SaveResetTags abstract class CacheTag
Memcache Replace


И так при каждом обновлении страницы. Т.е. из кэша ничего не берется.
Я что-то делаю не так?

PS: 5.2.13, memcache 2.2.5.

Php + Cache + Tags = phpCacheTag

Вы нумеруете версии 0.х.х просто потому что нравится так или планируется релиз 1.0 через N времени?

Smarty против XSLT

Я это понимаю. Потому и попросил пример со сложным шаблонам. Так уж получилось, что голова пока не мыслит не о каких трансформациях. Да, есть xml- с ним приятно работать как с callback`ами, есть html- на нём все собаку сьели, есть xslt, о котором много говорят, но в моей сфере он используется лишь в одном проекте(однако и в нём есть быстрая кнопка-'хочу smarty').

Зачем же кричать?

Smarty против XSLT

Я немного не в статьях. Да и мыслить категориями страниц имхо прошлый век. В умах людей во всю эпичное блочное кэширование и вся сила его с нами.

Как оно у меня: есть страница, побитая на блоки(назовём её главная). В странице три динамических элемента и туева хуча настраиваемых(телефоны, тайтлы, тексты). Так зачем нам по 6 тысяч раз на дню псевдо-статику перерисовывать при том, что мы знаем, что она редко изменяется? Такие части сохраняются в кэш и успешно из него тыкаются, пока кто-то что-то на псевдо-статике не изменит. Получается шустро.

Smarty против XSLT

Так оно ж не вечное. Поставил лимит в 20 минут и будь уверен, что 20 минут нагрузку не жди.

PS: Нафиг на сайтах-визитках вообще шаблонизатор? :D

Smarty против XSLT

Увеличил до 4 тысяч интераций. Пропорции результата те же.
Может быть разовьем идею тестов и вы покажите действительно сложный шаблон, на котором будет иметь место проводить тесты?

Smarty против XSLT

Оно не будет быстрее голого php.

Однако переучивать дизайнеров и верстальщиков дорогого стоит. Посему- пока невозможно. Эхх.

Smarty против XSLT

PHP:
total(усредненно за 20 пробегов): 93

Smarty:
total(усредненно за 20 пробегов): 970

XSLT:
total(усредненно за 20 пробегов): 90

Вывод- молодцы те люди, что писали php_xsl.dll.

Smarty против XSLT

О, узрел знакомые лица.
tenshi, запакуй исходники из теста куда-нибудь и дай поиграть. Авось другие результаты получятся :)

Smarty против XSLT

//Что касается субъективной оценки 2х технологий, то я бы в любом случае предпочел XSLT, т.к. это
//стандарт, рекомендованный W3C и имеющий официальную поддержку консорциума, как минимум.

А что и с чем вы сравниваете?

Mushroom Kingdom Fusion v0.41 Beta

Полазил по форуму- оно еще и замечательно поддается моддингу, люди активно работают.
Для желающих скачать: размер архива 170 мб.

Mushroom Kingdom Fusion v0.41 Beta

Интересный коктейль. Теперь лишь понять насколько удобно и интересно играть.
Автор, вы не поделитесь впечатлениями?

Простой способ немного разгрузить инициализацию javascript на странице

Протупил. Про цикл, когда элементов==0 понял. Однако всё равно вижу этот вариант менее красивым, чем проверки в самих функциях, а какие-либо действия в DOM-ready неудобным.
Загрузили дерево->вызвали функцию->функция проверила существование всех необходимых структур и либо выполняется, либо нет.

Может быть для маленьких приложений код хранить в domready.js и допустимо, но когда мы имеем хоть сколько-нибудь большое приложение сопровождать 300-500 строк мешанины становится трудно.

Простой способ немного разгрузить инициализацию javascript на странице

Неверно выразился. Естественно на класс функцию не повесишь.
Код из песочницы(по методу автора):

$(document).ready(function() {

    if($('.element').length) {
      $('.element').myUserFunction(200,23);
    }

    if($('.element2').length) {
      $('.element2').myUser2Function(24332,123);
    }

});

* This source code was highlighted with Source Code Highlighter.

Лично я просто проверяю входящие параметры в функциях и пока не очень понимаю будет ли удобнее писать 20-30 конструкций if и тем самым засорять domready.js. И будет ли это быстрее. Как по-вашему должен выглядеть этот код?

Простой способ немного разгрузить инициализацию javascript на странице

Миллион их. Недавно разбирался в коде одного западного магазина, так там 500кб ужатых скриптов тянулись на каждой странице.

Простой способ немного разгрузить инициализацию javascript на странице

А зачем тут цикл? Предположим у меня есть функция, которая вешается на '.class' при DOM ready. Какой смысл мне это делать количество раз, равное количеству классов?