Сергей Шлоков

С нами с 31 января 2013; Место в рейтинге пользователей: #3

Сергей Шлоков

06 октября 2015, 12:11

Не прокатило что? Объект не обновился или нет объекта с таким id?
Проверка на ошибки именно такая

if($c->prepare() && $c->stmt->execute()){
    $result = ...
}

А есть ли такой объект можно проверить так

if ($modx->getCount('Objekt', $c) {
  // есть
}

Вопросы

Как сделать true и false при запросе UPDATE 6

Сергей Шлоков

06 октября 2015, 07:43

И что, сразу работает без сброса кэша?

Вопросы

Как создать запись лексикона с MODX API? 5

Сергей Шлоков

05 октября 2015, 16:51

Чанк грузится или из базы или из кэша. Когда он загрузится, идет проверка. Если чанк статичный, то сравнивается содержимое файла и чанка и если они не равны, то содержимое файла сохраняется в чанк в следующей строчке.

Готовые решения

Загружаем сниппеты и чанки с диска 32

Сергей Шлоков

05 октября 2015, 10:30

Провел небольшой тест на своем сайте (на локалке). Ресурсов меньше 100. Тренировался только на чанках. Время вызова сниппета pdoMenu в чанке [[$main_menu]] отличается на 0.02 сек. Поэтому я его учитывать не стал.
Вот шаблон страницы. Чанки простые, без фильтров и премудростей.

<!DOCTYPE html>
<html lang="ru">
<head>
    [[$head]]
</head>    
<body>
    // Шапка страницы
    [[$header]]
    // Меню. В нем вызывается pdoMenu
    [[$main_menu]]
    // Галерея
    [[$gallery]]
    // Содержание ресурса 
    [[*content]]
    // Подвал страницы
    [[$footer]]
    </div> 
</body>
</html>

Вызов в различных комбинациях. 5 раз для каждого метода. Показаны средние значения.

--------------------------------------------------------------
ВЫЗОВ КЭШИРУЕМЫХ ЧАНКОВ
--------------------------------------------------------------
// Чанки MODX из базы
               Первый запуск            Второй (из кэша)
Время:             0.74           |          0.21
Запросы:            63            |          10
// Чанки с диска
               Первый запуск            Второй (из кэша)
Время:             0.66           |          0.21
Запросы:            58            |          10

--------------------------------------------------------------
ВЫЗОВ НЕКЭШИРУЕМЫХ ЧАНКОВ
--------------------------------------------------------------
// Чанки MODX из базы
               Первый запуск                Второй 
Время:             0.74           |          0.32
Запросы:            63            |          12
// Чанки с диска
               Первый запуск                Второй
Время:             0.66           |          0.27
Запросы:            58            |          12

--------------------------------------------------------------
ВЫЗОВ НЕКЭШИРУЕМЫХ СТАТИЧЕСКИХ ЧАНКОВ
--------------------------------------------------------------
// Статические чанки MODX
               Первый запуск                Второй 
Время:             0.77           |          0.32
Запросы:            65            |          12
// Чанки с диска
               Первый запуск                Второй 
Время:             0.66           |          0.27
Запросы:            58            |          12

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

П.С. Оставлю себе для разработки, чтобы не морочится со статическими элементами — каждому нужно прописывать пути в отличие от данного приема. Для простоты поменял логику парсера. Теперь он проверяет, есть ли такой чанк на диске, если есть — грузит, нет — берет из базы. Без всяких подчеркиваний.

Готовые решения

Загружаем сниппеты и чанки с диска 32

Сергей Шлоков

05 октября 2015, 09:36

Это у разработчиков MODX надо спрашивать.

Готовые решения

Загружаем сниппеты и чанки с диска 32

Сергей Шлоков

04 октября 2015, 14:06

Ну да, я видел. Только это опять все через базу.

Готовые решения

Загружаем сниппеты и чанки с диска 32

Сергей Шлоков

04 октября 2015, 14:05

Проблему деплоя это не решает, потому что вызовы сниппетов и чанков кто-то еще должен прописать в шаблонах или ресурсах — а их как делать статическими?

Я и не писал, что это решает проблему деплоя. Я писал

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

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

Пока я вижу только усложнение работы без явной выгоды. Указывать пути, отказываться от наборов параметеров, echo вместо return — зачем это всё?

Никакого усложнения нет. На самом деле и наборы можно прикрутить. Вместо echo сделать return дело 2 секунд (я считал print лучше, меня переубедили). А уж про пути, конечно, прикольно. Т.е. вот это просто

[[!любойсниппетсpdotools?
	&tpl=`@FILE имяфайла.tpl`
	&tplPath=`путь\к\директории\с\шаблонами`
]]

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

pdoTools позволяет загрузить чанки из файлов. Просто можно было бы сделать и загрузку сниппетов из файлов. В продолжении логики и развития функционала pdoTools.

Я это сделал не для поспорить. Мне было интересно поковыряться, экспертное мнение я услышал. Значит отложил в сторону. Пойду лучше с детьми погуляю, раз время свободное выдалось. :)

П.С. А за дефолтными параметрами сниппета MODX все равно в базу лезет. :)

Готовые решения

Загружаем сниппеты и чанки с диска 32

Сергей Шлоков

04 октября 2015, 13:39

Это MODX-девы (как вы выразились), для которых и сделан вывод через буфер. Не разработчики-авторы MODX, а те программеры, которые решили освоить MODX.
Ретурн так ретурн. В принципе, какая разница. Завтра забудем. :)

Готовые решения

Загружаем сниппеты и чанки с диска 32

Сергей Шлоков

04 октября 2015, 13:36

Вы не поняли. Без присвоения и возврата во внутренних вызовах, не будет возврата и во внешних.

У меня есть и присвоение и возврат. Вот код для принта

include $this->_scriptFilename;
if (ob_get_length()) {
	$this->_output = ob_get_contents();
}

Я не собираюсь упорствовать. Должен быть, пусть будет. Тем более, что это все равно оказалось никому не нужно :)

Готовые решения

Загружаем сниппеты и чанки с диска 32

Сергей Шлоков

04 октября 2015, 13:10

Для этого в modScript (расширяемый классом modSnippet) используется костыль ob_start()/ob_get_contents()/ob_end_clean(), и используется он как раз потому что многие именно MODX-разработчики вместо return пишут print/echo в своих сниппетах. Таким образом им просто облегчили жизнь.

Во-первых, не знал, что это костыль.
Во-вторых, они (MODX-разработчики) потому и пишут, что привыкли на php так делать. А тут надо знать про return, именно знать, ибо об это нигде не написано.

Готовые решения

Загружаем сниппеты и чанки с диска 32

Сергей Шлоков

04 октября 2015, 13:05

Чанки уже давным-давно можно вызывать из файлов через @FILE, так что о них смысла спорить нет.

Не видел такой возможности в парсере, а как надо вызывать?

<?php
return include $path_to_file;

Прикольно. Хорошее решение.

Готовые решения

Загружаем сниппеты и чанки с диска 32

Сергей Шлоков

04 октября 2015, 13:04

del

Готовые решения

Загружаем сниппеты и чанки с диска 32

Сергей Шлоков

04 октября 2015, 12:57

Я не большой профи в php. Просто мне кажется, что раз php файлы лежат отдельно, они не должны включать логику MODX. А пользователи yui, laravel тоже в инклюдах прописывают return?
Я не собираюсь отстаивать именно print. Тут как раз я хочу получить экспертное мнение как лучше.

Самое важное: $output= $snippet->process($params);

Это как раз и не самое важное. Присвоение идет внутри process(). Отличие лишь в том, что для return надо прописывать

$includeResult= include $this->_scriptFilename;

а для print нет

include $this->_scriptFilename;

Просто мне казалось, что для стороннего php программиста сниппет будет выглядеть привычнее с print. Он может написать любой сниппет для MODX менеджера, который сможет его подключить. Я так думаю. Я могу и ошибаться, ибо не профи в этом.

Готовые решения

Загружаем сниппеты и чанки с диска 32

Сергей Шлоков

04 октября 2015, 12:48

Со времен Evolution в любом сниппете можно сделать
include 'file.php';

В сниппете да, а в ресурсе, чанке, шаблоне? И без фильтров и других примочек MODX.

Есть статические элементы, есть Gitify, есть установочные пакеты

Статические элементы, как мы знаем от Евгения Борисова, на продакшене нужно отключать.
Gitify для меня как высшая математика. Для простых пользователей очень сложно. Установочные пакеты — мейби.

Короче, без серьёзного профита в удобстве или скорости это просто любопытный эксперимент, не более.

Мне кажется так удобнее и практичнее для разработки. Раз, создал файл. Два, в ресурсе его просто вызываешь как обычно. Все как и было, только файл не в базе, а на диске. Отредактировал, нажал F5 и все сразу обновилось. Используя статические элементы, например, нужно сначала кэш почистить.
По скорости, допустим, сниппеты кэшируются, а чанки нет. За ними нужно лезть в базу.

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

Согласен, но у меня нет больших и сложных компонентов. А мне кажется, на маленьких данных преимуществ не будет видно. Но попробую ради интереса.
П.С. Даже просто ради эксперимента, мне понравилось.

Готовые решения

Загружаем сниппеты и чанки с диска 32

Сергей Шлоков

04 октября 2015, 11:49

А нельзя всё привести к общему стандарту MODX? Ведь это лишняя проблема помнить о том, что там так, а тут не так.

Это проблема для людей, которые учили php через MODX. Как и я собственно, начал учить php разбираясь со снипетами. Но у php свои правила и стандарты.
В MODX перед вызовом сниппета зачитываются его параметры по умолчанию, к ним добавляются параметры вызова и все это передается в сам сниппет. А в данном случае, если сниппета в базе нет, то нет и параметров по умолчанию (хранящихся в поле properties таблицы modx_site_snippets). В данном случае их негде взять. Поэтому, их нужно определять самостоятельно. Но я не вижу в этом проблемы. Многие, в том числе и я, в своих сниппетах проверяют эти параметры. Вот пример. При таком подходе вообще переделывать ничего не нужно.
Тоже и по поводу return. Для php программиста привычнее и логичнее print. А для MODX-программиста — return. На самом деле ничего сложного поменять логику нет. Пара строчек кода. Вопрос именно в подходе — делать как в обычном php или как в MODX.

Если честно, мне это решение кажется каким-то костыльным, чтоли.

Мнения разные важны. В данном случае не соглашусь. Это совсем не костыли. Тут работа именно с чистым php по его же стандартам. Т.е. человеку, который знает php и решил разрабатывать на MODX не нужно знать тонкости и условности этого движка. Как привык так и пиши. Очень часто именно это является камнем в огород со стороны пользователей других движков.

Готовые решения

Загружаем сниппеты и чанки с диска 32

Сергей Шлоков

03 октября 2015, 11:04

Ок. Спасибо.

Новые дополнения и их версии

[Office] Версия 1.3.0-pl и расширение другими компонентами 14

Сергей Шлоков

03 октября 2015, 09:51

Ясно. Моя невнимательность подвела. Картинки слева — это админка, а справа — это фронт.
Еще вопрос, а скрипт ExtJs офис грузит?

Новые дополнения и их версии

[Office] Версия 1.3.0-pl и расширение другими компонентами 14

Сергей Шлоков

03 октября 2015, 08:51

Честно говоря, не могу понять связи картинок из админки и вызовом своего контроллера офисом. Видимо возраст сказывается. Василий разъясни специально для меня бестолкового. Офис загружает пользовательский контроллер во фронте (примеры с ключами и продажами), а картинки в админке показывают таблицу предметов как в предыдущей версии без офиса. Т.е. связь интерфейса в админке с офисом от меня ускользнула. А еще эта загадочная фраза ~~Собака друг человека~~

Вам вовсе не обязательно использовать Ext JS, это просто пример возможностей.

еще больше меня запутала.

Новые дополнения и их версии

[Office] Версия 1.3.0-pl и расширение другими компонентами 14

Сергей Шлоков

02 октября 2015, 08:48

-2

Понятно, что хозяин-барин. Но мне кажется это неправильно даже для бесплатного дополнения. А уж для платного вдвойне. Логичнее было бы выложить это отдельным решением для желающих, например, modxExtraOffice. Чтобы остальным 99% не пришлось выпиливать это из своих дополнений. Имхо, разумеется.

Новые дополнения и их версии

[Office] Версия 1.3.0-pl и расширение другими компонентами 14

Сергей Шлоков

02 октября 2015, 08:20

-1

А правильно так делать для платного компонента? В самом лучшем случае этим воспользуется 1% разработчиков.
П.С. Это я про Office.

Новые дополнения и их версии

[Office] Версия 1.3.0-pl и расширение другими компонентами 14