Александр Туниеков

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

В pdoTools вот код модификатора

$this->_modifiers['resource'] = function ($id, $field = null) use ($pdo, $modx, $fenom) {
            $pdo->debugParserModifier($id, 'resource');
            /** @var modResource $resource */
            if (empty($id)) {
                $resource = $modx->resource;
            } elseif (!is_numeric($id)) {
                $field = $id;
                $resource = $modx->resource;
            } elseif (!$resource = $pdo->getStore($id, 'resource')) {
                $resource = $modx->getObject('modResource', ['id' => intval($id)]);
                $pdo->setStore($id, $resource, 'resource');
            }

            $output = '';
            if (!empty($resource)) {
                if (!empty($field)) {
                    if (strtolower($field) == 'content') {
                        $output = $resource->getContent();
                    } else {
                        $output = $resource->get($field);
                        if (is_null($output)) {
                            $output = $resource->getTVValue(preg_replace('#^tv\.#i', '', $field));
                        }
                    }
                } else {
                    $output = $resource->toArray();
                }
            }
            $pdo->debugParserModifier($id, 'resource');

            return $output;
        };

Судя по $pdo->getStore ресурс где-то кешируется. Но как-то пробовал ускорить сайт 10 вызовов {resource_id | resource: 'tv_param_name'} сильно замедляют сайт.

Я ведь правильно понимаю — использование выше сниппета выше более рационально если надо дергать 5 — 6 полей другого ресурса?

Более рационально, если тип поля text. $resource->getTVValue($tv['name']); делает запросы в базу.

Поправил немного

<?php
$id = $input;
if (empty($id)) {
    $resource = $modx->resource;
} else {
    $resource = $modx->getObject('modResource', ['id' => intval($id)]);
}
if(!$resource) return [];

$out = $resource->toArray();
// чтоб страница не упала в рекурсию
unset($out['content']);

$id = $resource->id;
$sql = "
    SELECT IF(tvr.value != \"\", tvr.value, tv.default_text) AS tv_value, tv.name, tv.type
    FROM {$modx->getTableName('modTemplateVarResource')} tvr
    LEFT JOIN {$modx->getTableName('modTemplateVar')} tv
    ON tv.id = tvr.tmplvarid
    LEFT JOIN {$modx->getTableName('modTemplateVarTemplate')} tvt
    ON tvt.tmplvarid = tvr.tmplvarid 
    WHERE tvr.contentid = {$id} AND tvt.templateid = {$resource->template}
";
// $modx->log(1,$sql);
$q = $modx->prepare($sql);
$q->execute();
$tvs = $q->fetchAll(PDO::FETCH_ASSOC);

foreach($tvs as $tv){
    switch($tv['type']){
        case 'text': case 'textarea':
            $out[$tv['name']] = $tv['tv_value'];
        break;
        default:
            $out[$tv['name']] = $resource->getTVValue($tv['name']);
    }
}
return $out;

Я тут решил немного помочь и сделал сниппет
res

<?php
$id = $input;
if (empty($id)) {
    $resource = $modx->resource;
} else {
    $resource = $modx->getObject('modResource', ['id' => intval($id)]);
}
if(!$resource) return [];

$out = $resource->toArray();
$id = $resource->id;
$sql = "
    SELECT IF(tvr.value != \"\", tvr.value, tv.default_text) AS tv_value,tv.name
    FROM {$modx->getTableName('modTemplateVarResource')} tvr
    LEFT JOIN {$modx->getTableName('modTemplateVar')} tv
    ON tv.id = tvr.tmplvarid
    LEFT JOIN {$modx->getTableName('modTemplateVarTemplate')} tvt
    ON tvt.tmplvarid = tvr.tmplvarid 
    WHERE tvr.contentid = {$id} AND tvt.templateid = {$resource->template}
";
// $modx->log(1,$sql);
$q = $modx->prepare($sql);
$q->execute();
$tvs = $q->fetchAll(PDO::FETCH_ASSOC);

foreach($tvs as $tv){
    $out[$tv['name']] = $tv['tv_value'];
}
return $out;

Использовать

{set $res = 1 | res}
<pre>{$res | print_r}</pre>

Расчитанно, что все tv текстовые. Если надо чтоб tv обрабатывались перед помещением в массив, то надо вызывать getTVValue.

foreach($tvs as $tv){
    $out[$tv['name']] = $resource->getTVValue($tv['name']);
}

Клиент сегодня озадачил. Пришлось побороть проблему.
Создаем веб приложение и прописываем в google консоле uri
ваш_сайт/manager/?a=home&namespace=googlesheets

Блин. Насчет того, что точно не буду использовать vesp/core 4 кажется погорячился. Проблема в том, что ресурсов на собственный аналог не хватает :-(. Чтоб предложить более менее полноценное приложение надо потратить много времени… В принципе можно было бы перейти на vesp, но главная проблема отсутствие модульности. У нас сайт с, условно, сотней модулей. Пересоберать весь сайт при изменении одного модуля или добавлении нового желания нет.
У меня, при использовании gtsAPI, на странице вызывается сниппет, который подгружает однофайловый модуль на vue. Который весит пару килобайт. Соберается за секунды и никак не влияет на другие модули. Нужно, чтоб модуль можно было отдельно редактировать и соберать. Чтоб модуль отдельно подгружался при использовании на странице и чтоб при загрузке какой-либо страницы не загружались все сто модулей.
Пример модуля ExcelCalc

Нда… вот бы была такая система год назад… Сейчас уже активно пишу на более простом самописном аналоге с primeVue. Все проще и PSR-7 не поддерживает, но зато все мне понятно. Так что для меня врядли пригодиться. Хотелось бы современный и понятный стандарт, чтоб не плодить кучу разнообразных систем в которых ногу сломишь, но по моему новинки в программировании редко взлетают. С минишопом у Вас повезло. Ко времени пришелся. А vesp/core 4 может и не взлететь. Разве что на авторитете подымется. Думаю 3 проблемы помешают.
1 это не простой порог входа. Подробной документации еще нет, но система кажется не простой.
2. MODX с системой сниппетов и чанков довольно простой конструктор сайтов. Многие не знают php и пишут на MODX сайты. А с vesp/core уже так не получиться.
3. У vesp нет компонентов и модулей, чтоб не писать нужный функионал с 0, а как, например, установил минишоп и просто под свой сайт подстроил.

Ну это я так вижу :-). Может у кого-то другие впечатления…

Уже не помню :-(. может вот здесь проблема

$contents = explode(',',$contents);

BannerY видел 6 лет назат и напрочь забыл что там

pdoResources делает getChunk на каждую запись из базы. То есть на каждый ресурс вызывается обработка чанка.
Насколько я понимаю задачу, то либо вызывать pdoResources 2 раза, либо писать свой сниппет.
1) вызывать pdoResources 2 раза

<div class="col-lg-6">
	<div class="swiper>
		{* Start &TPL part-1 *}
                {'!pdoResources' | snippet : [
		      'tpl' = '<div class=" swiper-slide">{$name}</div>'
                ]}
		{* End &TPL part-1 *}
	</div>
</div>
<div class="col-lg-6">
	<div class="swiper-tabs">
		{* Start &TPL part-2 *}
                {'!pdoResources' | snippet : [
		      'tpl' = '<div class="swiper-tab">{$name2}</div>'
                ]}
		{* End &TPL part-2 *}
	</div>
</div>

Либо написать сниппет, например, getRes. Только для modx 2.x

$pdo = $modx->getService('pdoFetch');
$pdo->setConfig([
    'parents'=>'10',
    'return'=>'data',
    'limit'=>20
]);
$resources = $pdo->run();

return $pdo->getChunk('getResTPL',[
    'resources'=>$resources
]);

getResTPL

<div class="col-lg-6">
	<div class="swiper>
		{* Start &TPL part-1 *}
                {foreach $resources as $res}
                    <div class=" swiper-slide">{$res.name}</div>
                {/foreach}
		{* End &TPL part-1 *}
	</div>
</div>
<div class="col-lg-6">
	<div class="swiper-tabs">
		{* Start &TPL part-2 *}
                {foreach $resources as $res}
                    <div class="swiper-tab">{$res.name2}</div>
                {/foreach}
		{* End &TPL part-2 *}
	</div>
</div>

Хм… чет я притупил.

А php не весь на сервере выполняется? То есть по идее не важно откуда запущен должно же брать время сервера О_О

А вот что касается Vue внутри MODx, ну, апплодировать ногами тоже можно, но лишь ради развлечения других людей.

Грубовато :-)

Товары будут продаваться и без Vue.js

Чисто на товары Vue и не надо. Надо на динамичное приложение. Уже надоело как надо показать какую-то не стандартную модалку, то чанки на феном и он на фронте не работает. Приходиться идти по ajax на сервер выбирать отдельно данные закидывать их в чанк и html уже забирать. Много лишних телодвижений. Шаблоны лучше на фронте заливать данными. По большому счету я хорошо знаком только с модекс. Другие системы смотрел, но что-то не производят они впечатления. Пару api можно быстро создать, но чтоб чисто сделать апи для 200 таблиц понадобиться год. И еще год фронт написать. Тут на работе не будут ждать 2 года, чтоб у них все заработало. Новое можно только постепенно. Сейчас неделю ночи трачу обдумывая как на основе модекс бек сделать. По идее в часов 200 в течении 2-3 месяцев можно сделать такой функционал, что потом переезд будет в разы проше чем на каком-либо другом беке.

Ясно. Спасибо. Посмотрю потом

можно реплицировать бд и для этой бд сделать апи используя уже любой удобный яп, фреймворк и т.д

Реплиировать бд это синронизация бд или просто раз скопировать?
Если раз скопировать, то как функционал который еще не написан, а работать компании нужно? А написать год или 2.
Если синхронизировать, то это может гемор. Самописно я пробовал и точно гемор. А какой либо софт не знаю не смотрел еще. Если подскажете, будет интересно. И еще многие таблицы исторически созданны не оптимально. Хочется их переопределить, но сайт под эту структуру таблиц уже заточен. При синхронизации хотелось бы переопределить структуру таблиц :-(.

Ну на модекс написан за 8 лет большой функционал и на другой сервер его маленькими блоками не перекинешь.
И большими может тоже не перекинешь :-(. Вообщем есть таблица заказов и от нее зависит склад, производство, снабжение, логистика и т.д. Я счас пытаюсь маленькие блоки на vue перевести. Например распределение деталей из заказов по сменам производства. Или хотя бы написать распределение ресурсов(работников) по сменам.

Хороший вопрос :-). Сам думал. Но gtsAPI это только часов 6-12 остальное разборки с vue. Чтобы отдать чисто страницу с #app надо реализовать функионал который выдается pdoMenu и Login еще. Это еще часов 40 для реализации авторизации. Ну меню конечно роуты SPA дают не так сложно если по стандарту идти, но весь функционал за 8 лет написанный я в vue за неделю не напишу. И за года 2 не напишу наверно :-). То есть надо и меню модекс переключать и меню SPA. Что тоже сложно. Пока проще pdoMenu и Login от модекса и только подрубать часть функионала на vue на странице.

Хм. Я чет не подумал что у меня ситуация отличается. У меня 200 таблиц в базе и на фронте. Писать контроллер на каждую таблицу замучишься. А для большинства таблиц как раз только GRUD и требуется. Под это и заточено. Еще перенести функионал getTables на PrimeVue и треть работы сделана :-)

Спасибо за донат. Хотел в заметке спросить надо ли дальше и подробнее описывать :-) но уже запарился. Теперь буду знать. Надо расписывать. Только блоками работы поменьше, чтоб не запариваться и чтоб понятнее было. А стартовый блок работы получился большим. Я насчитал 60 часов работы О_О.

Да правильно. Сложновато написал. Хорошо еще что сейчас начал описывать. Потом вообще бы тяжко было все хитро сплетения прописывать.
В таблице указываешь точку монтирования — это куда слать запрос. Указываешь класс контроллера и путь к нему — то есть это где искать код код обработчика.
Но фишка то в том чтоб по возможности код обработчика вообще не писать. Класс контроллера остовляешь пустым и указываешь нужную таблицу и GRUD API уже есть. Думаю это съэкономит время.