Алексей Карташов

Компоненты? Ну каждый их реализовывал как хотел

Дак в этом и была большая проблема, в том числе.

Шаблонизация? Но это было еще в Mustache и есть даже в ExtJS Modx.

Вы явно не понимаете о чём говорите) Действительно, зачем этот vue вообще нужен, когда есть лодашевый _.template()? Всего одна маленькая функция для шаблонизации! Не ну а чо, берём её, придумываем свою реализацию компонентов и вперёд пилить интерфейсы)

Vuex — как единое место хранения данных? Это всё тот же Storage из ExtJS, но чуток переработанный.

Чуток?) Я вам по секрету покажу:

window.Store = {};

вот и всё, что нужно для глобального хранилища данных. И чего они там в своих MobX'ах и Vuex'ах всё усложняют?)

склейка JS

Нынче важна не склейка js в один большой мегафайл, а наоборот — модульность и асинхронная загрузка только того, что действительно необходимо в данный момент времени на данной странице (code splitting и вот это всё).

Многое: склейка спрайтов, склейка JS, переменные в CSS и т.п. не нужно нынче, т.к. стало частью стандарта или неактуально с приходом http2

И действительно, чего это все до сих пор парятся с svg-спрайтами — подключали бы на страницу по одному, делов-то. HTTP2 придё и порядок наведё! Что за идеализация http2?

C Babel — больше вреда чем пользы: дополнительное звено в разработке и увеличивает бандл полифилами и страдает время сборки.

> страдает время сборки
SSD реально решает эту проблему. Но в современном фронтенде самую жирную часть времени сборки отнимает SCSS (который, внезапно, пришёл из руби-мира). Тут могу только посоветовать на стилус переходить.

> больше вреда чем пользы: дополнительное звено в разработке

Вы это дополнительное звено никак не почувствуете. А вообще, js — это дополнительно звено в разработке между пикселями на экране и машинным кодом, php — это дополнительное звено в разработке между http-запросом и тем же самым машинным кодом на сервере. Продолжать, думаю не стоит)

И касательно babel'я. Babel же в сути своей — прекрасен! Вы только вдумайтесь — это тулза, написанная на javascript, которая делает javascript из javascript! Это же просто волшебно)

> увеличивает бандл полифилами

Дак ему за это просто нижайший поклон! Вы действительно не видите преимущества в том, чтобы один раз написать код, который будет работать максимально везде?

А что даёт? Возможность использовать самые-самые последние, «синтаксически сахарные» в большинстве своём, конструкции языка? А раньше то как жили?

Вы действительно не видите преимущества в том, чтобы писать максимально читаемый и понятный другим разработчикам код, который будет работать везде?

> А раньше то как жили?

Раньше мы писали килотонны лапши:

function () {
    var argsArr = Array.prototype.slice.call(arguments);
    // do something
}

Тяжёлое наследие, что поделать. Зато сейчас просто и понятно:

(...args) => { /* do something */ }

Это ведь не просто сахарок — это банально ускоряет разработку, повышает читаемость, сокращает количество набираемого кода. Нахрена писать Object.assign({}, obj), если можно написать { ...obj }? Но при этом object-rest-spread ещё только в черновиках стандарта и не имеет поддержки даже в последнем v8, а я уже без него жить не могу, потому что пишу так 5-6 дней в неделю на протяжении последних 2-3 лет.

банально не использовали, пока поддержка этих конструкций в браузерах не достигала 90%.

И мне не пришлось ждать 3-4-5-6 лет, пока эта фича появится в 90% браузеров и платформ. Это же круто, чёрт побери!
Я даже на последней ноде, когда делаю бэкенд, юзаю babel. Просто именно поэтому.

И как заметил Роман выше — речь не про новые плагины галереек. Типа, ну накуя оно всё это нужно, если раньше галерейки работали без вот этого вот всего?!

Просто то количество бизнес-логики, которое сейчас приходится писать во фронтенде — несоизмеримо в разы больше, чем раньше. Вот просто в разы. И если бы сейчас не было Vue — я бы повесился писать всё это на jQuery/Backbone/Ember'е/ExtJS'е. Конечно и раньше были большие и сложные проекты — я ж не отрицаю. Но 6-7 лет назад для этого требовался штат из десятков JS-разработчиков (просто потому что кода надо было писать в десятки раз больше). То сейчас командой в 3-5 человек можно поднимать сопоставимые по уровню проекты за приемлемое время и деньги. Более того, в такую команду гораздо легче добавить новых разработчиков — они быстрее въезжают, ведь гораздо меньше кода для изучения и в нём используются уже общепринятые концепции, а не выдумывались какие-то свои.

Ну и по всем пунктам присоединяюсь к комментарию Романа выше.

для теста пропишите в сниппете перед этой строкой вот это:

var_dump($data);

ну, по логике, должен) но я вложенные inline-чанки не тестировал, может там как-то и по другому надо

В чанке второй раз запускать этот снипет и им через data выводить?

Ну да, почему нет?

все символы json строки вложенного MIGx переводятся в нижний регистр

ненене! ничего никуда принудительно не переводится.

вы имеете в виду то что

Я имею в виду, что этому сниппету можно скормить:
— обычный массив,
— json-строку,
— название migx'ового tv, в значении которого тоже лежит обычный json.

И данные можно:
— отрендерить,
— вернуть как есть в виде обычного массива, чтобы потом делать с ними другие непотребства.

Т.е. для примера:
этот снипет у вас называется data.renderer, а у документа с id равным 123 в значении migx'овой tv с названием tv.migx лежит вот такой json:

[{
  "migx_id": "1",
  "key1": "value1",
  "innerJson": [{
    "migx_id": "1",
    "key2": "зАбОрЧиК"
  }, {
    "migx_id": "2",
    "key2": "ЗаБоРчИк"
  }]
}, {
  "migx_id": "2",
  "key1": "value2",
  "innerJson": [{
    "migx_id": "1",
    "key2": "AbCdEf"
  }, {
    "migx_id": "2",
    "key2": "aBcDeF"
  }]
}]

Тогда вот такой вызов сниппета:

<ul>
{'data.renderer' | snippet : [
  'id' => '123',
  'migxtv' => 'tv.migx',
  'chunk' => '@INLINE
  <li>
    <p>{$_idx}. <span>{$key1}</span></p>
    <ul>
{'data.renderer' | snippet : [
  'data' => $innerJson,
  'chunk' => '@INLINE <li><span>{$migx_id}</span> <span>{$key2}</span></li>'
]}
    </ul>
  </li>
  ']}
<ul>

возможно ещё в вызове вложенного сниппета надо кавычки поэкранировать

Вернёт вот такой результат:

<ul>
  <li>
    <p>1. <span>value1</span></p>
    <ul>
      <li><span>1</span> <span>зАбОрЧиК</span></li>
      <li><span>2</span> <span>ЗаБоРчИк</span></li>
    </ul>
  </li>
  <li>
    <p>2. <span>value2</span></p>
    <ul>
      <li><span>1</span> <span>AbCdEf</span></li>
      <li><span>2</span> <span>aBcDeF</span></li>
    </ul>
  </li>
</ul>

В чанке доступны:
$_idx — порядковый номер
$_total — сколько строк всего
$_first — это понятно
$_last — это тоже
$_even — чётная строка
$_odd — нечётная строка

Ты что-то слишком перемудрил.
Вот, делает всё, что тебе надо, и даже больше:

<?php
/**
 * @type modX $modx
 * @type pdoTools $pdoTools
 * @type array $scriptProperties
 *
 * @type array $data
 * @type string $migxtv
 * @type int $id
 * @type string $chunk
 * @type int $returnData
 */

//$data - произвольный массив данных для рендера (может быть json-строкой). Если валиден, $migxtv игнорируется.
//$migxtv - если $data не указан или null, то можно задать имя MIGx-tv.
//$id - id документа, если не задано, то id текущего документа
//$chunk
//$returnData - вместо рендера просто вернуть массив данных (или NULL, если данные получить не удалось)

$data = $scriptProperties['data'];
$migxtv = $scriptProperties['migxtv'];
$id = $scriptProperties['id'];
$chunk = $scriptProperties['chunk'];
$returnData = intval($scriptProperties['returnData']);

if (is_string($data) && !empty(trim($data))) {
  $data = $modx->fromJSON($data);
}

if (!is_array($data) && !empty($migxtv)) {
  $resource = $modx->resource;
  if (!empty($id)) {
    $resource = $modx->getObject('modResource', $id);
  }

  $tvValue = $resource->getTVValue($migxtv);
  if ($tvValue) {
    $data = $modx->fromJSON($tvValue);
  }
}

if ($returnData) { return $data; }
if (!is_array($data)) { return ''; }

$pdoTools = $modx->getService('pdoTools');

$output = '';
$idx = 0;
$total = count($data);
foreach ($data as $key => $row) {
  $row['_idx'] = ++$idx;
  $row['_key'] = $key; // здесь может строка, а не индекс в массиве
  $row['_total'] = $total;

  $row['_first'] = false;
  $row['_last'] = false;
  $row['_even'] = false;
  $row['_odd'] = false;

  if ($idx === 1) {
    $row['_first'] = true;
  } else
  if ($idx === $total) {
    $row['_last'] = true;
  }
  if ($idx % 2 === 0) {
    $row['_even'] = true;
  } else {
    $row['_odd'] = true;
  }

  if (empty($chunk)) {
    $output .= '<pre>' . $pdoTools->getChunk('', $row) . '</pre>';
  } else {
    $output .= $pdoTools->getChunk($chunk, $row, false);
  }
}

return $pdoTools->fastProcess($output);

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

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

да что ж такое..

По поводу минусов — их я вам не ставил. Оставьте беспочвенные обвинения при себе.

вы не внимательно читали мои сообщения?

Очень внимательно

есть ли у вас примеры «вреда» от base href, … один из которых, просто ошибка абстрактного новичка с неверным указанием путей

и дальше:

Уберет ваш новичок базу, включит вложенные url, и сюда же с вопросом «почему не работает» прибежит
…
указал на имеющую место быть проблему при использовании разобранного в статье способа (хоть и редкую, но все же)

Добавить нечего. Кроме одного. Чисто для себя погуглите на данном сайте и всех остальных modx-сообществах по фразе "base href" и "убрал базу, включил вложенные url, почему не работает" и сравните количество вопросов.

Самое простое [[~[[*id]]]]#anchor

Вместо "#" вы везде предлагаете писать в 13 раз больше символов, нагружать парсер modx'а там, где этого можно было не делать и бороться с возможными конфликтами во вложенных чанках. Вместо единоразового редактирования шаблона и изменения одной настройки.

если страница будет ссылаться сама на себя (редкий случай на практике, но возможен), посмотрите что получится тогда. С base href ничего такого не случается.

Что такого страшного случится в этом случае, чего не случится с «base href»? Вы же понимаете, что без примеров описанная проблема — самая что ни на есть абстрактная? Или не понимаете?

Вы бы хоть привели примеры того, КАК НАДО писать, чтобы проблему обнаружить и как писать НЕ НАДО, чтобы этих проблем не было — было бы ГОРАЗДО больше пользы для (тех самых абстрактных) новичков.

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

Если вы хорошо разбираетесь в данном вопросе — напишите развёрнутый комментарий-пояснение или мини-статью, разложите в ней по полочкам для новичков варианты подходов с тегом base и без него, какие проблемы возникают и как их обходить. И, при случае, я всем буду скидывать ссылку на вашу статью. Даже добавлю ссылку на ваше развёрнутое уточнение в саму статью. Вот ЭТО будет действительно полезно и ценно.

А пока вы только бессмысленно воздух сотрясаете. Мне ничего доказывать не надо — я всё это и так знаю.
С вашей стороны, хотите — используете, хотите — нет. Можете написать пояснение, можете нет. Очевидно же, ну.
И ваши минусы со мной согласны.

.

Слушайте, я на полном серьёзе не понимаю зачем вы всё это пишете.

Если хотите использовать — используйте! В чём проблема?

что решаемо

Не подскажите каким образом? Чтобы нативненько.

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

Вы не внимательно прочитали. Но выше Андрей вам уже подсказал.

Не за что)

Приветствую!
Да, давно уж.
Сейчас там всё как надо работает, жалоб давно не было.

Тебя от бэкбона, случаем, воротить не начало?)

p.s. вьюхи бекбоновские взял (андерскоровский темплейт) или что-то другое прикручивал? сейчас просто не могу пока посмотреть)

Эх, намучался я в своё время с папкой core, которая лежала выше корня сайта и не была доступна из веб. Самое банальное — даже advanced установщик modx не может обновить систему, потому что тупо не видит этой папки, а задать ему путь можно только от "/" (т.е. от корня сайта), вроде бы.
Плюс невозможно окончательно и бесповоротно сбросить кеш, удалив папку core/cache, потому что из файлового менеджера она не видна и надо лезть на сервер по ssh.

Короче, вынося папку core за пределы сайта, будьте готовы к приключениям :)

500 тысяч — это совершенно не та цифра, при которой надо задумываться о парцитировании. Конечно, базы, таблицы и нагрузки бывают разные, но на таблице modx_site_content на таких объёмах этого точно не нужно.
Но если у вас огромная посещаемость с просадкой на примитивных запросах, то лучше сервер помощнее докупить — 100% поможет, а времени и нервов сэкономите просто уйму.

Здесь три варианта:
1. Использовать схему, как в miniShop2/Tickets/etc — написать плагин на событие OnHandleRequest, который будет отлавливать ajax-запросы, а дальше switch/case'ом рулить нужными экшенами. Гибко, но не системно.

2. Гуглите про коннеторы. Я их в своих компонентах никогда не использовал, но они именно для этого, по сути, и созданы (как минимум для админки точно. Для фронта может и не подойдёт). Принцип такой — на каждый restful чих пишется процессор, а на каждый процессор — по коннектору. ajax-запросы шлются на соответствующие файлы-коннекторы. Системно, но на каждый чих по файлу — это печаль.

3. Дождаться MODX 3, которая, вроде как, должна быть полностью restful :)

modx.pro/howto/5139-super-modx-strict-seo-accelerated-frontend/

Ну, главное, что заработало)

Хм, что-то я не получал уведомлений о ваших ответах. Вы решили проблему?

Дак тож — белорусские рубли, не российские