Алексей Карташов

Алексей Карташов

С нами с 04 февраля 2013; Место в рейтинге пользователей: #49
Написать сообщение
20 августа 2013, 05:26
0
Возможно memcached, да. Но всё-равно — больно уж это странно.
/
19 августа 2013, 22:41
0
Хех, во дела…
В общем, у меня компонент был добавлен через addExtensionPackage() и из-за этого все мета-данные брались из кэша, только совершенно не понятно из какого — папка core/cache чистилась полностью.

В общем, сделал removeExtensionPackage() и теперь таблицы генерируются нормально
/
19 августа 2013, 21:33
0
Здесь какое дело…
При выполнении
$generator->parseSchema($xml, $Model);
на выходе в методе parseSchema генерируются правильные map-файлы.
Затем, при выполнении
$manager->createObjectContainer('myClassObject');
в этом методе есть вызов $xpdo->getFieldMeta(), а вот уже в нём набиваются мета-данные для создания таблицы. И вот там-то в массиве $this->map лежат старые мета-данные. Как они туда попадают — для меня ещё загадка.
В removeObjectContainer() ничего сверхъестественного нет, чтобы повлиять на такой исход событий. Сейчас порою addPackage(). Может там какая веселуха происходит.
/
19 августа 2013, 19:42
0
Но по логике, если б проблема была в схеме, то таблицы бы не создавались, а в логах были бы mysql-ошибки. Таковых не наблюдалось.
В сгенерированных map-файлах всё прописано согласно схемы, все поля, типы, индексы. А вот сами таблицы генерируются по старому.
Пути верные, сервер — простой шаред, в котором монтировать ничего нельзя, так что — нет, это тоже отпадает (к тому же до этого проблем не было).

Вот сейчас полностью снёс папку с кэшем, очистил папку модели компонента, убрал из xml-схемы всё — оставил описание одной таблицы и 2х полей и перегенерировал.
В итоге — сгенерировались xpdo-файлы этого класса, в map-ах только нужные 2 поля, в таблице — все старые 10 полей, плять. Со всеми индексами и типами.
Да откуда он вообще берёт эти старые данные? Мистики и волшебства в таких вопросах не бывает. Но вот в каком направлении копать?
/
19 августа 2013, 19:08
0
Блин, даже в логах пусто :-(
Вась, помоги, пожалуйста. Чёт совсем у меня вариантов нету.
/
19 августа 2013, 17:32
0
Сейчас в другую таблицу этой же модели добавил пару новых полей — так вот при перегенерации так же создалась старая таблица. Новых полей нет. В первой таблице названия полей так же без изменений. А в .map файлах всё прописывается правильно — всё как в xml-схеме. Чего-то я не знаю(
/
15 августа 2013, 08:46
0
Блин, эти три коммита как-то странно добавились, что там diff'ов просто немерянно набралось. И из-за этого многие ссылки в описании побились, которые вели на страницу сравнения.
/
15 августа 2013, 08:37
0
Твой пулл-реквест на очереди, скоро займусь.
Супер!

По событиям issue создал.

Там, кстати, в пуллреквесте странность. К нему почему-то прибилось 3 коммита, которые я отправлял в свой репозиторий уже после создания этого самого пуллреквеста. Не знаю почему так. По логике такого быть не должно, но в git'е я понимаю мало (пользуюсь гитхабовским гуёвым клиентом), возможно так и должно быть, хз.
В общем, последние три коммита Discount cards foundation, Discount types ready, DiscountCard grid там не нужны.
/
15 августа 2013, 04:11
0
По первому вопросу, в 
<head> ... </head>
в html-шаблоне, скорей всего, надо добавить:
<base href="[[~[[*id]]]]" />

По второму — слишком неоднозначная задача, которую можно решить многими разными способами (как и всё в modx'е). Здесь легко подойдёт migxdb, но не знаю — разберётесь ли вы с ним. В xpdo что-нибудь понимаете? Сниппеты свои писали?
/
15 августа 2013, 02:55
0
Нда, поспешил…
Вспомнил про крайнюю статью про плагины и новый метод miniShop2::invokeEvent(). Тогда вопрос про собственный класс и настройки снимается :-)
Но тогда как валидировать свои поля при выводе через сниппет, когда (и если) эта возможность появится. Ведь в методе msOrderHandler::validate() не вызывается никаких событий, а значит свои поля отвалидировать таким образом не получится…
/
14 августа 2013, 09:33
0
Это да, конечно)
/
14 августа 2013, 09:14
0
А чтобы из коробки это работало и настраивалось, по ходу надо какую-то настройку, в которой указывать id заказа, при смене на который надо делать эту проверку.
/
14 августа 2013, 09:11
0
Блин, точно!
Самый верняк — это на msOnChangeOrderStatus проверять, если только что оплаченный заказанный товар кончился, отменять другие заказы с этим товаром. Отлично, спасибо!
Но тогда надо уведомить как-то об этом покупателя. Можно заюзать поле «Комментарий», но, по логике, оно ведь предназначено для менеджеров, в письмах и чанках не отображается, да и комментарий этот никак со статусом не связан — он всегда останется таким, каким его написали, даже при смене статуса.
Но так-то пофиг, можно использовать и его.
/
04 августа 2013, 14:00
1
0
Усё, вопрос решён.
Переделал запрос на такой:
SELECT  `msDiscountCard`.`id`,
		`msDiscountCard`.`uid`,
		`msDiscountCard`.`public`,
		`msDiscountCard`.`discount_id`,
		`msDiscountCard`.`amount`,
		`msDiscountCard`.`amount_used`,
		`msDiscountCardMember`.`user_id`,
		`msDiscountCardMember`.`owner_type`,
		`msDiscountCardMember`.`discount_card_id`
	FROM `modx_bunny_lovems2_discount_card` AS `msDiscountCard`
	LEFT JOIN `modx_bunny_lovems2_discount_card_members` AS `msDiscountCardMember`
	ON `msDiscountCardMember`.`discount_card_id` = (
		SELECT  `msDiscountCardMember`.`discount_card_id`
			FROM `modx_bunny_lovems2_discount_card_members` AS `msDiscountCardMember`
			WHERE `msDiscountCardMember`.`owner_type` = 'owner'
				AND `msDiscountCard`.`id` = `msDiscountCardMember`.`discount_card_id`
			LIMIT 1
	)

И собрал его на xPDO вот так:
$subquery = $modx->newQuery('msDiscountCardMember');
$subquery->select('`msDiscountCardMember`.`discount_card_id`');
$subquery->where(array(
	'`msDiscountCardMember`.`owner_type`' => 'owner',
	'`msDiscountCard`.`id` = `msDiscountCardMember`.`discount_card_id`'
));
$subquery->limit(1);
$query = $modx->newQuery('msDiscountCard');
$query->select('`msDiscountCard`.*, `msDiscountCardMember`.`user_id`');
if ($subquery->prepare()) {
	$query->leftJoin('msDiscountCardMember', 'msDiscountCardMember', array(
		'`msDiscountCardMember`.`discount_card_id` = ('. $subquery->toSQL() .')'
	));
}
/
03 августа 2013, 18:15
0
Они могут помочь это выпустить отдельным дополнением
Ну это вариант, конечно. С самого начала я так и хотел, но вот установил modExtra и дальше не продвинулся. С твоими наработками куда проще было начать это делать, поэтому и начал «внедрять» в твой код.

на месяц вперед
Воу, аж на месяц счёт идёт… Ну хотя бы так, куда деваться)
/
03 августа 2013, 17:39
0
Они мне помогут разобраться с Ext'ом? ^_^

А ты примешь этот коммит, если что? :-) Задумка-то клёвая! Да и возможности гибкие будут)

p.s. как там, кстати, дела с no-js?)

/
03 августа 2013, 17:31
0
Не, тут надо с админкой. Будут огромные возможности.

Смысл какой — во настройках добавляется новая вкладка — «Типы скидок». Вот описание этой вкладки:
Укажите типы скидок для дисконтных карт. Например, «5%» или «2000».
Здесь же вы можете привязать скидку к конкретному товару. Например, у вас есть товар «Дисконтная карта на сумму 5%». Создайте тип скидки «5%» и свяжите её с этим товаром.
К этому товару автоматически привяжутся все дисконтные карты (созданные в панели управления) с этим типом скидки. И тогда, пользователь, купивший этот товар, автоматически становится владельцем первой свободной дисконтной карты с данным типом скидки.

И так же можно будет создавать дисконтные карты из админки. Можно назвать это промо-кодом, как угодно, суть не меняется. Эти карты могут быть общими для всех, именными, иметь совладельцев, иметь ограничение на количество использования.
Здесь, вы можете создавать дисконтные карты и связывать их с созданными раннее скидками.
Так же можно устанавливать лимит пользования (0 — неограниченно).
Дисконтные карты могут быть:
— общего пользования;
— именными, т.е. привязываются к определённому пользователю. Вы можете назначать владельца карты вручную, либо это будет происходить автоматически, если скидка, привязанная к этой карте, связана с товаром и пользователь приобретёт этот товар.

Именные карты могут:
— иметь совладельцев, т.е. пользователей, которые, помимо владельца, также могут воспользоваться данной картой;
— быть публичной, т.е. этой картой может воспользоваться любой. Разница с картой общего пользования только в том, что у этой карты есть конкретный владелец.
Пара скринов того, что готово:


Вот в первом скрине — осталось только в окошко создания/редактирования добавить superbox с возможностью выбора нескольких юзеров сразу.

И всё, что в описаниях выше — всё сделаю, но вот с ExtJS никак не совладаю :-( Он меня убивает просто. И ведь осталось-то с ним совсем немного — остальное дело техники — сниппет для упраления картами для фронта и обработки.

В админке MODX можно использовать и jQuery, ExtJS не обязателен.
Дак а как мне из jQuery юзать Ext-овские виджеты? А именно superbox.
/
01 августа 2013, 10:10
0
Это тебе спасибо за лестный отзыв! =)
/
01 августа 2013, 10:04
0
Контекст инициализируется не просто так
Так это понятно. Поэтому он и в плагине переинициализируется при необходимости.
А в скриптах всегда подставляется контекст.

Всё, что было в action.php — всё перенесено в плагин (ну за исключением подключения index.php). С такими вещами я больше всего боялся накосячить и поэтому отнесся к ним с бОльшим вниманием =)
/
01 августа 2013, 09:29
0
Нет, не замерял.
Но, технически, будет даже быстрее (пусть и не заметно для глаза) или разницы просто не будет. Ведь запросы обрабатываются не в сниппете, а в плагине на onHandleRequest.

Когда запросы шли через action.php, запускался index.php, в котором инициализируется modX, контекст и запускается $modx->handleRequest(). Код miniShop'а начинал свою работу после полной отработки modX::handleRequest(),

А когда всё работает через плагин, то код miniShop'а вступает в действие уже вот здесь, когда modX::handleRequest() запускает событие onHandleRequest, т.е. miniShop2 начинает обработку запроса раньше, чем это было через action.php :-)
/