Это и в моей башке выглядит странным, когда человек переписывает весь js дополнения, которое ставится на чужие сайты, и тянет с собой лишние зависимости.
Если что, мне 37 лет — и я учу новое. И если уж у меня на это времени хватает, я хз какие у тебя отмазки могут быть, дорогой мой говнокодер.
Что мои дополнения требуют jQuery для работы и я регулярно отвечаю на вопросы по его подключению в поддержке.
В Vue, раз уж его все так любят упоминать, конфликты версий разруливаются на стадии установки менеджером пакетов. Я вообще слабо себе представляю дополнения, использующие Vue, слишком уж это сложно выходит для установки и кастомизации.
Речь тут о том, что раз переписывается JS дополнения, зачем тащить ненужную зависимость? Никто не предлагает переписывать сразу всё и всем, но раз уж делаешь заново — нафига нужен jQuery?
Как минимум потому, что это лишняя зависимость для твоего дополнения, которой может и не быть на сайте, и тогда придётся её подключать только ради тебя.
Или еще лучше — на сайте будет jQuery, но не той версии, которая нужна. Или с подключенными конфликтующими плагинами.
Когда я соберусь переписывать JS в моих допах, там точно не будет jQuery.
Вдруг я префикс базы захочу изменить, а в куче запросов он будет указан.
Ну ты же любишь использовать плейсхолдеры в запросах, вот тебе еще один: {'table_prefix' | option}
А если серьёзно, то ты пишешь очень сложный запрос, который не понадобится 99% пользователей pdoTools, а может и вообще MODX.
Он не станет менее сложным, если засунуть его в массив Fenom, никто ничего от этого не выиграет.
Усилия по добавлению этого функционала не просто ничего не стоят, они отрицательные не длинной дистанции, потому что нужно будет отвечать на вопросы по конвертации этих твоих вложенных массивов в SQL.
Периодически будут находиться люди, пытающиеся наворотить какую-нибудь фигню с этими параметрами. Как сейчас это делают с долбаным tvFilters.
Рейтинг этой заметки на данный момент составляет 0 при 34 комментариях, что уже намекает на её полезность.
Я этот PR гарантированно не приму, удачи в развитии своих дополнений.
Александр не знает, что xPDO и следовательно, pdoTools, прекрасно понимают сырые запросы, если засунуть их в строку внутри массива.
И тогда вполне возможно написать даже то, что он приводит в начале заметки:
{'!pdoResources' | snippet :[
'class' => 'tSkladDetNSLink',
'select' => ['*
FROM `modx_tsklad_detail_naryad_smena_link` AS `tSkladDetNSLink`
LEFT JOIN `modx_tsklad_order_list` `Detail` ON Detail.id=tSkladDetNSLink.det_id
LEFT JOIN `modx_tsklad_orders` `Order` ON Order.id=Detail.sk_order_id
LEFT JOIN `modx_tsklad_naryad` `Naryad` ON Naryad.id=tSkladDetNSLink.naryad_id
LEFT JOIN `modx_tsklad_smena` `Smena` ON Smena.id=tSkladDetNSLink.smena_id
LEFT JOIN `modx_nomenclature_detail_nom` `DetailNom` ON DetailNom.id=Detail.nom_id
LEFT JOIN `modx_nomenclature_detail_class` `DetailClass` ON DetailClass.id=DetailNom.class_id
LEFT JOIN `modx_nomenclature_type_job` `NomTypeJob` ON NomTypeJob.id=DetailClass.type_job_id
LEFT JOIN (
SELECT NextDNL.det_id AS next_det_id, NextDNL.naryad_id AS next_naryad_id, NextN.name AS next_naryad_name, NextDNL.smena_id AS next_smena_id, NextS.date AS next_smena_date, NextS.number AS next_smena_number
FROM `modx_tsklad_detail_naryad_smena_link` AS `NextDNL`
LEFT JOIN `modx_tsklad_smena` `NextS` ON NextS.id=NextDNL.smena_id
LEFT JOIN `modx_tsklad_naryad` `NextN` ON NextN.id=NextDNL.naryad_id
ORDER BY NextS.date ASC, NextS.number ASC) `NextDNL1`
ON tSkladDetNSLink.det_id = NextDNL1.next_det_id AND
(NextDNL1.next_smena_date > Smena.date OR (NextDNL1.next_smena_date = Smena.date AND NextDNL1.next_smena_number > Smena.number)
)
AND NextDNL1.next_smena_id = (
SELECT NextDNL.smena_id AS on_next_smena_id
FROM `modx_tsklad_detail_naryad_smena_link` AS `NextDNL`
LEFT JOIN `modx_tsklad_smena` `NextS` ON NextS.id=NextDNL.smena_id
LEFT JOIN `modx_tsklad_naryad` `NextN` ON NextN.id=NextDNL.naryad_id
WHERE NextS.date > Smena.date OR (NextS.date = Smena.date AND NextS.number > Smena.number)
ORDER BY NextS.date ASC, NextS.number ASC
LIMIT 1
)
LEFT JOIN `modx_plazma_list` `PlazmaList` ON PlazmaList.det_id=tSkladDetNSLink.det_id
'],
'where' => [
"(`Detail`.`sech` = 'pryam' AND `Detail`.`name` = 'зонт' AND `DetailNom`.`A` = '2000' AND `DetailNom`.`B` = '1500' AND `DetailNom`.`a_s` = '500' AND `DetailNom`.`b_s` = '500' AND `Detail`.`metall` = '0,7Ц' AND `Detail`.`L` = '0' AND `Detail`.`comment` = 'тип 1, ф355 заузить под наш отвод' AND `tSkladDetNSLink`.`smena_id` = 65 AND `tSkladDetNSLink`.`naryad_id` = 8 AND `NextDNL1`.`next_smena_id` = '66' AND `PlazmaList`.`file_true` = '0')"
],
'sortby' => 'Detail.sech DESC, Detail.name ASC, DetailNom.A DESC, DetailNom.B DESC, DetailNom.a_s DESC, DetailNom.b_s DESC, Detail.metall DESC, Detail.L DESC, Detail.comment',
'sortdir' => 'DESC'
'limit' => 0,
'showLog' => 1,
]}
Запрос, вполне себе, подготавливается
У меня он не может быть выполнен просто потому, что таких таблиц в системе нет.
Но можно сравнить исходные параметры и конечный код — они идентичны, за исключением FROM из несуществующей таблицы (что при наличии модели tSkladDetNSLink будет заменено на FROM `modx_tsklad_detail_naryad_smena_link` AS `tSkladDetNSLink`) и экранирования сортировки (которой xPDO закрывает старую уязвимость).
Так что, кому уж прям очень нужны подзапросы в pdoTools — они уже там есть, с самого начала.
Что-то я совсем не понял с честь чего у вас такой вопрос?? «построение запроса через xPDO приводит к ошибке работы Fenom» — вроде нигде такого не говорил.
У тебя с памятью беда, или с логикой?
Вот это вот — оно про что?
Почему у тебя какие-то ошибки в парсинге именно после выполнения запроса? Какие ты там display и font меняешь, зачем? Какое оно имеет отношение к запросам или подзапросам в БД?
Или ты (я только сейчас об этом подумал) проверяешь свой новый придуманный синтаксис на pdoFetch с твоими изменениями, и без них? И приводишь как доказательство, что твой синтаксис без твоих изменений в pdoFetch не работает?
Если это и правда так, то я вообще уже не знаю, куда в скорую звонить, в какой регион.
Саша, ты несёшь такую пургу, что я просто теряюсь.
Скажи пожалуйста, каким образом у тебя построение запроса через xPDO приводит к ошибке работы Fenom? Это откуда должны расти руки, чтобы так получалось? Ты понимаешь, что Fenom в pdoTools был добавлен лишь в версии 2.0, и как-то до этого запросы прекрасно строились без него?
Пока ты не ответишь на этот вопрос, я не вижу смысла продолжать общение.
А авторы Tikkets вообще собираются редактор сообщений обновлять?
Нет, не собираются.
Авторам Tickets (обрати внимание на правильное написание) есть много чем другим заняться. Судя по твоему энтузиазму, ты легко запилишь прекрасный форк, на который все пользователи Tickets легко перейдут без потери данных.
И будешь его потом поддерживать бесплатно, годами.
С феном то все понятно, его закончу, но вот мысли у меня сделать отдельно такой плагин и для modx, который бы работал бонусом со всеми выше перечисленными объектами (шаблоны, чанки) напрямую с бд.
Нафига оно надо, если будет нормальная навигация по Fenom тегам?
Мне лично только её не хватает при работе из IDE, синтаксис MODX уже давно не использую.
Еще раз — Collections работает с ресурсами. Соответственно, все сниппеты MODX работают с ним.
Если ты перетаскиваешь весь контент в другие таблицы, то какой-нибудь GoogleSiteMap для них карту сайта не построит, а mSearch2 их для поиска не проиндексирует.
Сегодня есть pdoTools, и с его помощью можно выводить данные из любых таблиц, для которых есть схема, но опять же, все его родные сниппеты заточены именно под ресурсы. Например, в pdoResources прописана сортировка именно по publishedon, которого может не быть в другой таблице. А pdoMenu использует карту ресурсов в modX::getParentIds для построения меню.
У меня и данные в своих таблицах
У меня тоже.
Но это у меня и тебя, в наших непубличных проектах.
А теперь представь себе условный miniShop3, который хранит миллионы товаров в своих собственных таблицах. К нему нужно будет поставить и полный набор всех сниппетов для вывода этих товаров, генерации меню, хлебных крошек и т.д.
Как оно, сильно больше Collections будет? Одну документацию писать замучаешься, а потом баги отлавливать и править.
Говорю же, я много об этом думал и пришёл к выводу, что делать подобное не стоит. Ну а если и делать, то как отдельную независимую либу, которую потом интегрировать с MODX.
Собственно, как Андрей Чирко уже сделал с Shopkeeper 4 — и что-то большого успеха на рынке MODX у такого решения не видать.
Где-то во фреймворках есть заранее созданные таблицы под контент? С контекстами, прикрученными картами ресурсов кэша, менеджерами с кастомизацией форм для их редактирования?
Нет, никто так не делает во фреймворках, там ты всё пишешь под себя.
Именно поэтому я и доказываю тебе, что в ресурсы в MODX — они именно что для контента. Это ограничивает систему, но делает её удобной для новичков и небольших сайтов.
Использование modResource в MODX — это единственно верный путь для хранения пользовательского контента в 99% использования системы. А если кому-то это не подходит, нужно поискать другую систему, таков мой вывод.
Если что, мне 37 лет — и я учу новое. И если уж у меня на это времени хватает, я хз какие у тебя отмазки могут быть, дорогой мой говнокодер.
Вопрос, кажется, вообще не тебе задавали. Непонятно, откуда такой энтузиазм в защите jQuery. Не хочется Javascript учить? Ну бывает.
В Vue, раз уж его все так любят упоминать, конфликты версий разруливаются на стадии установки менеджером пакетов. Я вообще слабо себе представляю дополнения, использующие Vue, слишком уж это сложно выходит для установки и кастомизации.
Речь тут о том, что раз переписывается JS дополнения, зачем тащить ненужную зависимость? Никто не предлагает переписывать сразу всё и всем, но раз уж делаешь заново — нафига нужен jQuery?
Ответа от автора по-прежнему нет.
Или еще лучше — на сайте будет jQuery, но не той версии, которая нужна. Или с подключенными конфликтующими плагинами.
Когда я соберусь переписывать JS в моих допах, там точно не будет jQuery.
А если серьёзно, то ты пишешь очень сложный запрос, который не понадобится 99% пользователей pdoTools, а может и вообще MODX.
Он не станет менее сложным, если засунуть его в массив Fenom, никто ничего от этого не выиграет.
Усилия по добавлению этого функционала не просто ничего не стоят, они отрицательные не длинной дистанции, потому что нужно будет отвечать на вопросы по конвертации этих твоих вложенных массивов в SQL.
Периодически будут находиться люди, пытающиеся наворотить какую-нибудь фигню с этими параметрами. Как сейчас это делают с долбаным tvFilters.
Рейтинг этой заметки на данный момент составляет 0 при 34 комментариях, что уже намекает на её полезность.
Я этот PR гарантированно не приму, удачи в развитии своих дополнений.
Я и так много времени на тебя потратил. Иди, просвещайся.
И тогда вполне возможно написать даже то, что он приводит в начале заметки:
Запрос, вполне себе, подготавливается
У меня он не может быть выполнен просто потому, что таких таблиц в системе нет.
Но можно сравнить исходные параметры и конечный код — они идентичны, за исключением FROM из несуществующей таблицы (что при наличии модели tSkladDetNSLink будет заменено на FROM `modx_tsklad_detail_naryad_smena_link` AS `tSkladDetNSLink`) и экранирования сортировки (которой xPDO закрывает старую уязвимость).
Так что, кому уж прям очень нужны подзапросы в pdoTools — они уже там есть, с самого начала.
Не надо.
Вот это вот — оно про что?
Почему у тебя какие-то ошибки в парсинге именно после выполнения запроса? Какие ты там display и font меняешь, зачем? Какое оно имеет отношение к запросам или подзапросам в БД?
Или ты (я только сейчас об этом подумал) проверяешь свой новый придуманный синтаксис на pdoFetch с твоими изменениями, и без них? И приводишь как доказательство, что твой синтаксис без твоих изменений в pdoFetch не работает?
Если это и правда так, то я вообще уже не знаю, куда в скорую звонить, в какой регион.
Пиши свои допы, развивай — Сергей верно говорит.
Внезапно, нет.
pdoTools появился в 2013 году и целых 7 лет эти подзапросы никого не волновали. И сейчас не волнуют, увы.
Скажи пожалуйста, каким образом у тебя построение запроса через xPDO приводит к ошибке работы Fenom? Это откуда должны расти руки, чтобы так получалось? Ты понимаешь, что Fenom в pdoTools был добавлен лишь в версии 2.0, и как-то до этого запросы прекрасно строились без него?
Пока ты не ответишь на этот вопрос, я не вижу смысла продолжать общение.
Авторам Tickets (обрати внимание на правильное написание) есть много чем другим заняться. Судя по твоему энтузиазму, ты легко запилишь прекрасный форк, на который все пользователи Tickets легко перейдут без потери данных.
И будешь его потом поддерживать бесплатно, годами.
Какая связь вообще между генерацией SQL запроса в БД и шаблонизатором?
Ты вот такое прям серьёзно пишешь, это не прикол?
Нет конечно, не примет. Ты меня за дурака держишь, или что?
Да хоть бы отформатировал в PSR-2 свою писанину, чтобы читать это возможно было.
Это ты еще и 2 новых версии pdoTools сразу выпустил? Ну вообще орёл.
Мне лично только её не хватает при работе из IDE, синтаксис MODX уже давно не использую.
P.S. Есть вот такой древний плагин для Fenom. Он очень сырой, но может чем-нибудь пригодиться.
В описании разделов указано.
Если ты перетаскиваешь весь контент в другие таблицы, то какой-нибудь GoogleSiteMap для них карту сайта не построит, а mSearch2 их для поиска не проиндексирует.
Сегодня есть pdoTools, и с его помощью можно выводить данные из любых таблиц, для которых есть схема, но опять же, все его родные сниппеты заточены именно под ресурсы. Например, в pdoResources прописана сортировка именно по publishedon, которого может не быть в другой таблице. А pdoMenu использует карту ресурсов в modX::getParentIds для построения меню.
У меня тоже.
Но это у меня и тебя, в наших непубличных проектах.
А теперь представь себе условный miniShop3, который хранит миллионы товаров в своих собственных таблицах. К нему нужно будет поставить и полный набор всех сниппетов для вывода этих товаров, генерации меню, хлебных крошек и т.д.
Как оно, сильно больше Collections будет? Одну документацию писать замучаешься, а потом баги отлавливать и править.
Говорю же, я много об этом думал и пришёл к выводу, что делать подобное не стоит. Ну а если и делать, то как отдельную независимую либу, которую потом интегрировать с MODX.
Собственно, как Андрей Чирко уже сделал с Shopkeeper 4 — и что-то большого успеха на рынке MODX у такого решения не видать.
Нет, никто так не делает во фреймворках, там ты всё пишешь под себя.
Именно поэтому я и доказываю тебе, что в ресурсы в MODX — они именно что для контента. Это ограничивает систему, но делает её удобной для новичков и небольших сайтов.
Использование modResource в MODX — это единственно верный путь для хранения пользовательского контента в 99% использования системы. А если кому-то это не подходит, нужно поискать другую систему, таков мой вывод.
Слишком большой объём работы и непонятный выхлоп. Экономически не выгодно.