Дело в том, что именно первая строчка выплевывает jquery системный, а вторая строчка js-скрипты шаблона (которые по правильному должны подрубаться через AddHeadScript). Таким образом, если их поменять местами, сначала пойдут скрипты, использующие jquery, а затем сама jquery. Конечно же, jquery это лишь пример подводного камня.
PS: Такой же порядок в
<?$APPLICATION->ShowHead();?>
но мне метод не нравится в силу того, что я не могу сам раскидать теги как мне надо.
Не путайте людей, сейчас через настройки можно выносить все js вниз страницы, а их порядок зависит от порядка их регистрации в шаблоне.
В 90% случаев подключаете первую jquery и подобные библиотеки и патом всё остальное и никаких проблем не будет, а если всё же есть то вы изобрели велосипед.
Я думаю это очевидно должно быть, что строка идет Выше, потому что как раз в ней часто вызывается jquery с гугла.
А вот у меня назрел вопрос, есть ли реальная разница между Asset::getInstance()->addString(""); и $APPLICATION->ShowHeadStrings(); в скоросрти работы, и не отвалится ли $APPLICATION в одном из обновлений битрикса, в результате полного перехода на D7.
Стояла задача создать страничку с календарём мероприятий*,правда с функциональностью почти как у GoogleCalendar.
Примечание*1 мероприятие – элемент ИБ, имеющий конкретную дату/время проведения.
Что требовалось от функционала:
Загрузка событий в календарь из ИБ.
Отображение двух вкладок: Неделя, Месяц, с возможностью перехода по неделям/месяцам вперед и назад во времени.
В один календарный день может проводиться несколько мероприятий. Если мероприятие длится более 1го дня, то оно протягивается по календарной сетке на к-во дней, равное своей длительности.
Экспорт в ICal, MSOutLook.
Название мероприятия должно являться ссылкой и вести на страницу детального просмотра.
Выбрал для решения этой задачи календарь событий 2.0. Создал в модуле календарь тип событий, бросил на страницу компонент bitrix: calendar.grid. Залез в код компонента и понял, что для решения моей задачи придется долго и нудно ковыряться в ядре модуля календарь. Начал распиливать этот недокументированный «чёрный ящик», а он же работает только с событиями.
Написал метод для превращения элементов ИБ в события календаря.
Выглядит он примерно так:
Код
public static function LoadCalendarEventsFromIB($iblockID, $calendarType, $calendarSectionID = false, $arAddFilter = false, $arDecoration = false) {
<br /> //если не задан календарь, то создаем новый
<br /> if (intval($calendarSectionID) > 0) {
<br /> $bAutoCreateSection = false;
<br /> } else {
<br /> $bAutoCreateSection = true;
<br /> }
<br /> if (CModule::IncludeModule("iblock" && CModule::IncludeModule("calendar") {
<br /> $arFilter = array("IBLOCK_ID" = > $iblockID, "ACTIVE" = > "Y", "ACTIVE_DATE" = > "Y", ">DATE_ACTIVE_TO" = > date("Y-m-d");
<br /> //если есть дополнительный фильтр, объединим его с уже сформированным
<br /> if (is_array($arAddFilter) && (count($arAddFilter) > 1)) {
<br /> $arFilter = array_merge($arFilter, $arAddFilter);
<br /> }
<br /> $arSelect = array("ID", "NAME", "DATE_ACTIVE_FROM", "ACTIVE_DATE", "DATE_ACTIVE_TO";
<br />
<br /> //массив для записи в b_calendar_...
<br /> $arEventsToDb = array();
<br /> //выбираем мероприятия
<br /> $dbRes = CIBlockElement::GetList(array(), $arFilter, false, false, $arSelect);
<br /> if (intval($dbRes - > SelectedRowsCount()) > 0) {
<br /> global $USER;
<br /> //массив для успешно записанных в БД событий
<br /> $arSuccessfullyAdded = array();
<br /> //если необходимо записывать в уже существующий календарь
<br /> //проверим — нет ли в нем ещё этих мероприятий
<br /> if (!$bAutoCreateSection) {
<br /> //выберем уже существующие события в данном календаре, из b_calendar..
<br /> $arExistEvents = CCalendarEvent::GetList(
<br /> array('arFilter' = > array("SECTIONS" = > array($calendarSectionID)), 'parseRecursion' = > false));
<br /> if (count($arExistEvents) > 0) {
<br /> $arExistEventsID = array();
<br /> foreach($arExistEvents as $oneExistEvent) {
<br /> $arExistEventsID[] = intval($oneExistEvent['LOCATION']
<br /> }
<br /> }
<br /> }
<br /> while ($arRes = $dbRes - > GetNext(true, false)) {
<br /> //если в b_calendar_... еще нет такого мероприятия
<br /> if (!in_array(intval($arRes['ID'], $arExistEventsID)) {
<br /> $arEventsToDb[$arRes['ID']]['DT_FROM'] = $arRes['DATE_ACTIVE_FROM'];
<br /> $arEventsToDb[$arRes['ID']]['DT_TO'] = $arRes['DATE_ACTIVE_TO'];
<br /> $arEventsToDb[$arRes['ID']]['NAME'] = $arRes['NAME'];
<br /> $arEventsToDb[$arRes['ID']]['OWNER_ID'] = $USER - > GetID();
<br /> $arEventsToDb[$arRes['ID']]['DESCRIPTION'] = $arRes['NAME'];
<br /> $arEventsToDb[$arRes['ID']]['COLOR'] = ($arDecoration['COLOR'] ? $arDecoration['COLOR'] : "#FFFFFF";
<br /> $arEventsToDb[$arRes['ID']]['TEXT_COLOR'] = ($arDecoration['TEXT_COLOR'] ? $arDecoration['TEXT_COLOR'] : "#00679A";
<br /> $arEventsToDb[$arRes['ID']]['SECTIONS'] = array($calendarSectionID);
<br /> $arEventsToDb[$arRes['ID']]['LOCATION'] = $arRes['ID']; //пишем ID мероприятия
<br /> }
<br /> }
<br /> //если есть что записывать в b_calendar_...
<br /> if (count($arEventsToDb) > 0) {
<br /> //создаем экземпляр объекта
<br /> $obCalendar = new CCalenar();
<br /> foreach($arEventsToDb as $elID = > $oneEvent) {
<br /> $toDB = array("arFields" = > array_merge(array("CAL_TYPE" = > $calendarType), $oneEvent), "autoDetectSection" = > true, "autoCreateSection" = > $bAutoCreateSection);
<br /> //пишем событие в БД
<br /> $eventID = $obCalendar - > SaveEvent($toDB);
<br /> if ($eventID > 0) {
<br /> $arSuccessfullyAdded[$elID] = $eventID;
<br /> } else {
<br /> //произошла ошибка при записи события в БД
<br /> return false;
<br /> }
<br /> }
<br /> } else {
<br /> //записывать нечего
<br /> return false;
<br /> }
<br /> } else {
<br /> //выборка не содержит мероприятий по заданному фильтру
<br /> return false;
<br /> }
<br /> }
<br /> return true;
<br />}
<br />//end of LoadCalendarEventsFromIB
<br />
С отображением вкладок календаря, экспортом в ICal—вроде проблем не было.
Настал момент натягивать дизайн. Тут задался задачей: «Как сделать так, чтобы название события вело на страницу детального просмотра?»
Вернулся в код компонента и понял, что никакой догмой разработки на компонентах и их шаблонах — тут и не пахнет. Весь рендеринг кода зашит в CCalendar, а именно в CCalendarSceleton::Build(array(“Куча недокументированных параметров…”)); Кому интересно — /bitrix/modules/calendar/classes/general/calendar_sceleton.php:5
Пришлось наследовать и переопределять методы под решение данной задачи...
А ведь, с одной стороны для решения задачи не хватало то:
Компонента «Календарь событий» с возможностью загрузки событиями из ИБ и функциональностью «Календарь событий 2.0».
Шаблона компонента(с CSS и JS-ом как раньше, а не зашитым в ядро).
Раньше подобные задачи сводились к кастомизации шаблона типичного компонента поэтому имеется ряд вопросов:
Это новый стиль разработки фреймворка? Когда представление зашивается в ядро и интегратору приходится наследовать методы.
Имхо стоит подружить календарь с ИБ, как основным хранилищем структурированных данных. Т.к. там уже есть ряд полей вроде даты-начала, даты окончания, на которых в 90% случаев интеграторы делают подобные вещи.
Не полетит ли функционал, написанный на ООП после обновления модуля календарь, на 12й версии БУС?
Тоже столкнулся с кастомизацией календаря. Чтобы он работал как нужно нам пришлось компоненты внутрь компонентов копировать, и я ведь понимаю что после моей работы мало кто сможет толком разобраться что конкретно было поменяно.
Hello I am so delighted I located your blog, I really located you by mistake, while I was watching on google for something else, Anyways I am here now and could just like to say thank for a tremendous post and a all round entertaining website. Please do keep up the great work.
Для выполнения каких-либо действий в назначенный момент в Битриксе используются агенты: и .
Агенты названы крайне неудачно "периодические" и "непериодические". Разберём, какие реально бывают агенты.
Агент - это запись в специальной таблице:
какой код надо выполнить,
когда выполнить,
с каким периодом выполнять,
каким способом назначать время следующего запуска агента (периодический или непериодический агент).
Обычно, когда пользователь зашел на страничку сайта, ядро Битрикса смотрит, есть ли агенты, время которых наступило и выполняет их.
Важно. В начале хита еще не объявлена переменная $USER. Её в агентах использовать нельзя.
Можно в агенте создать объект $USER, что-то с ним сделать и уничтожить.
Реальное время запуска агента обычно чуть-чуть позже, чем время, на которое назначен агент. Момент запуска — это когда кто-то зашел на страницу сайта.
Настройки -> Настройки продукта -> Агенты:
Агенты, прежде всего, бывают повторяющиеся или неповторяющиеся. Это зависит от программиста, который написал код агента.
Если функция агента возвращает вызов себя, то агент повторяется.
Если функция агента ничего не возвращает, то агент будет удален из таблицы и больше не запустится. Агент не повторяется.
Программист может сделать агента, который повторится бесконечное число раз. Или только 2-3 раза в зависимости от условий. В списке агентов это увидеть нельзя. Только смотреть в код.
Пример функций агентов повторяющихся бесконечное число раз:
// пример функций агентов
function TestAgentPeriod()
{
AddMessage2Log( "Периодический BX_CRONTAB:".BX_CRONTAB." BX_CRONTAB_SUPPORT:".BX_CRONTAB_SUPPORT );
return "TestAgentPeriod();";
}
function TestAgentNotPeriod()
{
AddMessage2Log( "Непериодический BX_CRONTAB:".BX_CRONTAB." BX_CRONTAB_SUPPORT:".BX_CRONTAB_SUPPORT );
return "TestAgentNotPeriod();";
}
Вычисление следующего времени запуска.
Для повторяющихся агентов есть смыл говорить об интервале запуска и способе вычисления времени следующего запуска.
В данном примере интервал агентов 15 секунд. Один агент периодический, а другой непериодический.
Назначенное время следующего запуска периодического агента вычисляется так:
Старое назначенное время агента + интервал.
Этот способ позволяет запустить агент точное число раз. Например, раз в день запускается агент очистки старых почтовых событий или агент с ежедневным отчетом о посещаемости сайта.
Назначенное время следующего запуска непериодического агента вычисляется так:
Время завершения последнего запуска агента (выполнение return агента) + интервал
Абсолютное большинство агентов непериодические.
Например, агент пересчета рейтингов запускается раз в час. Но если за сутки не было ни одного посетителя, то логичнее выполнить агент один раз и сдвинуть назначенное время следующего запуска на час вперед после запуска. В случае периодического агента, этот код выполнился бы 24 раза за все сутки.
Агенты могут запускаться не только на хитах пользователя, но и . Но, как это правильно настроить, — тема .
Старицин Геннадий, если агент периодический и время следующего запуска у него 15:00:00, то после 15:00:00 Битрикс попытается его запустить. И неважно сколько времени агент будет работать. Если интервал один час, то время следующего запуска будет назначено 16:00:00.
-----------
Если агент непериодический и выполняется 5 минут, то всё сложнее.
Допустим хит пользователя (или крон) пришел в 15:01:00, агент реально запустился в 15:01:00 и закончил работу в 15:06:00. Тогда время следующего запуска непериодического агента 16:06:00.
------------
Поэтому я предлагаю называть агенты так. Повторяющиеся и неповторяющиеся.
Повторяющиеся бывают:
Периодические - это строго периодические. Непериодические - это нестрого периодические.
Для неповторяющихся одноразовых агентов разницы периодический или непериодический почти нет.
Наверное, никто не будет спорить, что форма оформления заказа это самый сложный элемент для кастомизации, так как если внешний облик формы не устраивает клиента, то попотеть придется. Как-то так:
Поэтому, я поделюсь кое-какими соображениями о самой сложной части кастомизации - о блоке свойств. И да, речь пойдет исключительно об одношаговом компоненте как самом ходовом и современном. Много я шишек набил на этих формах, много шагов было сделано неправильных. Вот какие правила я вынес:
1. Нельзя писать свою форму (свою логику). Ой поплачете. За прошлые годы я свидетель как эта форма меняется раз в квартал стабильно. Меняются алгоритмы, добавляются события, на которые вешаются сторонние решения Маркета. В общем, не лезьте туда. Выносить и менять логику - ну если прямо , то можно.
2, Если форма сложная, то по части свойств предусмотреть универсальность практически нельзя. Да, вы конечно будете несомненно крутым интегратором, если сделаете сабж выше универсальным, который бы подстраивался под новые свойства. Но мой вам совет - тоже не стоит. Даже если в такой форме добавится "телефон соседей", то ее придется дорисовать сначала, потом утвердить, а потом снова "доинтегрировать". Я рекомендую такие формы заранее обговаривать с клиентом и объяснять ему, что так мол и так.
3. Есть еще вариант говнокдинга (тоже пройденный, несомненно), когда мы ставим кучу if'ов, чтобы знать в каком месте html вывести то или иное свойство. Были чужие варианты и пострашнее, когда в форму, какая она есть от верстальщика, вставляешь name="ORDER_PROP_123", где 123 завтра может смениться и всему конец. Динамика должна остаться хотя бы в именовании полей.
4. Контролируйте и учите верстальщика. Об этом в самом конце.
Посему, от п.2 мы и оттолкнемся (и не забудем про п.3). Итак, смотрим на верстку, и видим, какие свойства нам надо создать. То есть то, что является именно свойствами
Создаем их, с чувством, с толком, с расстановкой. Вот так они выглядят в шаблоне visual без кастомизации (кстати, этот шаблон вышел недавно, и рекомендую использовать впредь всегда его). placeholder'ы, которые вы видите на первом скрине, я поместил в поле "описание" свойств.
Копируем шаблон на редактирование и идем во внутренний файл шаблона props.php. Там находим блок вывода свойств. Это происходит в два шага - первый это те свойства, которые не входят в профиль, и заполняются каждый раз снова и снова. Второй - свойства, которые могут быть сохранены в профиле. Так как такая форма не предполагает первый вариант, мы его убираем. Ну и все свойства вам конечно надо создавать с галочкой "сохранять в профиле".
Далее перемещаемся в самый верх функции PrintPropsForm, которая расположена здесь же, и пишем там буферизацию куска html, отвечающего за блок свойств.
Кусок html представляет из себя обычный html, где вместо полей формы мы пишем маркеры с кодами свойств (#КОД_СВОЙСТВА#).
Весь этот блок у нас в переменной $props, который надо вывести в аккурат после foreach, который идет далее.
Промежуточный результат у нас какой-то такой
Теперь, в самом начале блока foreach нам надо вставить переопределение нужных полей. Мне нужны были только TEXT и одна TEXTAREA. Руководствуясь пунктом 2 на остальные свойства забиваем. Потом ставим continue и что дальше происходит - нас не волнует.
То есть, еще раз - мы берем и заменяем маркеры в буферизированном блоке на живые поля ввода, такие, какие они были бы в нормальном выводе. Получаем результат полностью рабочий.
Какое правило мы еще отсюда вынесли? То самое - правило 4. То, что верстальщик должен быть в теме, а лучше работать бок-о-бок с интегратором. Верстальщик сей верстки был профессиональным, поэтому не стал каждому инпуту давать свой индивидуальный класс, даже поле индекса не имеет ни отдельного класса, ни size="4". Респект! Что позволило нам максимально быстро и чисто интегрировать верстку в форму.
К посту я прикрепляю файл props.php, где вы можете посмотреть пример кода из урока. Он конечно еще не закончен (для данной верстки), я намеренно оставил его таким для примера.
А я использую компонент по шагам bitrix:sale.order.full и в нем нет файла props.php зато есть функция PrintPropsForm Есть варианты как отсортировать свойства по группам?
Дмитрий, не смотря на то, что это многошаговый, св-ва и так по группам должны идти (а иначе как?). Возможно ошибка какая-то, рекомендую в Битрикс стукнуть.
Зачем заменять маркеры в буферизированном блоке на живые поля ввода, если потом просто ставить continue? Не претендую на истину последней инстанции. Мне просто хочется разобраться.
В одном из моих личных проектов потребовалось сделать приложение 2 типа для bitrix24 и работать с его API. Я человек ленивый, поэтому решил написать «простенькую» обёртку поверх REST- вызовов.
Библиотека живёт на github —
Пример получения текущего юзера
// инициализируем бибилиотеку для работы с B24
$obB24App = new \Bitrix24\Bitrix24();
$obB24App->setApplicationScope($arParams['B24_APPLICATION_SCOPE']);
$obB24App->setApplicationId($arParams['B24_APPLICATION_ID']);
$obB24App->setApplicationSecret($arParams['B24_APPLICATION_SECRET']);
// выставляем настройки, зависящие от пользователя
$obB24App->setDomain($arParams['DOMAIN']);
$obB24App->setMemberId($arParams['MEMBER_ID']);
$obB24App->setAccessToken($arParams['AUTH_ID']);
$obB24App->setRefreshToken($arParams['REFRESH_ID']);
// получили информацию по текущему пользователю из Bitrix24
$obB24User = new \Bitrix24\User\User($obB24App);
$arCurrentB24User = $obB24User->current();
Пример получения списка задач
/**
* объект для работы с задачами
**/
$obTasks = new \Bitrix24\Task\TaskItems($obB24App);
/**
* список задач из B24
* @var $arB24Tasks array */
$arB24Tasks = $obTasks->getList(
array("ID" => 'desc'),
array('RESPONSIBLE_ID' => $arUser['B24_USER_ID']),
array('ID','TITLE','CREATED_DATE','DEADLINE','STATUS','REAL_STATUS','STATUS_CHANGED_DATE','GROUP_ID','CHANGED_DATE'),
null);
Я её периодически обновляю, но уже сейчас она вполне пригодна для работы. Критика и пулл-реквесты приветствуются.
2/ Определяемся с инфоблоком - ниже в скрипте в параметр $arParams['IBLOCK_ID'] нужно записать его ID
3/ Решаем, нужно ли нам генерировать совсем уникальные коды. Можно вначале пройтись и создать не повторяющиеся, а для повторяющихся добавить в конце ID. За это отвечает параметр $arParams['IS_ADD_RAND'] - {true|false}
4/ Указываем шаг выборки - параметр $arParams['LIST_CNT'] - большим не стоит делать, максимум 100 элементов за раз
5/ Настраиваем параметры транслита. За это отвечает массив $arTransParams
6/ Указываем для чего будем проводить генерацию - для разделов или для элементов - параметр $arParams['TYPE_WORK'] - возможные значения - {section | element}
7/ Жмем кнопку выполнить - прогнать скрипт нужное количество раз
Не так давно я писал пост о том . Пришло время CSV, но там еще проще.
require_once ($_SERVER["DOCUMENT_ROOT"]."/bitrix/modules/main/classes/general/csv_data.php";);
$csvFile = new CCSVData('R', true);
$csvFile->LoadFile($_FILES['csv']['tmp_name']);
$csvFile->SetDelimiter(',');
while ($arRes = $csvFile->Fetch()) {
ec($arRes);
}
Собственно: - подключаем файл класса работы с CSV - создаем объект класса, указываем, что будет использоваться разделитель (R, есть еще фикс.поля F), и первая строка содержит заголовки (true); можно не указывать эти параметры и задать отдельными методами
- загружаем файл - ставим делиметер, где допустимые параметры: \t (табуляция), запятая, пробел, точка с запятой. - бежим как при обычной выборке из базы (напомню, Fetch возвращает НЕ обработанные данные, а GetNext безопасные).
Semenov Roman, да никто же не спорит Тут вопрос скорее не "почему не использовали именно эту фичу", а "зачем понадобилось писать прослойку, да еще и не очень удобную"
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».
Весь рендеринг кода зашит в CCalendar, а именно в CCalendarSceleton::Build(array(“Куча недокументированных параметров…”));
;
Тут вопрос скорее не "почему не использовали именно эту фичу", а "зачем понадобилось писать прослойку, да еще и не очень удобную"
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».
В 90% случаев подключаете первую jquery и подобные библиотеки и патом всё остальное и никаких проблем не будет, а если всё же есть то вы изобрели велосипед.
А вот у меня назрел вопрос, есть ли реальная разница между Asset::getInstance()->addString(""); и $APPLICATION->ShowHeadStrings(); в скоросрти работы, и не отвалится ли $APPLICATION в одном из обновлений битрикса, в результате полного перехода на D7.