Здравствуйте.
Тема очень интересна. Сейчас рассматриваю возможность использования процессоров для создания контента из front-end'a сайта (ну не хочу я пускать всех в mgr, да и конечному пользователю будет удобно из front-end'a работать). Конкретно пытаюсь сделать добавление статей в блог. Может я конечно изобретаю велосипед, и все уже написано за меня? Не поможете советом по этому вопросу?
Дак вы используете MIGX или все-таки MIGXdb?
MIGXdb данные хранит не в JSON, а в таблице, которую вы сами же и определяете. А доступ к ней можно сделать через xPDO $modx->getObject, $modx->getCollection итд
pdo_sqlite драйвер подключил, но без изменений. Что самое интересное, все остальное работает без проблем за исключением компонента miniShop. Ругается, что не видит таблиц, но они же есть!
Вы смотрите пример как в таблице отображать ресурсы с TV. Вам это надо?
Поэтому и работает myClass->setTVValue(«prise»,$prise), т.к. myClass скорей всего является наследником modResource, а значение хранится в TV.
Или все же вам надо у каждого ресурса сделать список значений в виде таблицы и хранить это все в базе?
Мануал или код все-таки? Мануал MIGX, конечно, довольно скромный, но это больше касается MGIX-db, а с самим MIGX там особо нечего разбираться. Я мигиксы в каждом проекте использую. Пару-тройку раз migx-db, остальные — «обычный».
Ну можно и это. Я ж не в курсе, что конкретно Вам надо. Можете, просто, скажем, сделать TV с полями, где одно это цвет товара, а другое количество товара этого цвета. При продаже товара с этим цветом — меняете количество. Когда количество равно нулю, при генерации listbox-а просто игнорируете создание option этого цвета.
просто к сожалению мануал по MIGX весьма скудный, и автор не описывает что для чего((
… ткните сюда ткните туда, вуаля вы получили счастье и код вообще без комментариев практически…
Дело то в том что вроде бы у бруно в MIGXdb заложен этот функционал, просто не описан насколько я понял сам класс migx наследует методы modx, а в конфигурации есть поле classname где указывается имя объекта, при этом в мануале есть такие строчки…
______________________________________________________________
Register the TVs for our processors (getlist,fields)
We need to register TVs to include them in the getlist- and fields-processors.
Todo so we need a new config-file under /core/components/migx/configs/
with the same name as our MIGX-configuration: childstutorial.config.inc.php (should allready be installed with the MIGX-package)
and this content:
Вы ошибаетесь на счет MIGX. MIGX не связывает TV, а как исключительно верно указал Евгений Дурягин, использует их для указания на то, как их рендерить в форме ресурса. Значение же самого TV типа MIGX — это JSON-строка. Я бы не стал заморачиваться на MIGXdb для создания TV для товара, для этого подойдет «обычный» TV типа migx. Изменять цену можно с помощью msGetPrice. Пишете там функцию, которая распарсивает значение вашего TV типа MIGX и изменяет цену согласно этому значению. Как-то так.
В MIGXdb вы же сами таблицу описываете и определяете какие в ней поля должны быть.
Вот и обращайтесь к этой таблице как и к любой другой, через xPDO.
А TV используется только для отрисовки значение поля.
Василий, могу ли я вас попросить об одолжении, когда будет возможность, проверить работу 2-х сайтов у которых префиксы для mgr и web указаны и обновляются ли настройки, к примеру, Статус сайта (да/нет) и Название сайта, без удаления папки /core/cache?
Всего 125 661 комментарий
Тема очень интересна. Сейчас рассматриваю возможность использования процессоров для создания контента из front-end'a сайта (ну не хочу я пускать всех в mgr, да и конечному пользователю будет удобно из front-end'a работать). Конкретно пытаюсь сделать добавление статей в блог. Может я конечно изобретаю велосипед, и все уже написано за меня? Не поможете советом по этому вопросу?
MIGXdb данные хранит не в JSON, а в таблице, которую вы сами же и определяете. А доступ к ней можно сделать через xPDO $modx->getObject, $modx->getCollection итд
PDO, with database driver(minimal requirements)
pdo_sqlite драйвер мб?
Я понимаю, что это все хранится в базе в виде JSON массива и мне просто нужно переформировав его перезаписывать… это самый очевидный вариант.
Но если для этого уже в пакете предусмотрен инструмент почему бы не воспользоватся им… ))
У меня просто руки не доходят потеснить это дело я вот и спросил МБ кто уже плавал знает
Поэтому и работает myClass->setTVValue(«prise»,$prise), т.к. myClass скорей всего является наследником modResource, а значение хранится в TV.
Или все же вам надо у каждого ресурса сделать список значений в виде таблицы и хранить это все в базе?
… ткните сюда ткните туда, вуаля вы получили счастье и код вообще без комментариев практически…
С кодом Василия несравнить
______________________________________________________________
Register the TVs for our processors (getlist,fields)
We need to register TVs to include them in the getlist- and fields-processors.
Todo so we need a new config-file under /core/components/migx/configs/
with the same name as our MIGX-configuration: childstutorial.config.inc.php (should allready be installed with the MIGX-package)
and this content:
/core/components/migx/configs/childstutorial.config.inc.php
1
2
3
<?php
$this->customconfigs['includeTVs'] = 1;
$this->customconfigs['includeTVList'] = 'price,images,categories';
___________________________________________________________________
Насколько я понял после этого к переменным
можно обращаться как то так myClass->setTVValue(«prise»,$prise);
просто если это так то зачем делать велосипед… тем более не факт, что он выйдет лучше ))
Вот и обращайтесь к этой таблице как и к любой другой, через xPDO.
А TV используется только для отрисовки значение поля.
Хотя, насколько я помню, это должно учитываться и без чистки.
Префикс пишу в системные настройки, не в контекст.
Когда заморочки с кэшем — удаляю /core/cache
Дальше разбираться пока времени нет.
А у другого сайта другие префиксы для mgr и web, но между собой одинаковые.»
Именно так и пытался сделать, сначала создается впечатление что все работает, но потом:
«Иначе, все данные будут кэшироваться без уникального префикса, и на одном сайте вылезет кэш от другого. Будет не круто, уверяю.»
Возможно это только у меня так, поэтому спросил у кого есть возможность проверить у себя на сайте, чтобы внести хоть какую-то ясность в это для всех.