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

А вот ещё непонятка одна…
Вот создал я тв-параметр, выставил ему требования, к примеру — «число», «минимальное значение» — 300, «разрешить десятичные» — да.

И вот почему-то я был уверен, что если сделать так:

$result = $resource->setTVValue('tvname', 'swff');

, то в $result будет ошибка. А оказывается нифига этот метод никаких таких проверок не делает и всё спокойно сохраняет, и в $result всегда приходит true. Поля проверяются на уровне javascript по ходу…

И вот это уже реально пичалька, ибо если проверки есть только на уровне скриптов, то всю валидацию надо писать самому :-(

Да просто через плагин не понятно как показывать ошибки в форме, поэтому решил через сниппет.

Спасибо большое!

Ага, понял, спасибо!
А вот ещё такой момент:
Через форму создания надо сохранять и твшки, но некоторые tv-шки обязательны.

Поэтому я пошёл таким путём: создал копию сниппета TicketForm (чтобы при обновлении не слетело), понаписал в ней вот это:

/* ... */
$requiredTvs = (!empty($scriptProperties['requiredTvs'])) ? explode(',', $scriptProperties['requiredTvs']) : array();
/* ... */
	case 'saveTicket': 
	case 'updateTicket': 
		$data = $_POST;
		$good = true;
		foreach($requiredTvs as $tv) {
			if (!$data[$tv]) {
				$data['error.'. $tv] = $modx->lexicon('field_required');
				$good = false;
			}
		}
		if ($good) {
			$output = $Tickets->saveTicket($data);
		} else {
			$output = $Tickets->getTicketForm($data);
		}
		break;
/* ... */

А в плагине на OnDocFormSave уже без проверок сохраняю тв-шки.

Так нормально? По феншую? Или есть более джедайский путь?

Да не за что :-)

Ну так у них и параметры также называются, через точечку

Ааа! Эвона как © Не знал, что так можно :-) Спасибо!

Оу, не знал… А почему во всех компонентах и сниппетах, какие не посмотри, везде используется, к примеру,

$modx->getOption('mycomponent.core_path');

? Да, конечно, делают проверки и подставляют значения по умолчанию, но неужели это просто задел на будущее?

Василий, спасибо огромное!
И ещё один вопрос можно? Сразу что-то забыл про него…

При установке своего компонента, создаю системную настройку. Настройка эта находится в правильном неймспейсе (в списке настроек меняю значение комбобокса с «core» на «mycomponent» и вижу её в списке). Но вот если я её получаю через:

$modx->getOption('mycomponent.mysetting');

, то получаю «NULL», а если через

$modx->getOption('mysetting');

, то правильное значение.
Но ведь это никуда не годится… Если у любого другого компонента будет настройка с таким же именем или, что ещё хуже, есть системная настройка с таким же именем?

Вот не хочет настройка получаться через указание неймспейса и всё тут. В чём проблема — не знаю. Может сталкивался?

сделай

die(var_dump($num));

и посмотри что у тебя в переменной $num лежит. Скорей всего в ней что-то такое, чего нельзя просто так на экран вывести. Ну или включи отображение ошибок — может твой скрипт просто тихо умирает на ошибках.

поздравляю, ты сказал тоже самое, что и я, только слов в 5 раз больше потратил

Без обид, но если ты не знаешь цену своей работы, то такой проект ты вряд ли осилишь…

Кстати, по 2му пункту — можно брать хэш от имени сниппета и строковых представлений имён параметров и их значений (предварительно отсортировав имена параметров по имени, например). Тогда да — мы будем однозначно идентифицировать каждый вызов каждого сниппета. Но ИМХО — это ещё одна совершенно лишняя нагрузка. Хотя идея рабочая.

> если только не прописывать работу с заголовками каждому используемому сниппету.
Именно. Но это такое не благодарное дело получится.
Но если уж заморачиваться, то логика должна быть примерно такой:
КАЖДЫЙ сниппет при КАЖДОМ своём выводе должен сверять ПРЕДЫДУЩУЮ выводимую им информацию с ТЕКУЩЕЙ выводимой им информацией. Т.е. надо завести отдельную таблицу и хранить там, к примеру, md5 от выводимых сниппетом данных и дату этих данных. И если md5 от текущих данных отличается от md5 из таблицы, то перезаписывать md5 и дату.
Потом на то же событие «OnLoadWebDocument» проверять количество сниппетов, в которых данные изменились с последнего вызова (эту переменную можно держать в сессии и каждый сниппет при необходимости инкрементирует её). И если это количество отлично от нуля, то отдавать 200. Иначе отдавать 304 (естесственно, не забыть проверять и дату последнего редактирования ресурса, как в текущем варианте).

НО:
1. Мы здесь теряем одно преимущество этого заголовка — снижение реальной нагрузки на сервер (это при достаточно годной посещаемости). Ведь фактически нагрузка увеличится! Это +1 запрос к вызову каждого сниппета и, если использовать md5, то ещё и на хэширование ресурсы тратить.
2. Как определить уникальность вызова сниппета и однозначно идентифицировать его в нашей специальной таблице?

В принципе, можно написать сниппет-обёртку (как getPage), который будет делать всю эту грязную работу. Ну и плагин доработать слегка.
Для поисковиков будет хорошо, да. Эту задачу этот сниппет+плагин будет решать.

Но со вторым «НО» из списка выше пока не понятно. Да и популярностью данное решение пользоваться не будет — оно сложно для понимания и оборачивать нужно КАЖДЫЙ вызов КАЖДОГО сниппета, что, естесственно, подавляющее большинство делать не будет.

Да и кому это вообще надо-то?))) Нафига я всё это писал? xDD

Пока искал ответ на ваш вопрос, натолкнулся на занятную статью, в которой есть отсылка на сервис для проверки правильности отдачи этих заголовков.
Так же, на этом сервисе есть 2 занятные статьи, после прочтения которых, вывод (относительно MODx) не такой уж и однозначный…

Дело в том, что у вас идёт проверка на последнее изменение КОНТЕНТА страницы, т.е. последнее сохранение ресурса.
И, если

$modx->resource->editedon <= $lastMod

дата последнего Last-modified, который запомнил клиент (браузер или робот поисковика) больше (или равна) дате последнего сохранения ресурса в modx, то вы отдаёте 304 и клиент эту страницу загружать уже НЕ БУДЕТ.

Но вот нюансы:
— если вы добавили новый ресурс, который должен быть виден в меню;
— или у вас появился новый комментарий к статье;
— или у вас стоит какой-нибудь модуль финансовых сводок, который должен отображать актуальную информацию;
— да мало ли что ещё…
то пользователь этих изменений уже не увидит! Потому что он будет брать эту страницу из своего кэша.

ИМХО вопрос с Last-Modified нужно продумывать ГОРАЗДО тщательнее и на каждом конкретном сайте в индивидуальном порядке. И простым плагином здесь уже не обойтись.
Всё зависит от (кхм) зависимостей данных, отображаемых на текущей странице, от данных на других страницах (к примеру вывод новостей) или сниппетов и модулей (к примеру галереи или комментарии).

Вот такие пироги. Решайте — выбирать вам.

Значит надо будет написать, когда вплотную к этому вопросу подойду.
А потом объединить 2 функционала)

Я просто пока над регистрацией особо не заморачивался ещё, но хотелось бы уточнить один момент, чтобы потом знать с какой стороны к нему заходить…

А аватарка юзера?
В данном случае она берётся из gravatar.
Но если авы в граватаре нет, то есть ли вообще какая-нибудь возможность вытащить авы из привязанных соц.сетей? Понятно, что всё это гуглится и изучаются api социалок. Но может ты уже интересовался подобным?

з.ы. слышал, что вроде как вк аватарки не отдаёт, но ведь можно попробовать и curl прикрутить :-)

Блин! Так это реально ж круто!

Получается к одному аккаунту можно привязать сразу все доступные в HybridAyth аккаунты из соц.сетей?
Т.е. будучи залогиненным под гугловским аккаунтом, я могу привязать и ВК, и FB, и всё остальное?

Гуд, спасибо! :-)

Да об этом много где написано, но сам я это не усвоил, пока не потратил несколько часов на устранение описанных выше багов :-)

Ошибочка вышла в комментарии…
Правильно надо так:

поиск бага на тему — почему же НЕ закрывается js-модальное окно или кастомный комбобокс