Зачем стучаться в закрытую дверь? Просто сделай отдельный пакет. Кому надо поставит. Не нужно лезть в исходники!!!
Я, например, когда начинал свой путь в MODX и мне надо было добавить функционал в Tickets, сделал отдельный TicketMessages, расширяющий исходный компонент, в который добавил всё, что мне надо. Я не мучал автора своими пулами.
Были аналогичные мысли по феному. Но чтобы сделать вдумчиво, надо погружаться в Java. Я не нашел лишнего года.
А вот с базой ты погорячился. Напрямую работать можно только при условии, что сервер MySql доступен снаружи. Часто такое бывает?
Много раз уже это обсуждалось… Дефолтное значение TV хранится в таблице modx_site_tmplvars, а сами значения в modx_tmplvar_contentvalues. Где-то у Боба Рэя инструкция валялась по работе с TV с этим учётом.
Как написал Артём, нужно делать индекс по этим полям (order_id и field_id). И лучше первичный ключ. А наследовать от xPDOObject.
В этом случае:
1. mySql будет следить, чтобы не было дублей.
2. Значительно ускорится выборка таких записей.
Просто первое, что бросается в глаза — это недоделанная структура таблицы. Именно поэтому возможны одинаковые записи. А так как getObject() получает только один объект, то вероятно, что он получает не тот объект, который ты проверяешь. А метод save() говорит, что объект обновлен и возвращает true. Просто это другой объект. Это самый вероятный сценарий при такой структуре таблицы.
Сильно больше, чем вложено в Collections? На примере своих дополнений не вижу ничего особо сложного. У меня и данные в своих таблицах, и сниппеты с ними работают, и чанки и т.п.
Мда. Вера в MODX окончательно пошатнулась. Я был уверен, что хоть у одного разработчика родилась мысль сделать отдельную таблицу для ресурсов. И тут на тебе… Ни одного не оказалось. Ау, ребята, вот вам крутая идея!!!
Что бы там Джейсон себе не фантазировал, но как только разработчик доходит до мысли, что нужные ему данные проще хранить в своих таблицах, ему резко перестают быть нужны ТВ, шаблоны, чанки и сам MODX.
100%. Многие бывшие модиксеры из этого сообщества это подтвердят.
Разве? Так делал Articles. Лично у меня в голове отложилось, что разница у них в том, что Collections хранит контент в отдельной таблице. И Джейсон где-то в обсуждениях говорил, что юзайте Collections, а не пихайте всё в дерево ресурсов, которые являются эндпойнтами.
Не надо наводить тень на плетень. Возможность расширения базового функционала никак не является руководством к использованию ресурсов как к хранилищу контента сайта. Такая возможность есть, но она не является обязательной. И для опытного разработчика нет никакой надобности добавлять свой CRC. Только если, конечно, не поставлена именно такая задача — своё контекстное меню, процессоры и т.п в дереве ресурсов.
А вообще для меня выглядит странно — принять руководство по расширения базового класса инструкцией к использованию ресурсов как хранилище контента сайта.
пока я буду расширять класс modResource под каждую свою модель я на том же ларавеле за это время половину админки напишу
А зачем? Есть уже готовые пакеты. В крайнем случае, можно по аналогии сделать свой пакет из заготовки modExtra.
И на ларавел ты не напишешь быстрее аналог дерева ресурсов. А на твоё возражение, что ты и не будешь его писать, отвечу — и в MODX не надо всё пихать в дерево ресурсов.
П.С. Это конечно моё мнение и оно может отличаться от твоего. Это не значит, что оно правильное или нет. Просто нет одного правильного решения. Каждый пилит код как умеет.
Ничего подобного. Устанавливается каркас для работы с сайтом. Для визитки этого вполне хватит. А для сайтов типа блога умный разработчик ставит Collections или аналогичный пакет. И где-то в дебрях руководств Джейсон это объяснял.
Я, например, когда начинал свой путь в MODX и мне надо было добавить функционал в Tickets, сделал отдельный TicketMessages, расширяющий исходный компонент, в который добавил всё, что мне надо. Я не мучал автора своими пулами.
А вот с базой ты погорячился. Напрямую работать можно только при условии, что сервер MySql доступен снаружи. Часто такое бывает?
А вообще тема нужная.
В этом случае:
1. mySql будет следить, чтобы не было дублей.
2. Значительно ускорится выборка таких записей.
100%. Многие бывшие модиксеры из этого сообщества это подтвердят.
А вообще для меня выглядит странно — принять руководство по расширения базового класса инструкцией к использованию ресурсов как хранилище контента сайта.
А зачем? Есть уже готовые пакеты. В крайнем случае, можно по аналогии сделать свой пакет из заготовки modExtra.
И на ларавел ты не напишешь быстрее аналог дерева ресурсов. А на твоё возражение, что ты и не будешь его писать, отвечу — и в MODX не надо всё пихать в дерево ресурсов.
П.С. Это конечно моё мнение и оно может отличаться от твоего. Это не значит, что оно правильное или нет. Просто нет одного правильного решения. Каждый пилит код как умеет.