Утверждена программа встречи. Как обещал, у нас будут ребята с JetBrains с прямым включением из Мюнхена — Михаил Винк расскажет о PhpStorm, Сергей расскажет про псевдотестирования, а Александр поделится опытом интеграции NoSQL базы в MODX с помощью ElasticSearch. После докладов будут организованы дискуссионные столы на основные темы: start — для тех, кто только начинает знакомство с MODX; backside затрагивает вопросы настройки сервера и сторонних модулей; inside посвящён административной части сайта;
а об оптимизации клиентской части мы будем говорить во frontend.
Также от меня лично будет несколько интересных новостей и заявлений, обсуждение которых, если потребуется, будет перенесено на афтепати, которое состоится сразу по завершению митапа.
Напоминаю, что участие в митапе бесплатное, но требуется регистрация.
Скорее всего автор хотел скрывать ненужные поля в админке, а не фронте, потому что очевидно, что если какие-то поля не нужно отображать во фронте, их плейсхолдеры просто достаточно удалить из шаблона.
А в админке лишние поля можно скрывать с помощью плагина, который на пререндере страницы будет проверять соответствующий шаблон и выводить только нужные поля, а-ля кастомизация форм.
А как на счёт CaST? Это обёртка над Гитом для телепортации MODX, позволяющая выборочно «делать снимки» пользователей, чанков, отдельных ресурсов, системных настроек или всего сайта в целом. И также выборочно «разворачивать».
Собирался, но из-за загруженности пришлось отказаться. Но, может, ещё передумаю.
В Питере, кстати, запустили https://vk.com/spb_frontend. На открытии сезона было неожиданно много фронтендщиков (более 40).
Поддерживаю идеи и от себя добавлю:
Полностью согласен с прошлым утверждением«2 варианта товара — это 2 разных товара, со своими артикулами и остатками», поэтому сейчас использую связи (один-к-многим), когда master-товар является эталонным и содержит всю информацию, которая не зависит от параметров (описание, тех. характеристики товара, производитель и т. д.), а у slave — прописываю ключ, который хочу менять (цвет, например), его значение (красный, синий или жёлтый), соответственно, и стоимость. Если появится товар, у которого два параметра будут влиять на стоимость, то это уже матрица:
P. S. Я считаю, что добавлять такие товары проще через специальный интерфейс, создание которого, за незнанием ExtJS, вижу только во фронтенде через процессоры.
P. P. S. Василий, идея краундфайдинга для miniShop2+ могла бы повлиять на его скорейшую реализацию?
идея с json теряет смысл, если нужно вывести товары, которые есть только в определённой точке. А такая необходимость тоже может понадобиться.
Так что отдельная табличка…
value (количество товара) == unlim может означать, что количество товара неограничено и вести его учёт нет необходимости. Значение может быть и отрицательным, тогда добавляется логика, что, товар, в принципе, по факту отсутствует, но заказать его можно.
start — для тех, кто только начинает знакомство с MODX;
backside затрагивает вопросы настройки сервера и сторонних модулей;
inside посвящён административной части сайта;
а об оптимизации клиентской части мы будем говорить во frontend.
Также от меня лично будет несколько интересных новостей и заявлений, обсуждение которых, если потребуется, будет перенесено на афтепати, которое состоится сразу по завершению митапа.
Напоминаю, что участие в митапе бесплатное, но требуется регистрация.
А в админке лишние поля можно скрывать с помощью плагина, который на пререндере страницы будет проверять соответствующий шаблон и выводить только нужные поля, а-ля кастомизация форм.
2) rtfm.modx.com/xpdo/2.x/class-reference/xpdo/xpdo.query
В Питере, кстати, запустили https://vk.com/spb_frontend. На открытии сезона было неожиданно много фронтендщиков (более 40).
Полностью согласен с прошлым утверждением«2 варианта товара — это 2 разных товара, со своими артикулами и остатками», поэтому сейчас использую связи (один-к-многим), когда master-товар является эталонным и содержит всю информацию, которая не зависит от параметров (описание, тех. характеристики товара, производитель и т. д.), а у slave — прописываю ключ, который хочу менять (цвет, например), его значение (красный, синий или жёлтый), соответственно, и стоимость. Если появится товар, у которого два параметра будут влиять на стоимость, то это уже матрица:
P. S. Я считаю, что добавлять такие товары проще через специальный интерфейс, создание которого, за незнанием ExtJS, вижу только во фронтенде через процессоры.
P. P. S. Василий, идея краундфайдинга для miniShop2+ могла бы повлиять на его скорейшую реализацию?
Так что отдельная табличка…
value (количество товара) == unlim может означать, что количество товара неограничено и вести его учёт нет необходимости. Значение может быть и отрицательным, тогда добавляется логика, что, товар, в принципе, по факту отсутствует, но заказать его можно.
github.com/bezumkin/mSearch2/blob/06ea4777750bff24d47bab479f1754be015b66df/assets/components/msearch2/action.php#L234