Как разработчик, не вижу оснований для использования библиотеки BX во фронтенде битрикс управление сайтом. Сама по себе библиотека трудна в использовании, а также плохо развита по сравнению с jQuery.
Использование jQuery во фронтенде компонентов - каталога, корзины, оформление заказа поможет разработчикам быстрее и эффективнее править код, а также разработчик получит дополнительную гибкость, BX имеет ограничения по сравнения с jQuery, при работе с измененной структурой DOM например.
Также использование jQuery должно облегчить порог входа для разработчиков системы и уменьшить общее время на разработку. Те использование jQuery является экономически оправданным.
В принципе возможно самому использовать jQuery вместо BX, но любопытный интегратор будет интересоваться что же происходит в BX, будет стараться изучить и понять данную библиотеку хотя по моему опыту на поддержку проекта на BX уходит времени больше если конечно была кастомизация шаблонов (catalog, sale.basket.basket, sale.order.ajax).
Поэтому я за переход платформы (БУС во фронтенде) на jQuery 1.
п.с Как всегда это мое личное мнение. Кто согласен плюсуйте.
Использование jQuery во фронтенде компонентов - каталога, корзины, оформление заказа поможет разработчикам быстрее и эффективнее править код, а также разработчик получит дополнительную гибкость, BX имеет ограничения по сравнения с jQuery, при работе с измененной структурой DOM например.
Также использование jQuery должно облегчить порог входа для разработчиков системы и уменьшить общее время на разработку. Те использование jQuery является экономически оправданным.
В принципе возможно самому использовать jQuery вместо BX, но любопытный интегратор будет интересоваться что же происходит в BX, будет стараться изучить и понять данную библиотеку хотя по моему опыту на поддержку проекта на BX уходит времени больше если конечно была кастомизация шаблонов (catalog, sale.basket.basket, sale.order.ajax).
Поэтому я за переход платформы (БУС во фронтенде) на jQuery 1.
п.с Как всегда это мое личное мнение. Кто согласен плюсуйте.
Те например разработчик указывает строчку $APPLICATION->registerAdditionalScript('jquery', SITE_TEMPLATE_PATH . '/js/jquery')
это значит что в дальнейшем запись вида $APPLICATION->showAdditionalScript('jquery') подключит версию jquery разработчика.
Все это уже есть в вордпресс, при огромном количестве плагинов.
это значит что в дальнейшем запись вида $APPLICATION->showAdditionalScript('jquery') подключит версию jquery разработчика.
Все это уже есть в вордпресс, при огромном количестве плагинов.
Текущая версия jQuery в ядре Битрикс - jQuery v1.8.3. Для bootstrap свежих компонентов и для современных версий фронтенд элементов необходима более свежая версия JQuery.
Считаю, что нужно обновить версию jQuery до последней.
Кто за?
Считаю, что нужно обновить версию jQuery до последней.
Кто за?
Если кто-то не заметил, то когда вы включаете композитный сайт автоматически в зависимости каждой страницы добавляются js-библиотеки BX.core, BX.ajax даже если вы их нигде больше не используете.
Почему добавляются понятно - нужно делать ajax-запросы к теневой странице. Но очень напрягает что ускорение за счет быстрой отдачи страницы смазывается загрузкой дополнительных ~150 кБ javascript.
Мне не жалко, вот только на мобильных (а мы помним что композит позиционируется как ускорение и для мобильников в особенности) загрзка и интерпретация этих лишних килобайт скриптов займет много времени.
Это все происходит при том, что на 99% сайтов используется jQuery. А если она уже загружается - почему бы не использовать ее? Битриксу переписать js-заглушки проще и правильнее чем заставлять каждого верстальщика учить BX и не использовать jQuery.
Суть идеи в том, чтобы в настройках модуля композитного сайта появилась настройка "Какую JS-библиотеку использовать для заглушек": BX / jQuery
Почему добавляются понятно - нужно делать ajax-запросы к теневой странице. Но очень напрягает что ускорение за счет быстрой отдачи страницы смазывается загрузкой дополнительных ~150 кБ javascript.
Мне не жалко, вот только на мобильных (а мы помним что композит позиционируется как ускорение и для мобильников в особенности) загрзка и интерпретация этих лишних килобайт скриптов займет много времени.
Это все происходит при том, что на 99% сайтов используется jQuery. А если она уже загружается - почему бы не использовать ее? Битриксу переписать js-заглушки проще и правильнее чем заставлять каждого верстальщика учить BX и не использовать jQuery.
Суть идеи в том, чтобы в настройках модуля композитного сайта появилась настройка "Какую JS-библиотеку использовать для заглушек": BX / jQuery
Битрикс регистрирует через CJSCore::RegisterExt библиотеку jquery. Соответственно ее можно и нужно использовать как зависимость во всяких component_epilog-ах и своих JS-библиотеках черзе CJSCore::Init
Говорить о том, что наврядли найдется сайт не использующий jquery, думаю не нужно.
Однако jQuery развивается и хочется идти вногу со временем. А для этого нужно периодически обновлять в ядре версию jQuery.
Никакое общение с техподдержкой и просьбы обновить jquery в ядре с версии 1.8 до более свежей естественно ни к чему не привели. Да и учитывая обратную совместимость наврядли коллеги захотят это делать (обновлять).
Ввиду этого - идея: всегда распространять с ядром все версии jQuery (хотя бы с точностью до второго числа версии) и дать возможность выбирать в настройках сайта/главного модуля какую версию регистрировать в CJSCore::RegisterExt под именем 'jquery'
Говорить о том, что наврядли найдется сайт не использующий jquery, думаю не нужно.
Однако jQuery развивается и хочется идти вногу со временем. А для этого нужно периодически обновлять в ядре версию jQuery.
Никакое общение с техподдержкой и просьбы обновить jquery в ядре с версии 1.8 до более свежей естественно ни к чему не привели. Да и учитывая обратную совместимость наврядли коллеги захотят это делать (обновлять).
Ввиду этого - идея: всегда распространять с ядром все версии jQuery (хотя бы с точностью до второго числа версии) и дать возможность выбирать в настройках сайта/главного модуля какую версию регистрировать в CJSCore::RegisterExt под именем 'jquery'
- Необходима возможность отображать фильтр по пользователям (для полей "кем создан", "кем изменен") у элементов так же как в разделах (без селекта)
- Необходима возможность в фильтре по элементам не выводить всех пользователей в селекте, а выводить только пользователей определенных групп
Под катом сценарий возможной проблемы:
Почему бы не сохранять в поставке и далее мажорные версии jQuery? Сейчас есть 1.7 и 1.8, с поступлением новых - и так далее. Места они много не просят.
Естественно, не просто сохранять, а сделать возможность инициализировать конкретную версию либы через
оно же
Например, InitJSCore('jquery18') или InitJSCore('jquery20'). А вызов без указания версии InitJSCore('jquery') зафиксировать на текущей - 1.8.x.
Это поможет избежать проблем с несовместимостью скриптов и версий библиотеки, не бояться обновления jQuery в поставке, ну и позволит разработчикам подключать именно то, что нужно.
Да, будет проблема на активных проектах, которые развиваются, ставят решения из МП, может возникнуть конфликт версий. Но он может возникнуть и сейчас, когда может использоваться прямое подключение файла либы в решении. Или же просто всё отпадёт при обновлении версии и потребует вмешательства разработчика.
А так хотя бы будет уверенность, что на уже сданных, стабильных проектах яваскрипт не умрёт при обновлении продукта из-за несовместимости с новой версией jQuery.
Естественно, не просто сохранять, а сделать возможность инициализировать конкретную версию либы через
CUtil::InitJSCore('') |
CJSCore::Init() |
Это поможет избежать проблем с несовместимостью скриптов и версий библиотеки, не бояться обновления jQuery в поставке, ну и позволит разработчикам подключать именно то, что нужно.
Да, будет проблема на активных проектах, которые развиваются, ставят решения из МП, может возникнуть конфликт версий. Но он может возникнуть и сейчас, когда может использоваться прямое подключение файла либы в решении. Или же просто всё отпадёт при обновлении версии и потребует вмешательства разработчика.
А так хотя бы будет уверенность, что на уже сданных, стабильных проектах яваскрипт не умрёт при обновлении продукта из-за несовместимости с новой версией jQuery.
Текущая версия jQuery, хранящаяся в платформе - 1.7 (3 ноября 2011). Уже почти 1,5 года прошло. Для нас это единственная причина не использовать jQuery из самого ядра.
Считаю, что нужно обновить версию jQuery до последней. Кто за?
Считаю, что нужно обновить версию jQuery до последней. Кто за?
Ответил 
Жуков Евгений 22.02.2013 16:56:12
Жуков Евгений 22.02.2013 16:56:12
Версия jQuery поднята до 1.8.3 в обновлении модуля main 12.0.7.
Сделать в настройках возможность подключать jquery и шла привязка к сайтам.
Чтобы при выходе новой версии jquery, он обновлялся с Битриксом.
Чтобы при выходе новой версии jquery, он обновлялся с Битриксом.
© 2001-2023 «Битрикс», «1С-Битрикс». Работает на 1С-Битрикс: Управление сайтом.
Соглашение об использовании сайта
Соглашение об использовании сайта
CJSCore::Init(array('jquery'))С другой стороны, jQuery параллельно развивает ветку под номером 2, которая аналогична ветке 1 за одним исключением - полным отсутствием поддержки IE8 и меньше. В связи с чем у меня есть альтернативный вариант - включить в продукт последнюю версию jQuery2 в виде дополнительного расширения jquery2, которое смогут использовать те партнеры, которые готовы расстаться с поддержкой IE8 и радоваться жизни.
CJSCore::Init(array('jquery2'))