Как визуально разделить свойства товара?
Как получить значение пользовательского свойства типа «список» в Битрикс
Доработка свойства списки или введение типа bool
Вы используете устаревший браузер. Пожалуйста обновите свой браузер чтобы улучшить взаимодействие с сайтом. Это снижение затрат на работу с клиентами, рост продаж и автоматизация процессов. Мы можем решить все задачи веб-интеграции собственными силами. Оставьте заявку на обсуждение интеграционного проекта. Разработка и создание сайтов в Москве. Написать нам Проверка домена. Веб-интеграция Портфолио Отзывы 1С-Битрикс Блог Цены Мы Вакансии Контакты In English. Разработка Маркетинг Поддержка CRM Битрикс 24 Брендинг. Главная Блог Проекты Битрикс: Устройство и технические свойства платформы Все Битрикс24 Брендинг Интернет-маркетинг Проекты Техподдержка Жизнь. Наша специализация — сложная разработка на 1С-Битрикс Компания 1С-Битрикс и ее продукты CMS и корпоративный портал вызывают много вопросов и обсуждений как в интернете, так и в жизни. Выходят новые версии, идут семинары, компания занимается активной маркетинговой деятельностью, работает партнерская сеть, а вопросов со стороны профессионального сообщества меньше не становится. Эта статья — попытка разобраться в частых вопросах и проблемах и сформировать общее понимание ситуации. Немного предыстории и авторской позиции. До года мы развивали свою систему, пробовали другие коробочные системы. Больше сайтов были сделаны нами НЕ на Битриксе. Так что опыт работы на других системах есть и солидный. Я понимаю и что такое свой код, и что такое разработка на опенсорсе, и что такое другие коробочные системы. Теперь работаем на Битриксе, и в целом — довольны. Не хочу сейчас о личных впечатлениях, скажу главное: Хочу получить обратную связь и дополнить собственное понимание. В основном буду говорить не о маркетинге и лозунгах, а о прикладной стороне системы, как я ее понимаю. Как она построена, как делать на ней проекты, как чувствуют себя пользователи, как работают партнеры. Как система развивается сама и как она готова к развитию со стороны. Обсуждая технологии, будем говорить не об абстрактной красоте кода и применении всех возможных нанотехнологий, а только о технических аспектах, создающих бизнес-преимущества. Задача, на мой взгляд, грандиозная, так что решена в меру моих скромных возможностей. Устройство и технические свойства платформы 1С-Битрикс. Он сделан на древнем как помет мамонта PHP 4. Это не круто, пещерный код! Ответ на каждый вопрос буду разбивать на три куска: Для бизнеса, для клиента, для внедрения версия php это один из последних технических вопросов. Думаю, менее важный, чем версия серверной ОС в офисе или тип принтеров: МФУ или классические лазерные работяги. Для программиста, натягивающего дизайн или делающего компоненты, это тоже в общем мелочь. Ну сохранено много чего для совместимости, и бог с этим. Для кого это важно? В чем вообще вопрос? В том, что обеспечение совместимости с версией 4, выпущенной страшно сказать в году, требует соблюдения морально устаревших и технически избыточных конструкций и запрещает использование многого важного, удобного и в целом — правильного. Теперь все пишется без поддержки PHP4. Как я понимаю, есть планы по наведению порядка в старом коде. Был ли смысл работать с поддержкой версии 4, ведь когда Битрикс всерьез выходил на рынок, уже была и набирала популярность версия 5. Думаю, что система так долго сохраняла эту совместимость потому, что хостинговые компании переходили на php5 относительно медленно и было важно не создавать препятствий для внедрений. Кроме того -- совместимость новых версий Битрикса со всем, что было написано ранее, поддерживается разработчиками постоянно. Для партнеров, поддерживающих разные проекты, уверенность в такой совместимости является на мой взгляд одной из самых важных положительных сторон. Если надо с ним работать, кастомизировать и развивать, придется возиться. Если вас такой код бесит -- придется сжать зубы. Где разделение логики и представления тут же каша из php, HTML, css, js и SQL! Принято считать что в любом программном продукте нужно разделять логику и данные, представления и вычисления, код на разных языках и тому подобные сущности. Честно - звучит красиво, но как это делать -- неясно. Начнем с того, зачем это делается. Я вижу несколько причин: Часто хотят разделить по критерию языка программирования. Давайте возьмем любой веб-продукт. Там 4 языка будет точно. И переход между языками совершенно не означает смены роли соответствующего куска кода. Часто куски, на которые вы порежете, будут использоваться ровно 1 раз. Какую пользу принесет такое разделение? Представьте себе полный список фрагментов HTML или SQL-кода, которые есть в проекте. Как их складировать, как именовать, как вызывать? Конечно, критерий разделения должен быть другим. Разделять логику, данные, языки, сущности на независимо и удобно редактируемые элементы нужно по критерию частоты правки. Нужно смотреть, кто и в каких обстоятельствах эту правку будет выполнять. Соответственно и сами средства редактирования нужно создавать именно с учетом этого критерия. В вебе и программировании вообще есть популярный миф, что логику, данные и представления легко и очевидно можно отделить друг от друга. Что решение этой задачи однозначно, и кто делает не так, как кажется говорящему -- ленивый дурак. Если немного подумать, становится очевидно что логика, данные и представления легко переходят между собой в зависимости от того, с какого уровня абстракции вы смотрите на задачу. Например, html-код шаблона для разработчика сайта это безусловно представление, для браузера это код, а для ядра CMS это данные. Когда задается вопрос про кашу, сразу понятно что смотрел человек. Человек открыл код шаблона, увидел цикл с HTML вперемешку с php и решил, что Битрикс плохо. Так вот, про кашу в шаблоне. Это шаблон, он для вывода. Все данные уже собраны, запросы отработали, понятно что и куда мы выводим, даже отлов угроз уже прошел. Это последнее звено в пищевой цепочке кода и данных. Тут логика вывода действительно смешана с оформлением, и это правильно. Это не нравится фанатикам, фанатики в своих CMS делают иначе: Все это обрабатывается через eval и практически не поддается отладке Зато очень красиво. То, как сделано в Битриксе, поддается любой отладке и тратит минимум ресурсов. То, что видно в коде шаблона, является представлением. Это не бизнес-логика, это логика вывода и она в Битриксе выведена в отдельную сущность - код шаблона. Код, реализующий бизнес-логику, запрашивающий и обрабатывающий данные, находится в других местах -- компонентах и модулях. О них мы поговорим дальше. Я убежден, что логика, представления и данные в Битриксе разделены самым разумным для задач CMS образом. Во многих случаях программисты и не хотят об этом думать, у них другой подход. Поскольку далеко не все видят разницу между обращением на языке php к извлеченным данным для целей вывода и тяжелыми запросами к бд или вызовам функций API, то в шаблоне можно писать любой php-код. Можно прямое, даже не API-шное обращение к базе написать. Можно написать десяток строк на API и решить задачу. Битрикс этим очень развращает разработчика. Не запрещено писать бизнес- логику в шаблонах и HTML в компонентах. Прекрасно помню как я сам, не разобравшись особо в компоненте и поленившись его кастомизировать, дописал прямо в index. Потом переделали, но впечатление яркое осталось. И очень часто это впечатление от сделанного с применением Битрикса безобразия переносится на сам Битрикс. В собственном коде и по идеологии Битрикса задача решена нормально, а вот привитием хороших манер и практик Битрикс почти не занимается. Дает слишком много свободы. Style guides, Code conventions, Code review - все на совести разработчика. Понятно, что обычно и разработчик этим не занимается. Поскольку веб-представления бывают сложны не только по виду, не только по структуре текста, но и по логике вывода скажем, колоночный вывод, различные шаблоны вывода в зависимости от уровня доступа пользователя , то язык шаблонизатора, особенно функционального, вполне сопоставим с языком разметки или даже программирования. При этом язык php уже сам является шаблонизатором, так как умеет оставлять без изменения те части текста, которые находятся вне его маркеров. Как правило, нет никакого прикладного смысла в том, что на языке-шаблонизаторе писать поверх еще 1 шаблонизатор. Польза от этого сомнительная только одна: Хорошо это или плохо -- однозначно сказать сложно. Я вижу больше плюсов. Хотя бы то, что его не надо учить. В Битриксе есть что учить и без шаблонизатора. Разумеется, все что можно вообще сделать на языке программирования, можно сделать в шаблоне, ведь это просто php. Ничто не мешает написать прямо в тексте шаблона вызов другого компонента, прямое или API-шное обращение к БД, или любую другую ерунду, не рекомендованную по идеологии в этом месте. Битрикс это не контролирует. Почему не применяется современный, технологичный, стандартизованный подход к шаблонизации на основе xslt-преобразований данных в представления? Суть идеи XSLT проста и красива. Код системы бизнес-логика реализует все функции и готовит данные в формате xml. В xml никакого оформления нет, одни данные и разметка, отражающая их структуру. Затем с помощью xslt-преобразований делается представление. В xslt-преобразованиях нет бизнес-логики. Там нельзя написать запрос к БД. В Битриксе XSLT нет. XSLT надо учить, его производительность и гибкость не всеми подтверждаются. Есть мнение, что только с таким PHP- шаблонизатором можно быстро знакомиться с системой и начинать поддержку. Есть множество экспертных мнений, что PHP-шаблоны оправдывают себя экономически и производственно, в отличие от XSLT, Smarty и прочего. Независимо от того, родился плохой или хороший код шаблона, его все равно не будут редактировать. Технология XSLT менее подвержена этому недостатку. Есть мнение, что только с XLST-шаблонизатором можно качественно и долго развивать проекты, повышая эффективность сотрудников и зарабатывая деньги. Есть множество экспертных мнений, что XSLT-шаблоны оправдывают себя экономически и производственно, в отличие от PHP, Smarty и прочего. Есть масса хороших специалистов, которые верят в мощь xslt. Почему бы Битриксу не включить его поддержку? Если бизнес Битрикса в создании новых возможностей для партнеров и есть те, кто скажет, что хочет развивать свои проекты на xslt — почему нет? Я не готов судить о том, насколько это сложно и революционно, но в минусы запишу. Вопрос XSLT дискуссионный, но я не считаю его слишком важным. Действительно, на первый взгляд выглядит странно. Но только на первый. Точно так же поступают для хранения данных редактируемой структуры 1С, invision power board, wordpress и тысячи других веб- и не-веб-приложений. Не знаю как это называется по-умному, я привык называть это решение "база данных в базе данных". Подход заключается в том, что в физической структуре БД создаются 4 таблицы, не меняющиеся при изменении структуры данных: Честно, не понимаю что мешает получать доступ к данным с применением родного для них API. Что за кайф разбираться в хитросплетениях чужой структуры данных при наличии развитого API? Тормоза - вопрос важный, но далеко не однозначный. Действительно, при хранении всех свойств в одной таблице извлечение значений, например 20 свойств, приведет к 20 джоинам. Сортировки и поиски тоже не добавят красоты запросу. Если же есть сложная логика вроде: Штатно из них можно опять сделать 7 ну 10 с учетом системных таблиц , но этим надо заниматься. Тяжелые длинные непонятные запросы к базе данных примеров масса на различных форумах и в любых проектах Суть Код Битрикса порождает очень большие запросы. Давайте попробуем разобраться в этой очень сложной теме, которая включает вопросы узкотехнологические, вроде производительности конкретных выборок, вопросы удобного применения технологий работы с БД в больших развиваемых проектах на растущей CMS, вопросы стоимости владения и поддержки. Откуда это все вообще берется? Есть инфоблоки, где быстро и комфортно создается структура данных. Есть стандартные компоненты, реализующие наиболее распространенные вещи. Есть API, позволяющее отправлять достаточно произвольные запросы. Прямой доступ к БД неудобен и вообще говоря, противопоказан, так как физическая структура БД может измениться, а работа даже самого древнего API гарантирована. Вы применяете компоненты, пишете свои, активно пользуетесь API, в итоге ваша достаточно высокоуровневая логика выборки превращается в запрос. Генератор запроса, несмотря на свою сложность, по сути выполняет довольно тупую работу по переводу логики, изложенной на высоком уровне, в обращения к конкретным полям конкретных таблиц по условиям. Запрос получается совершенно неудробочитаемым. Со вставками и удалениями все в общем так же. Если есть желание заняться их профилировкой и отладкой, вы фактически ограничены теми не слишком богатыми средствами изменения запроса, которые предлагает Битрикс. В мощных СУБД есть умные и очень эффективные оптимизаторы запросов, которые готовы из говна сделать конфетку а совсем плохие запросы такие СУБД даже не дают исполнять. Подавляющее большинство установок Битрикса работают на MySQL, чей оптимизатор достаточно слаб и для таких задач подходит мало. Разумно было бы разработать свой или интегрировать внешний, но насколько я понимаю, технологически эта задача очень сложна и решать ее всерьез Битрикс не готов. В итоге мы имеем большие запросы, ограниченные средства их изменения с сохранением логики, и механизмы кеширования поверх всего этого. Запросы не надо писать руками. Создание сайта на Битриксе обычно предусматривает визуальную настройку готовых компонентов, создании структуры сайта и натягивание дизайна. Не в каждом проекте приходится кастомизировать компоненты, но даже эта работа не заставляет писать запросы. Есть API, до физической структур дела нет. Запросы велики, нелегко их менять, иногда все тупит. Обертки над запросами решают задачу защиты от атак или глупостей. Это включаемый галочкой в админке режим работы инфоблока, когда его поля переносятся в отдельную таблицу. Как правило -- здорово помогает при большом числе записей и опасности блокировок. Джоины, появившиеся для извлечения отдельных свойств, сливаются в один. Возьмите из вашего тяжелого проекта тяжелый запрос и сделайте explain в консоли. Вы удивитесь как хорошо он покрыт индексами и как мало там будет циклических переборов записей. Если вы это сделали, что вам горя с того, что иногда будут вызываться тяжелые на десятые доли секунды запросы? Инфоблоки база в базе дают гибкость в ущерб производительности. Нужна производительность -- делайте таблицами, API для этого есть. Купить хороший сервер стоит как месяца работы хорошего специалиста. Арендовать — как 2 недели. И бизнесу это нравится. Есть мнение что другие свойства Битрикса экономят куда больше денег. Большому кораблю -- нормальную СУБД. Вывод по первой части. Битрикс — специфическая система, удивительная на первый взгляд. Есть мнения что она ужасна и наполнена неправильными решениями, есть мнения что она проста и понятна, потому и работает. Мое мнение в том, что этот набор простых и гибких решений хорошо работает. Он работает на клиента, он работает на бизнес студии, он работает на перспективу. Несмотря на то что технические решения далеко не однозначны, я не вижу кому от них плохо. Возможно, вы привыкли к другому. Система реализует особую идеологию, возможно не самую красивую, зато исключительно эффективную. Если оно отличается от того, что вам близко и понятно, и вы недовольны, спросите себя, как эта система развивается 10 лет? Как сохранена полная обратная совместимость до самых ранних версий? Как удается запускать 2 релиза в год? Вы знаете другую такую компанию? Мне кажется, тут есть о чем подумать. Идеология и архитектура платформы 1с-Битрикс. ООП, ORM, Паттерны проектирования, MVC Часть 3: Взгляд сисадмина, разработчика, директора Спасибо за внимание. Ребята, вы мне нравитесь. Давайте обсудим первый шаг.
Преступная халатность статья
Ижевск новости дтп
Значение нормативных актов
Как приготовить плов пошаговое фото
Final dance перевод
Схема движения маршрутки 28 в ульяновске