Павел Гвоздь

Сергей, я считаю вполне обоснованным «недопонимание» со стороны Василия, мне бы тоже не понравился упрёк в мою сторону:

Но как же у автора pdoTools получились такие впечатляющие цифры? А всё просто. Тест проводился в API режиме. Т.е. в идеальных условиях для Fenom.

И выше Василий показал, что не в АПИ режиме дело.

В качестве вывода могу дать совет. Там, где не нужна логика, используйте синтаксис MODX. Если работаете с логикой, то не путайте синтаксисы — используйте только один.

И в конце статьи тогда стоило бы уточнить про предустановку pdoTools, а то создаётся впечатление, что pdoTools с его Fenom не даёт преимуществ на шаблонах без логики.

Зачем собирать отдельный пакет? Чтобы плодить кучу одинакового и создавать проблему выбора?
Твой PR скоро просмотрю, обязательно. Время только найду.

Нормально ты припахал) Как-нибудь потом…

А что там идеального то в нормальном коде? Лучше уж никак, чем писать такой низкокачественный код. Потом когда работаешь с такими сайтами, половина времени (не преувеличение) уходит, чтобы разобраться, что и как работает.

Приведённый Сергеем кусок кода отлично описывает уровень кодера. Это не то, что бессмысленно, это даже уже не смешно…

А у меня в пакете вообще всё управление происходит в админке. На фронте только вывод, юзер на фронте не сможет ничего редактировать. У вас же вся работа с картой объектов на фронте, верно? В этом, пожалуй, основное и главное отличие компонентов.

Я не против публикации компонента в Modstore, даже по той же цене, что сейчас у imgArea.

Я думаю такие вопросы должны решаться индивидуально. Но посмотрим, что ответят владельцы площадки.

Очень даже крутое нововведение! Поддерживаю.

Нет. А в чём разница-то?

В магазин не взяли.

Так может не взяли как раз, потому что он точь в точь, как аналог?

если в магазине не дают продавать

А не дают? Вроде, если компонент не повторяет точь в точь, а реализует что-то новое или большее, то берут в магазин? Или я ошибаюсь?

Здесь неравные условия изначально.

Ну и конкуренция между платным и бесплатным пакетом тоже априори на неравных условиях.

А где тут конкуренция, если один платный, а второй бесплатный?

Илья Уткин выпустил свой компонент reMessages. И я не успел на поезд

А это нормально в пику платному компоненту выпускать тот же функционал бесплатно? Я может чего не понимаю…

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

$q = $modx->newQuery('msProduct')
    ->leftJoin('modTemplateVar', 'price_opt_tv_name', 'price_opt_tv_name.name = "price_opt"')
    ->leftJoin('modTemplateVarResource', 'price_opt_table', 'price_opt_table.tmplvarid = price_opt_tv_name.id AND price_opt_table.contentid = msProduct.id')
    ->where([])
    ...

примерно так будет.

Компонент Битрикс CMS для приёма оплаты в TON Coin взаимодействует с мерчантом tegro.money/, а конечно же не напрямую с блокчейном TON. Поэтому здесь работа примерно также, как и с другими мерчантами, через API сервиса должна быть налажена.

Я задавал вопрос именно в контексте разницы скорости, а не удобства, ибо думается мне, что разница в скорости с твоим решением либо будет минимальна, либо вообще её не будет.

Прирост скорости по сравнению с $modx->getCollection() более чем в 10 раз

А почему сравнивается с getCollection, а не с newQuery?

Но ведь GraphQL это не БД, а язык запросов. В какую базу будут выполняться запросы, это уже решает бекенд api.

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

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

Только текущая страница.