Недавно меня попросили провести исследование системы разработки десктопных учетных систем ПК ВИКТА. Специфика, конечно, не моя, но вопрос так стоял - "Ну а кто, кроме тебя?" Просматривая в меру сил и знаний эту разработку (что было непросто ввиду отсутствия руководства разработчика) я обратил внимание на некоторые приемы, сходные с тем, что мы имеем в 1С-Битрикс. И поэтому у меня возник вопрос - "А была бы полезной веб-разработчику система разработки десктопных приложений, похожая на 1C-Битрикс Framework?" Вот его я и выношу, с вашего позволения, на исследование.
К слову, оказалось, что в решении используется оригинальная не реляционная БД, показавшая на тестах кратное преимущество по скорости и объему.
Для магазина полиграфических услуг ООО "Полиграфмастер" потребовался калькулятор расчета стоимости тиража. Я взял наш типовой калькулятор из Marketplace, но оказалось, что применить его для этой задачи без переделки невозможно. Порядок расчета был задан заказчиком вот так:
Как видно требовался расчет по формуле. Но это еще "полбеды". Основная "беда" была в таблице связей коэффициентов. Надо было реализовать логику при которой выбор значений в одном поле - изменял возможность выбора значений в другом. Стало ясно, что универсальный калькулятор далеко не так универсален, как хотелось бы.
Формулу удалось реализовать довольно просто и изящно. Добавил свойство следующего содержания: (K_1*K_4+40+K_2+K_3)*K_5, где K_1 ... N префиксы символьных кодов соответствующих свойств-коэффициентов, а вот с зависимыми полями пришлось попотеть...
В результате родился такой монстр к описанию поля Тип переплета (K2): fr=3&fra=dws&frf=3:1,2;5:1,2&fd=pereplet, что в переводе означает: fr (field relation) = 3 - услуга K_2 имеет связь с услугой K_3 fra (field relation action) = dws - действие по связи - скрыть, когда выбрано (dws - disabled when selected) frf (field relation field) = 3:1,2;5:1,2 - поля 3 и 5 услуги 2 связываются с полями 1 и 2 услуги 3 fd (field dictionary) = pereplet - услуга K_2 связывается со справкой в полиграфическом справочнике с кодом "pereplet" (раздел с кодом "pereplet";)
Вот так выкрутился. Полный скриншот настройки - приведен ниже. Там есть еще одна настройка fc (field check ) =int, что означает провести проверку поля на целое значение.
В общем появился повод серьезно задуматься над качественной и системной переработкой инструментария калькулятора, чтобы он оправдывал свое гордое название "универсальный".
Здравствуйте, я тоже не понял про "то, что в параметрах калькулятора значится как "Отображать поле количества расч. единиц? (Нет=1)". Как можно ввести количество услуг?
После прошедшей партнерской конференции я воспользовался сервисом: http://sitespeed.ru/ для проверки скорости загрузки своих сайтов на Битрикс и обратил внимание на то, что ведь если мы используем много компонентов, то на страницу грузится много CSS файлов (для каждого компонента свой), да и собственно js файлов Битрикс также грузит много.
CSS файлы компонентов как правило - небольшие и время их запроса превышает время их получения, а пока они не получены - страница не грузится. Отсюда предложение - собирать CSS файлы компонентов при выводе страницы в один общий. Грузится должно быстрее.
Кроме того CSS и JS файлы ядра Битрикса, выводимые в паблик можно сворачивать в min форму. Мы ведь их не читаем и не правим - зачем их выводить в развернутом виде? А ведь все тенденции к тому, что js обвязка будет только тяжелеть.
Также можно сворачивать в min форму и CSS и js компонентов при выводе. А еще лучше держать min формы постоянно и обновлять их только при обновлении соответствующих файлов компонентов.
Согласен с Максимом, что ручная минимизация путь к проблемам. Но польозователю я считаю нужно отдавать сжатые и обфусцированные копии перечисленных файлов. В настоящий момент битрикс их не минимизирует - только собирает в кучу и жмет gzip-ом. И вот тут уже я считаю было бы неплохо удалить лишние пробелы и все комментарии...
http://dev.1c-bitrix.ru/learning/cour...ON_ID=4469 - 3 файла js и 3 файла css. ок, если на сайт ходит 10,100,1000 человек в день. если число выше, начинает хотеться уменьшить количество файлов до 1css и 1js. ну и хотя бы gzip'нутых
1. Работа с большими списками данных в административной части (интеграция/импорт данных для свойств из инфоблоков) 2. Работа с большими списками в публичной части (нужна JS библиотека автонавигации с поддержкой multyselect-а) 3. Управление результатами расчета: сортировка, удаление и т.д. (Пока нашлось: http://tablesorter.com) 4. Автонумерация отправленных расчетов и сохранение их в инфоблок, на случай неотправки по причине перерасхода ресурсов на хостинге 5. Сложная логика условий при расчетах. 6. Пошаговое исполнение. 7. Возможность отображения списка товаров: общего, выбранных, свойств выбранных, в том числе с поддержкой изображений с функцией zoom. 8. Из 7 вытекает скрытопотенциальная необходимость интеграции с интернет-магазином. 9. Критически важна возможность широкой и глубокой настройки пользовательского интерфейса т.к. калькулятор именно призван создать возможность для принятия решения при достаточно большом объеме сложносвязанных (в общем случае) данных, или хотя-бы подобрать 3-5 вариантов для принятия окончательного решения после консультации.
Роман! Как вы себе представляете мой ответ на вопрос - "Брать не брать"? Зависит от вашей задачи. Поскольку, как я убедился, вопрос пользовательского интерфейса - важнейший, то если требуется оригинальный пользовательский интерфейс сильно отличный от стандартного, то вот в текущей реализации Pro придется достаточно много "попотеть" с JavaScript. Если с JS - есть опыт работы, это не страшно. А если JS с нуля или около нуля - тогда будет сложно.
Петров Роман, По совету Романа - подумал о "выводе". Вывод таков, что самое узковажное место будет определять строительство объектной модели. Если узковажное место - импорт больших списков - модель будет иметь крен в сторону удобства (даже на уровне имен) работы по импорту-экспорту, а если это место - возможность модификации пользовательского интерфейса - то объекты будут устроены удобно именно для этой модификации.
Сейчас методы класса модуля просто выполняют отображение традиционных input полей ввода (select, text, radio, textarea, checkbox, hidden) + 2-х нестандартных полей datetime (input+календарь битрикс) и table (простая двухколоночная таблица). Чтобы с помощью этого набора реализовать, например, калькулятор расчета окон, который может подразумевать отображение профилей, характеристик окон, замков и еще десятки параметров придется серьезно поработать с JavaScript, что очевидно приведет к росту количества "нестандартных" полей. Чтобы уметь управлять этим разннообразием, придется, по видимому по другому взглянуть на само понятие того, что такое "поле ввода".
Решил задачу многоуровневых ЧПУ при следующих ограничениях: 1. Если на конце "/" это URL раздела 2. Если на конце нет "/", то URL продукта 3. Если на одном уровне иерархии есть два раздела с одинаковым символьным кодом - возникает неоднозначность 4. Если два продукта имеют одинаковый символьный код - возникает неоднозначность
Далее в "Обработчике адресов" пишется условие вида:
где: products - папка на сайте в которой находится отображение многоуровневого каталога. CPU ($1) - собственно ЧПУ любого количества уровней. CPU_ELEMENT_CODE ($2) - код элемента, если он есть. $3 - передача управляющих параметров скрипта, чтобы, например, работала версия для печати заданная так: /products/section_1/section_2/product_code_1?print=Y
Файл sectiuon.php принимает на вход CPU как параметр и производит разбор строки с целью получить ID конечного раздела. Когда ID раздела получен - выводится его содержимое. Если же передан еще и CPU_ELEMENT_CODE - то выводим содержимое элемента, а содержимое раздела НЕ выводим. В общем, как использовать расшифрованное ЧПУ это уже вопрос конкретного проекта.
Более удобно получение последнего ID и построение навигационной цепочки - оформить функциями и добавить в init.php. Тогда результат их работы можно записать в глобальные переменные и вызывать везде где надо.
В связи с наведением порядка в корпоративных стандартах было решено подобрать к выбранной стандартом jQuery еще и стандартную библотеку всплывающих окон.
Я с лету предложил Highslide. Библотечка, «сказали» — хорошая. А что если поискать такую за которую поменьше платить? Я поискал полчаса — нашел подешевле FancyBox. Тут ужо меня спортивный интерес разобрал. Думаю — мир не без добрых людей, неужели же не найдется приличная, но бесплатная или хотя-бы условно бесплатная библиотека?
И нашлась. Называется prettyPhoto. Раз уж такая библиотека нашлась, решил я ее маленько усовершентсовать. А именно:
1. Сделать так, чтобы модальные окна можно было вызывать из модальных же окон. Тогда, если хочется, можно строить цепочки выполнения страниц на GET параметрах url модальных окон.
2. Сделать так, чтобы JavaScript код, загружаемый в модальное окно вместе с текстом страницы - исполнялся. Тогда такую страницу можно исполнять «в комплекте» не вынося специально JavaScript код в файл *.js, чтобы потом загружать его вторым запросом через jQuery.getScript(). Когда два запроса - всегда выше вероятность что-то потерять. Да и такую страницу можно, при желании отлаживать не в AJAX режиме. Тут преимущество в том, что вызовы JavaScript все внутри и панель Битрикса будет работать.
3. Сделать так, чтобы код загруженный в режиме AJAX , если он больше размера модального окна прятался «под скрол» В оригинальной реализации больший текст «вываливался» за окно.
Это было сделано и собственно касалось библиотеки и мало касалось Битрикса. Расширенный скрипт доступен по ссылке.
А вот специально для Битрикса был написан код, который позволял бы контент редактору с помощью визуальных средств редактирования картинки добавить для нее возможность увеличенного просмотра.
Стандартное решение представляло из себя код вида:
ul можно было заменить на div или span, но легче от этого не становилось. Эти контейнеры слабо управляются с помощью визуального редактора. Идеально было-бы эту возможность присваивать через стиль, который виден в списке стилей визуального редактора прямо изображению даже без ссылки. И это оказалось возможно т.к. библиотека имеет небольшое API.
Написал 3 функции для отображения картинки и изменении курсора при наведении, чтобы было понятно, что можно кликнуть
function zoomIMG_over(obj)
{ $("#"+obj.id).css("cursor", "pointer"); }
function zoomIMG_out(obj)
{ $("#"+obj.id).css("cursor", ""); }
И добавил их отслеживание в document
$(docu ment).ready(f unction(){
$(".zoom_img").hover(
f unction () { zoomIMG_over(this) },
f unction () { zoomIMG_out(this) }
);
$(".zoom_img").click(
f unction () { zoomIMG(this) }
);
});
Стиль zoom_img я прописал в стили шаблона сайта. Теперь (см. рис. 1) контент-редактор может в визуальном редакторе «повесить» на картинку функцию увеличения, просто выбрав стиль из списка стилей.
Ступил... hover состояния можно сделать в CSS всего одной строкой: img.zoom_img:hover { cursor:pointer; } Фнкции zoomIMG_over и zoomIMG_out в этом случае НЕ НУЖНЫ!
Не то чтобы юбилей, но где-то год и месяц назад, но без одного дня был сдан сайт туроператора Ориент, а в нем для отображения географического положения отелей было решено создать инфоблок «Геопривязка». По замыслу все отели снабжались координатами на карте Yandex и затем любой тур, ссылавшийся на данный отель, автоматически получал бы карту с местоположением отеля. На практике оказалось, что операторам сайта слишком долго было заполнять геопривязку, выходя для этого из инфоблока «Направления», где содержались туры в инфоблок «Геопривязка». Они хотели бы заполнять геопривязку для отеля, если возможно прямо из редактируемого тура. Для решения этой задачи был сделан специальный интерфейс на JavaScript на базе библиотеки jQuery см. рис. 1-5.
Pис. 1. При редактировании тура, для добавления отеля с геопривязкой оператор вызывает всплывающее окно с картографическим интерфейсом.
Pис. 2. Из списка регионов можно выбрать или найти с помощью поиска нужный регион, а затем выбрать отель, которой нужно добавить к туру.
Pис. 3. Если отель еще не имеет геопривязки предлагается провести быстрое позиционирование по региону.
Pис. 4. Затем можно уточнить поиск именем объекта. Если карта Yandex знает где это - соответствующая точка будет отображена. В случае неточности, оператор может вручную подвинуть точку до правильного положения на карте.
Pис. 5. Если при поиске объекта (отеля) найдено несколько совпадений - они публикуются списком справа от карты.
Pис. 6. Использование карты Yandex а не Google в данном случае обусловлено тем, что туроператор Ориент работает преимущественно в России, а Google не слишком хорошо знаком с ее курортными регионами. Однако, для международного позиционирования использование Google предпочтительнее.
Единственная «технологическая» неприятность — Битрикс ругался, что: «Внимание! Обнаружены лишние символы в служебном файле: .. ./bitrix/php_interface/map_menu.php»
Дело в том, что туда мне пришлось вписать загрузку JS библиотек и CSS стилей через <sc ript> и [*], чтобы функционал работал в админке, но Битриксу это не понравилось
Эпилог. Где-то месяца три они позаполняли, а потом «сломались». Яндекс, конечно, не знал местоположения отелей так, чтобы вообще не приходилось «шарить» по улицам населенного пункта, чтобы поставить маркер точно в дом отеля и операцию геопривязки сочли всё-же слишком продолжительной…
Это не баг, а фича Тут «продвигатели» IT отчасти сами виноваты. Никто их за язык не тянет сообщать аудитории, что вот эта «прога» или вот этот «девайс» решает проблемы просто, быстро и с небольшими затратами ресурсов. Эти ожидания переносятся на всю сферу IT. И соверешенно психологически объяснимо, что часто на программистов делают круглые глаза, когда они сообщают, что вот чтобы эту «шпуньку» прикрутить нужно два дня работы. Разве не написано в документации «каждой первой» CMS, что вот теперь вы «в принципе» можете обойтись без программиста? Вся эта «пропаганда» в целом создает именно те завышенные ожидания от IT в целом и от программистов в частности по производительности и заниженные ожидания по стоимости, которые затем и приводят к разочарованиям обоих сторон, особенно при переводе печатных каталогов с иллюстрациями «на сайт», когда первоночально «думалось», что этот каталог как-то сам в электронную форму перенесется или, в крайнем случае с помощью «розовой кнопки» и 2-3 дней работы. — 2-3 недели/месяца? — Да вы с ума сошли! XXI век на дворе! Сканеры? Распознавание текста? Верстка Excel таблицы для импорта? — Мне вводить? А вы на что? Перевод в электронную форму это сфера IT! Это ваша работа! — Да мне студент это все сделает за 15 тыс. и сайт и каталог (почему-то часто фигурирует именно эта магическая цифра в 15-шку) Собственно в общественном мнении существует, на мой взгляд перекос, относительно того, что все, что сделано на компьютере это ПРОСТО, потому, что компьютер рисует и программирует. Того же ожидают и от программистов. Хотя, возможно, это отношение изменится со сменой поколений.
Андрианов Андрей , это характерно для любой сферы. Просто в России любят, как мой коллега тут выразился недавно "Пенку с говна снимать". Вот таким образом и экономят...
Сейчас для того, чтобы информировать пользователей моего решения "Калькулятор услуг" (http://mp.1c-bitrix.ru/solutions/focu...alculator/) мне приходится это писать прямо в отзывы, что по смыслу с моей стороны - не правильно.
Предлагаю обратиться к Битриксу с просьбой интегрировать блоги разработчиков с отзывами на странице продукта в Marketplace - следующим образом:
1. Блог разработчика (если разработчик использует его для сопровождения продукта) выводится на странице модуля после закладки "Установка" с надписью "Блог разработчика" или "Поддержка в блоге".
2. Фамилии людей в отзывах являются ссылками по которым можно отправить личное сообщение с информированием о решении проблемы.
3. Пункт 2 можно сделать на множестве записей пользователей, выбрав их чекбоксами.
4. Сообщение, отправленное в п. 2-3, по желанию разработчика может появляться как комментарий к отзыву, причем, в случае множественной отправки, полный текст сообщения приводится только для самого свежего по дате отзыва, а в остальных дается только ссылка на этот текст.
5. Для блогов "завести" разделы, чтобы в случае поддержки нескольких модулей - каждая поддержка осуществлялась в своей ветке.
Рекомендуем оставить Вам оставить вашу идею на нашем сайте Идей http://idea.1c-bitrix.ru/ Если Идея получит поддержку других пользователей, то она будет полностью или частично внедрена. --- конец цитаты ---
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».