Идеи пользователя 104137
Редактирование шаблонов почтовых событий без подсветки и в браузере - сущий ад. Новая фишка с почтовыми шаблонами особо не спасает. При командной разработке работать с событиями приходится через миграции, а проблем и без них хватает.
Предлагаю вынести вёрстку шаблонов почтовых событий в файлы и для обратной совместимости использовать оба варианта. к примеру, организовать хранение можно как /local/mail_templates/event_type/mess_id.php при этом нужно подумать как там организовать доступ к переменным, в .т.ч. глобальным. И при создании почтового события делается проверка на существования файла, если есть он включается, если нет - берётся тело шаблона из базы. Или хотя бы подсветку синтаксиса дайте при редактирjвании в формате html.
этот подход позволит сохранить совместимость со старыми проектами и даст вектор развития новой системе шаблонов. Удобно их хранить и главное не будет проблем с CVS.
такое ощущение что про основные модули уже забыли, постоянно развивают именно интернет магазин. Некоторые болячки тянутся годами которые постоянно раздражают. Развитие и новые фишки безусловно нужны, но вы хотя бы другие модули в порядок приведите.
Предлагаю вынести вёрстку шаблонов почтовых событий в файлы и для обратной совместимости использовать оба варианта. к примеру, организовать хранение можно как /local/mail_templates/event_type/mess_id.php при этом нужно подумать как там организовать доступ к переменным, в .т.ч. глобальным. И при создании почтового события делается проверка на существования файла, если есть он включается, если нет - берётся тело шаблона из базы. Или хотя бы подсветку синтаксиса дайте при редактирjвании в формате html.
этот подход позволит сохранить совместимость со старыми проектами и даст вектор развития новой системе шаблонов. Удобно их хранить и главное не будет проблем с CVS.
такое ощущение что про основные модули уже забыли, постоянно развивают именно интернет магазин. Некоторые болячки тянутся годами которые постоянно раздражают. Развитие и новые фишки безусловно нужны, но вы хотя бы другие модули в порядок приведите.
В системе реализована достаточно гибкая система резервного копирования, но иногда не хватает возможности экспортировать 1 таблицу. Я понимаю что это можно сделать через PMA, но есть не всегда, да и лишние манипуляции... открыть PMA на одном сервере, экспортнуть, загрузить на другой сервер, отловить ошибку ключей, импортнуть. Было бы на много удобнее работать из админки битрикса.
Сейчас в D7 аналог CMain::GetCurPageParam выглядит так:
На мой взгляд немного избыточно, предлагаю в конструктор Uri добавить текущий URL по умолчанию и сократить текущую запись до
$request = Application::getInstance()->getContext()->getRequest();
$uriString = $request->getRequestUri();
$uri = new Uri($uriString);
$uri->deleteParams(array("baz"));
$uri->addParams(array("foo" => "bar"));
$redirect = $uri->getUri(); |
$uri = new Uri();
$redirect = $uri->deleteParams(array("baz"))->addParams(array("foo" => "bar"))->getUri(); |
Есть 2 общих практики при работе в битриксе с ajax:
1. Создать отдельный файл-обработчик с подключением файла
и на этот файл делать ajax запросы. Этот метод хорош тем что выполняется минимум лишнего кода, но имеет существенный недостаток: постоянно приходятся создавать отдельный файл в компоненте либо то в другом месте, и начинается постоянная путаница.
2.
Ссылаться на страницу с компонентом и в компоненте по условию сбрасывать буфер
Тут всё прекрасно, код в тонусе и не запутаешься. НО выполняется весь хеадер и как правило там несколько компонентов включая малую корзину, меню и прочее ( тут всё зависит от фантазии ) что естественно даёт задержку выполнения.
предлагаю другое решение.
3.
дать возможность в init.php определить константу
BX_NO_INCLUDE_AJAX_PROLOG
и в файле prolog.php по условию не подключать файл prolog_after.php
соответственно так же не подключать пролог. так и код компонентов в тонусе, и лишнего кода не выполняется. А для ajax запросов компонентов из хеадера или футера уже делать отдельный файл или не определять эту константу. Тут уж дело вкуса.
1. Создать отдельный файл-обработчик с подключением файла
require($_SERVER["DOCUMENT_ROOT"]."/bitrix/modules/main/include/prolog_before.php"); |
и на этот файл делать ajax запросы. Этот метод хорош тем что выполняется минимум лишнего кода, но имеет существенный недостаток: постоянно приходятся создавать отдельный файл в компоненте либо то в другом месте, и начинается постоянная путаница.
2.
Ссылаться на страницу с компонентом и в компоненте по условию сбрасывать буфер
if( conditional ){
$APPLICATION->RestartBuffer();
header('Content-Type: application/json');
....
die();
} |
предлагаю другое решение.
3.
дать возможность в init.php определить константу
BX_NO_INCLUDE_AJAX_PROLOG
и в файле prolog.php по условию не подключать файл prolog_after.php
$isAjaxRequest = \Bitrix\Main\Application::getInstance()->getContext()->getRequest()->isAjaxRequest();
if( defined('BX_NO_INCLUDE_AJAX_PROLOG') ){
if(!$isAjaxRequest)
require($_SERVER["DOCUMENT_ROOT"].BX_ROOT."/modules/main/include/prolog_after.php");
}else{
require($_SERVER["DOCUMENT_ROOT"].BX_ROOT."/modules/main/include/prolog_after.php");
}
|
соответственно так же не подключать пролог. так и код компонентов в тонусе, и лишнего кода не выполняется. А для ajax запросов компонентов из хеадера или футера уже делать отдельный файл или не определять эту константу. Тут уж дело вкуса.
Из 1с выгружаем большой каталог.
Справочник достиг размера 15к элементов.
В настройках свойства каталога, в модальном окне подгружаются 15к строк - ненормально....
Нужно бы поставить пагинатор или просто ограничить и выводить первые 100, и ссылку на hiload инфоблок.
Справочник достиг размера 15к элементов.
В настройках свойства каталога, в модальном окне подгружаются 15к строк - ненормально....
Нужно бы поставить пагинатор или просто ограничить и выводить первые 100, и ссылку на hiload инфоблок.
Этот метод при расчёте скидок по правилам работы с корзиной учитывает группы пользователя в базе.
Что не даёт по определённым условиям управлять скидками. Как пример, недавняя задача:
Для людей которые бросили корзину(так и не войдя в систему) в гугле получают ссылку с информацией о скидки 5%. Скидка применяется к условной группе. По урлу захода на сайт эта группа назначается нашему анонимному, пока анонимному, пользователю что бы тот получил свою законную скидку. Но вот беда, DoProcessOrder не понимает группы в сессии пользователя и следовательно не применяется скидка.
Я понимаю что это сделано что бы если в срочном порядке пользователя лишили группы, (допустим золотые покупатели) он не получал из сессии принадлежность и соответственно скидку.
Нужно как то этот вопрос решить. Моё видение ситуации следующее:
Сделать встроенный хендлер на изменение пользователя который бы регистрировал изменение пользователя, а при загрузке страницы проверять - были ли изменения. если нет берём данные из сессии, иначе обновляем данные в сессии беря их бд.
А в нашем DoProcessOrder брать группы пользователя из сессии. Это позволило быи рыбку съесть и ...
и гибко использовать группы для анонимных юзеров и держать актуальные данные в сессии.
Мой алгоритм - всего лишь примитивный пример реализации, уверен вы сможете сделать это более элегантно.
$groupDiscountIterator = Internals\DiscountGroupTable::getList(array(
'select' => array('DISCOUNT_ID'),
'filter' => array('@GROUP_ID' => CUser::GetUserGroup($arOrder['USER_ID']), '=ACTIVE' => 'Y')
));
|
Для людей которые бросили корзину(так и не войдя в систему) в гугле получают ссылку с информацией о скидки 5%. Скидка применяется к условной группе. По урлу захода на сайт эта группа назначается нашему анонимному, пока анонимному, пользователю что бы тот получил свою законную скидку. Но вот беда, DoProcessOrder не понимает группы в сессии пользователя и следовательно не применяется скидка.
Я понимаю что это сделано что бы если в срочном порядке пользователя лишили группы, (допустим золотые покупатели) он не получал из сессии принадлежность и соответственно скидку.
Нужно как то этот вопрос решить. Моё видение ситуации следующее:
Сделать встроенный хендлер на изменение пользователя который бы регистрировал изменение пользователя, а при загрузке страницы проверять - были ли изменения. если нет берём данные из сессии, иначе обновляем данные в сессии беря их бд.
А в нашем DoProcessOrder брать группы пользователя из сессии. Это позволило бы
и гибко использовать группы для анонимных юзеров и держать актуальные данные в сессии.
Мой алгоритм - всего лишь примитивный пример реализации, уверен вы сможете сделать это более элегантно.
Ответил 
Жуков Евгений 22.01.2018 15:38:45
Жуков Евгений 22.01.2018 15:38:45
Это было сделано для того, чтобы заказ, оформленный клиентом из публички, и заказ, оформленный для того же клиента менеджером, были идентичными. Эта политика меняться не будет, более того, в новом провайдере работа с группами пользователя стала такой же (данные сессии игнорируются).
Понятно что её можно самому сделать. Но всё равно хотелось бы иметь документацию по d7 онлайн c с возможностью комментариев от сообщества разработчиков.
Это даст большой скачок популяризации нового ядра и улучшения знаний разработчиков.
Это даст большой скачок популяризации нового ядра и улучшения знаний разработчиков.
Сделать для всех служебных скриптов битрикса, атрибут асинхронной загрузки - по умолчанию "defer"
Это ускорит загрузку страницы.
Это ускорит загрузку страницы.
Переписать все шаблоны компонентов использующие ajax в порядок. Для порядка нужен расширяемый JS шаблонизатор. Это позволит изменять внешний вид компонента без магии перелопачивания простыни js кода.
Привести все шаблоны компонентов в нормальный вид, что бы не хотелось плакать при их виде и переписывать их с 0.
Ответил 
19.08.2014 12:35:35
19.08.2014 12:35:35
Коллеги, старайтесь излагать свои мысли более конкретно. В таком варианте эта идея не имеет решения, что будет выступать критерием ее решения?
Да и не все компоненты плохие на вид, серия каталожных вполне приятная, оформление заказов, публичные компоненты списка заказов и их просмотр приятные. И так можно перечислять долго.
В продукте огромное число компонентов и переделывать их все утопия, часть компонентов устарели, мы работаем в сфере которая очень динамична.
Давайте конкретизируем идею, напишем список компонентов которые действительно в первую очередь должны быть исправлены, пусть их буде 10, с описанием, что вам не нравится и в какую сторону вы бы хотели их изменить, тогда идея имеет высокий шанс быть выполненной и взятой в работу!
Да и не все компоненты плохие на вид, серия каталожных вполне приятная, оформление заказов, публичные компоненты списка заказов и их просмотр приятные. И так можно перечислять долго.
В продукте огромное число компонентов и переделывать их все утопия, часть компонентов устарели, мы работаем в сфере которая очень динамична.
Давайте конкретизируем идею, напишем список компонентов которые действительно в первую очередь должны быть исправлены, пусть их буде 10, с описанием, что вам не нравится и в какую сторону вы бы хотели их изменить, тогда идея имеет высокий шанс быть выполненной и взятой в работу!
© 2001-2023 «Битрикс», «1С-Битрикс». Работает на 1С-Битрикс: Управление сайтом.
Соглашение об использовании сайта
Соглашение об использовании сайта
