Евгений Дурягин

Евгений Дурягин

С нами с 15 декабря 2012; Место в рейтинге пользователей: #332
Евгений Дурягин
20 февраля 2013, 12:40
0
Дак вы все-таки скрипт хотите запускать на сервере по крону или из браузера?
Евгений Дурягин
19 февраля 2013, 11:54
0
И так и так умеет. Отчет «Сайты» учитывает домены, отчет «Метки» — метки.
Евгений Дурягин
19 февраля 2013, 11:26
0
А обязательно необходимо делать средствами MODX? Как вариант любая серьезная система статистики позволяет учитывать такие посещения, например Яндекс.Метрика help.yandex.ru/metrika/?id=1111475 В данном случае можно получить гораздо больше информации, чем просто количество посетителей.
Евгений Дурягин
17 февраля 2013, 14:29
0
Получить в хуке значения из формы можно через $hook->getValues(), отдельного поля $hook->getValue('name'). Примеры в документации. Для формирования html эти значения можно передать в $modx->getChunk
Евгений Дурягин
13 февраля 2013, 20:42
0
runSnippet не поддерживает наборы параметров. Хотя это не влияет на результат, он их просто игнорирует.
Евгений Дурягин
13 февраля 2013, 20:42
0
getPage сам по умолчанию отслеживает $_GET['page'] и никаких дополнительных действий не нужно.
Вызов вашего сниппета некэшируемый?
Евгений Дурягин
12 февраля 2013, 23:11
0
В качестве эксперимента выводил управление альбомом Gallery в редактирование документа community.modx-cms.ru/blog/tips_and_tricks/8733.html
Евгений Дурягин
06 февраля 2013, 13:26
0
Вы имеете ввиду, если в XML-схеме для объекта Calls прописать две связи:

<composite alias=«PrimaryContractor» class=«Contractors» local=«contractor»
foreign=«id» cardinality=«one» owner=«local» />
<composite alias=«Contractors» class=«Contractors» local=«id»
foreign=«call_id» cardinality=«many» owner=«local» />

то при $call->getOne('PrimaryContractor') будет возвращаться нужный объект?
Да, по крайней мере теоретически :)
Евгений Дурягин
06 февраля 2013, 12:40
0
Ну можно прописать связи как Contractor (или даже PrimaryContrator) и Contractors
$call->getOne('PrimaryContractor');
$call->getMany('Contractors');
А вы уверены что composite и aggrеgate правильно прописали? У контрагента может быть несколько обращений или в каждом обращении контрагенты уникальны?
В вашей схеме при удалениии обращения удаляются и все связанные контрагенты.
А при удалении контрагента его обращения не удаляются, что может привести к нарушению целостности данных.
Евгений Дурягин
24 ноября 2012, 12:44
0
Jason Coward уже делал такое расширение https://github.com/opengeek/engaged
Но было это во времена самых первых версий 2.0, на 2.2 может и не заработать из коробки и нужно править напильником.
Евгений Дурягин
29 октября 2012, 11:41
0
Дак вы используете MIGX или все-таки MIGXdb?
MIGXdb данные хранит не в JSON, а в таблице, которую вы сами же и определяете. А доступ к ней можно сделать через xPDO $modx->getObject, $modx->getCollection итд
Евгений Дурягин
28 октября 2012, 12:54
0
Вы смотрите пример как в таблице отображать ресурсы с TV. Вам это надо?
Поэтому и работает myClass->setTVValue(«prise»,$prise), т.к. myClass скорей всего является наследником modResource, а значение хранится в TV.

Или все же вам надо у каждого ресурса сделать список значений в виде таблицы и хранить это все в базе?
Евгений Дурягин
27 октября 2012, 13:56
0
В MIGXdb вы же сами таблицу описываете и определяете какие в ней поля должны быть.
Вот и обращайтесь к этой таблице как и к любой другой, через xPDO.
А TV используется только для отрисовки значение поля.
Евгений Дурягин
24 октября 2012, 12:54
0
abstract class AsupQueryBaseManagerController extends AsupQueryManagerController {

Должно быть extends modExtraManagerController, если у вас где-то еще AsupQueryManagerController не объявлен. Это первое, что бросилось в глаза.
Евгений Дурягин
16 октября 2012, 15:01
0
Лучше использовать xPDO::OPT_CACHE_PREFIX
Евгений Дурягин
16 октября 2012, 14:58
0
Только при беглом просмотре исходников PDO::OPT_CACHE_PATH должен равнятся абсолютному пути.
Евгений Дурягин
16 октября 2012, 10:18
0
Опечатка, должно быть xPDO::OPT_CACHE_HANDLER
Евгений Дурягин
16 октября 2012, 10:18
0
Ну можно еще и так:
$modx->cacheManager->set('key123', $str, 3600, array(
xPDO::OPT_CACHE_KEY => 'blablabla',
xPDO::OPE_CACHE_HANDLER => 'xPDOFileCache')
);
Сохранит в файлах

$modx->cacheManager->set('key123', $str, 3600, array(
xPDO::OPT_CACHE_KEY => 'blablabla',
xPDO::OPE_CACHE_HANDLER => 'cache.xPDOMemCache',
'blablabla_memcached_server' => 'localhost:11211'
)
);
Сохранит в memcached

Хотя это все насколько я помню, нужно все перепроверять.
Евгений Дурягин
16 октября 2012, 00:51
0
Кстати, помоему этого и достаточно
$modx->cacheManager->set($id, $collection, 86400, array(xPDO::OPT_CACHE_KEY => 'my_cache_dir'));

Если ты создашь настройку my_cache_dir_cache_handler=xPDOFileCache
То он будет кэшировать в файлах, остальное куда указывает cache_handler
Евгений Дурягин
16 октября 2012, 00:45
0
Свой класс не обязательно. В MODX система кэширования гораздо гибче. Там выбор класса для кэширования идет что-то типа по ключу, точно не помню, экспериментировал год назад наверное. Если ключ не задан, то используется класс по умолчанию. Например если указать resource_cache_handler = cache.xPDOMemCache, а cache_handler=cache.xPDOAPCCache, то он ресурсы будет кэшировать в memcached, а все остальное в APC. Можно в сниппетах использовать свои ключи и кэшировать куда нужно.

Вот статья для ознакомления modx.com/blog/2012/09/24/using-memcached-for-modx-caching/ Там, как видно, Jason Coward кэширует разные элементы в разные истансы memcached, точно также можно и разные классы прописать.