Сейчас в классе компонента подключаются js-расширения (fx, popup, window, ajax, date) которые нужны не всем. Предлагаю добавить в компонент параметр для управления их подключением или вынести их в шаблон.
Иван, возможно, я не так вас понял, но на данный момент штатные формы и так посредством JS встраиваются. Это уже потом скрипты дорисовывают фрейм. Но так уж они работают.
Зачастую куча компонентов из-за отсутствия блоков на странице попросту не нужна в сайтах, а они грузятся. Было бы круто иметь возможность отключать все, что не нужно в header.
Компонент корзина(sale.basket.basket) написан край как неудачно! И не только он...
В js идет построение верстки, но mvc и шаблонное проектирование вообще против такой парадигмы программирования! js должно только менять значения, а не конструировать верстку. Для js можно оставлять id в верстке и их же передавать массивом в js для дальнейшей работы с данными.
Сейчас же, для банальной стилизации компонента приходится его переписывать почти на половину! Предлагаю разработчикам пересмотреть стиль написания стандартных шаблонов, для уменьшения стоимости работы по персонализации их CMS, а соответственно и увеличения популярности для конечных клиентов!
p.s. там же, в sale.basket.basket/class.php видел строки ужаса, где ресайзят картинки! в ЯДРЕ компонента, РЕСАЙЗ картинок, и только на 110x110px!
Шаблоны большинства компонентов Bitrix написаны по MVC, но некоторые компоненты реализованы на коленке и не задумываясь о сложностях кастомизации и использования!
Пример: компонент bitrix:sale.basket.basket верстка на таблицах, исправляем на более приемлемую для нас (но не сильно, буквально изменим table|tr|td на div) меняем классы, т.к. к ним привязаны стили и называются они не понятно. Теперь фокус! компонент не работает или работает частично! Оказывается разработчики добавили в js генерацию верстки!!! т.е. js сам прописывает table|tr|td и их предустановленные классы!
В итоге, кроме template.php | style.css нужно перебрать весь script.js !
Если написать всё по MVC - тогда "мухи отдельно, котлеты отдельно" функционал JS должен быть завязан только на ID элементов!! Чтобы кастомизация шаблона не убивала кучу времени разработчиков!
Полностью с вами согласен! Компонент находится на глобальном рефакторинге, выйдет к новому релизу. Будут отражены ваши пожелания и много интересного еще! Я думаю всем понравится!
Для коробочной версии Битрикс24 жизненно необходимо иметь возможность изменять стандартные js (например в всплывающие карточки звонка добавить новое поле или вывести доп.информацию), однако все "зашивается" на папку /bitrix/js/, а так как не предусмотрен штатный механизм для расширения js, то может стоит добавить папку /local/js/ для приоритетного замещения /bitrix/js/
Например при подключении core.js (/bitrix/js/main/core/core.js) проверялось бы наличие файла /local/js/main/core/core.js и в случае его существования подключался именно он.
Может для редакции БУС это не так актуально как для КП, но в КП это просто необходимость для кастомизации crm (да и например BX.ShowWait() можно кастомизировать)
В процессе разработки приложения для Битрикс24 столкнулись с необходимостью переходов на определённые URL посредством js. Но, к сожалению, смогли реализовать открытие определённого URL только в текущей вкладке (window.parent.location.href = <url>). А вот открыть URL в новой вкладке или новом окне не получилось. Техподдержка ответила, что сейчас такой возможности нет. А хотелось бы в дополнение к этим методам что-нибудь вроде BX24.openURL(url, params).
В версии 15.5 появилась возможность переместить весь js код в конец страницы. Как говорил Сергей Рыжиков "Магическим образом" это все происходит. Но есть исключения, которые не должны переноситься. Например google tag manager, который по документации должен быть в самом начале после открытия <body> Возник вопрос, как его добавить в исключение? Нужна такая возможность.
Наличие любого параметра (?blablabla) у ссылки на подключаемый файл заставляет любое клиентское приложение (браузер, прокси-сервер, мобильное приложение и т.д.) обязательно обратиться за файлом на сервер. Это RFC. Сервер, в лучшем случае ответит "304 Not Modified" (но при этом всё равно дёрнет файл с диска/памяти, чтобы проверить) или же полноценный 200 с полной передачей файла. Ответ сервера в некоторых кешах сохранится, в некоторых (н-р, AppCache) нет.
Соответственно, время модификации, хеш от него или любой другой праметр для cache busting должен быть в имени или пути файла (...template_283cd0022d3edc763e34cc00a91e7e1b/template_283cd0022d3edc763e34cc00a91e7e1b-142712022549372.js), а не в параметре (...template_283cd0022d3edc763e34cc00a91e7e1b/template_283cd0022d3edc763e34cc00a91e7e1b.js?142712022549372).
Проверить очень просто: при повторном открытии страницы сайта на сервер должен идти только 1 запрос - на саму страницу, а все остальные файлы должны браться из кеша браузера.
UPDATE 2015-04-01
Теоретическое обоснование и рекомендации от известных разработчиков:
Never access cached files by using traditional GET parameters (like other-cached-page.html?parameterName=value). This will make the browser bypass the cache and attempt to get it from network.