Cyrax_02

Понаблюдал. Что получается в версии 1.3.0:

1. При пересоздании конечного минимизированного файла предыдущий файл не удаляется. Тем самым, папка будет быстро и бесконтрольно пухнуть.
2. Конечный минимизированный файл пересоздаётся только в том случае, если меняется хэш содержимого минимизированного файла. Т.е. если изменить содержимое некоторого комментария исходного файла, то минимизированный файл пересоздаваться не будет, хотя исходный файл изменён. Логично.

3. Если не очищать кэш modx, то конечный минимизированный файл в версии 1.3.0 пересоздаётся так же быстро, как и в версии 1.2.2.
4. Если в версии 1.3.0 очистить кэш modx, то minifyX отрабатывает очень долго (в 10 раз дольше), не зависимо от того, пересоздаётся конечный минимизированный файл или нет.

Возникает вопрос: что делает MinifyX 1.3.0 при очистке кэша modx ?

У меня формируется 2 минимизированных файла (их размер различается в 10 раз):
.css размером 20 Кб
.js размером 200 Кб

В версии 1.2.2 скорость формирования этих файлах такая:
.css — x
.js — 10х

В версии 1.3.0 скорость отработки minifyX без очистки кэша modx (не зависимо от того, пересоздаются минимизированные файлы или нет):
.css — x
.js — 10х

В версии 1.3.0 скорость отработки minifyX после очистки кэша modx (не зависимо от того, пересоздаются минимизированные файлы или нет):
.css — x
.js — 100х
Т.е. здесь обработка .js выполняется уже в 100 раз дольше .css, хотя размер его в 10 раз больше .css

Может, последняя версия munee при обработке .js-файлов выполняет ещё какую-то масштабную обработку? Причём эта дополнительная масштабная обработка выполняется только при очистке кэша modx. Если кэш modx не очищать, то даже при пересоздании минимизированных файлов MinifyX 1.3.0 отрабатывает быстро (как и 1.2.2).

Так причина перегенерации файлов при очистке кэша modx тоже неизвестна?

у меня всё по-прежнему быстро

Об этом можно судить только протестировав время для двух вариантов. Я протестировал. Время увеличилось в 4 раза. Уверен, что и у любого другого протестировавшего разница будет существенной.

Так в чём же причина?
а) более долгой обработки
б) связи с кэшем modx?

Редактирую и сохраняю в редакторе modx

Блин. Что xpdo учитывает только тип данных, указанный в модели, и что xpdo НЕ учитывает тип TV-параметра, указанный в его свойствах, — это понятно.

Не понятно, почему xpdo не учитывает тип TV-параметра, указанный в его свойствах. Следуя концепции TV-параметров, при формировании SQL нужно учитывать тип TV-параметра, указанный в его свойствах. Если указан числовой тип, то и операции сравнения должны быть числовыми (значение не должно заключаться в скобки). А то, что на уровне БД значения TV имеют строковый тип — это исключительно способ хранения данных, который выбрали разработчики modx.

Согласно концепции TV-параметров, эти параметры являются типизированными. Соотсветственно, и способ их обработки должен отвечать их типу. xpdo всё мешает в кучу.

Я хочу сказать, что даже если и записать поле CAST'ом:

$modx->where(array('`TV`.`value` AS DECIMAL(13,3):<' => 0))

то xpdo всё равно сформирует sql-запрос со строковым сравнением (заключит нуль в кавычки):

WHERE `TV`.`value` AS DECIMAL(13,3) <= '0'

Это ответ на пример с ORDER BY CAST

Запиши тот же самый CAST:

ORDER BY CAST(`TV`.`value` AS DECIMAL(13,3))

но для условия where (TV.value < 0)

Хотелось бы решить задачу, не исключая значение из xpdo-обработки

Нелогично получается с точки зрения modx: тип TV-поля указывать можно, все необходимые операции с такими TV-полями посредством xpdo можно выполнять (т.е. формируем почти любые запросы), а корректно сравнивать числовые TV (элементарная операция) посредством xpdo — нельзя. Серьёзная дыра в модели xpdo. Не иначе.

Да, с полями ресурсов xpdo работает нормально.
Не указал сразу — речь идёт о полях TV. При работе с TV xpdo всегода заключает значения в кавычки.
Да, значения TV-полей физически (на уровне БД) имеют строковый тип. Но xpdo не принимает во внимание тип этих полей, указанных в свойствах TV. Всегда рассматривает их как строки.

Здорово. Стоит попробовать.
Можно даже и без использования HTML5 реализовать. Будет работать и на старых браузерах.

Пока такого мнения: для игр и прочих сложных интерактивных анимаций — flash, для рекламных баннеров — HTML5.
Впрочем, в идеале можно предусмотреть и комплексный вариант: в зависимости от платформы и версии браузера использовать либо HTML5-реализацию баннера, либо flash-реализацию…

Да, ещё KIS (по крайней мере, 12-й) загружает проц на 100% при наличии на странице баннеров. Вернее, процесс браузера (Opera, FF) при наличии анимационных баннеров загружает проц на 100% при работающем KIS. Впрочем, это уже оффтоп…

Да. А в вашей компании Simple Dream веб-дизайнеры какого мнения?

Угу. Кратко и сердито ))

Вот тебе исходный код, ищи ошибку — там всего 266 строк. Если найдешь — исправлю.

Ну… ошибки обычно ищут в имеющемся функционале. А если у тебя нет проверки набора исходных файлов? Где ошибку-то искать? Здесь уже корректнее говорить не о поиске ошибок, а о доработке функционала.

Вот как у тебя формируется имя готового файла:

$file = $this->config['jsFilename'] . '_' . $time . $this->config['jsExt'];

Здесь присутствует только время создания. А информации о наборе исходных файлов, которым соответствует этот минимизированный файл, нет. Напрашивается добавить ещё и хэш от набора полных имён исходных файлов.

Вот здесь выполняется поиск минимизированных файлов, имеющих в имени baseFilename, '_' и 10 цифр, тогда как такие минимизированные файлы могут соответствовать совсем другим наборам исходных файлов:

<pre class="prettyprint">// Get the latest cache files
                $this->config['cacheFolder'] = $cacheFolder = MODX_BASE_PATH . $full_path;
                $regexp = '('.$this->config['jsFilename'].'|'.$this->config['cssFilename'].')';
                $regexp .= '_(\d{10})';
                $regexp .= '('.$this->config['jsExt'].'|'.$this->config['cssExt'].')';

                $files = scandir($cacheFolder);
                foreach ($files as $file) {
                        if ($file == '.' || $file == '..') {continue;}

                        if (preg_match("/^$regexp$/iu", $file, $matches)) {
                                if ($matches[3] == $this->config['jsExt']) {
                                        $this->current['js'][] = array(
                                                'file' => $matches[0],
                                                'time' => filemtime($cacheFolder . $file),
                                        );
                                }
                                else {
                                        $this->current['css'][] = array(
                                                'file' => $matches[0],
                                                'time' => filemtime($cacheFolder . $file),
                                        );
                                }
                        }
                }

Особенно при том, что у других людей таких вопросов вообще не возникает?

Причин много:
1. На разных страницах сайта подключают одинаковые наборы файлов. В этом случае озвученная проблема себя никак не проявит.
2. Указывают разные базовые имена на каждой странице портала. В этом случае озвученная проблема себя никак не проявит.
3. Те, кто сталкивается с проблемами в работе MinifyX, отказываются от этого сниппета, не разобравшись в причинах проблем. Например, Муравьев Артём. Не все же могут себе позволить «торчать» с каждым сниппетом по 3 недели.
4. Ещё не обратили внимания на проблему.
5. Скромничают.
6. Перешли на другую CMS.

Василий, это штатное (задуманное) поведение MinifyX или нет?

Проблема №3. При одинаковых cssFileName MinifyX почему-то работает с одним и тем же файлом для разных наборов исходных файлов.
Например, для одной страницы (шаблона) указываем один набор параметров. Загружаем страницу => MinifyX создаёт минимизированный файл.
Далее на другой странице вызываем MinifyX с другим набором исходных файлов, но с тем же cssFileName. Загружаем эту страницу. В итоге MinifyX ничего не создаёт и подключает уже существующий минимизированный файл (содержащий стили для предыдущей страницы). Со всеми вытекающими.

Для обхода проблемы приходится для каждого набора подключаемых файлов указывать разные cssFileName.

Да, так и есть. Если менять исходный файл средствами modx, то время его изменения выставляется серверное и минимизированный файл обновляется только 1 раз.

Похоже, дело в WinSCP. Он у меня локальное (виндовое) время выставляет, а MinifyX — серверное.

У тебя там время изменения минимизированного файла неправильно выставляется. После первого обновления страницы (после изменения исходного файла) оно примерно на минуту меньше, чем время изменения исходного файла. И при каждом обновлении страницы создаётся новый минимизированный файл (по понятным причинам), при этом время его изменения понемногу увеличивается. И когда время его изменения перевалит за время изменения исходного файла, обновляться он перестаёт.