Обзор бекенда SIMAI Framework

ruticker 04.03.2025 23:47:51

Текст распознан YouScriptor с канала Компания «Симай»

распознано с видео на ютубе сервисом YouScriptor.com, читайте дальше по ссылке Обзор бекенда SIMAI Framework

Вот так получше видно. Да, да, но здесь расскажу, ну и заодно и к другим придет. В общем, почему мы используем свой фреймворк? Потому что Битрикс, как я говорил, уже не развивается много лет в плане управления сайтом. Мы, соответственно, разрабатываем технологию, которая позволяет, скажем, достигнуть определенных целей. Скажем, той целью, которую хочется достигнуть, является искусственный интеллект для управления сайтом с помощью искусственного интеллекта. Для этого у нас была задача разбить весь сайт на блоки, вплоть до отдельных вещей, и создать систему сборки данных, состоящую из фронтенда и бэкенда. Frontend, соответственно, на сайте либо Free, максимальная версия — старая версия, либо SF4, Saw 4. Самая последняя версия уже не 4.8.1, больше это все время подправляем. Бэкенд состоит из следующих вещей: он состоит из двух папок. Ну, точнее, раз, два, три, четыре. Сейчас перечислю все вещи. Так, самая важная папка фреймворка — это папка **Simai**. Папка **Simai** находится всегда в корне сайта. Ну вот, прямо в корне, в корне. То есть, если есть сайты на папках, то есть, к примеру, это папка сайта, а это корень сервера. Как это называется? Очень в корневой папке находится папка **Simai**. Она содержит в себе вот следующие подпапки. Одним из них являются те формы, которые для администрирования используются. Они сюда выкладываются для того, чтобы к ним был доступ. Так они находятся в модуле. То есть, если в любую из них зайти, то будет ссылочка на файл, который сам модуль находится. Ну и, соответственно, здесь админские все формы, которые есть во фреймворке. **Post** — это проверка почты, про почту **SMTP** настройки. **Property** — не помню, тоже не помню, в смысле, этот принцип неважно. Вот папка **Asset** — здесь все, что используется, и скриптов, и стилей. У нас есть целая API по подключению всех этих скриптов и стилей. Сюда выкладываются папка первая, папка содержит, грубо говоря, папку какого-то ресурса, а в ней могут быть подпапки по версии. То есть, фреймворк поддерживает одновременную работу с несколькими версиями. Есть конфигурационный файл, в котором описывается, какая версия подключается. Этот конфигурационный файл находится в папке **Config**. Вот здесь вот, то есть, если посмотреть, **AssetConfig** как раз описывает, какие стили и скрипты подключаются. То есть, вот такой вот массив есть в нем. Соответственно, мы потом сделаем конфигуратор, который позволит добавлять и убавлять. Пока все это в виде конфигов сделали, но принцип очень простой. То есть, что мы подключаем здесь по умолчанию? Дефолт. То есть, по умолчанию подключит версию 4, но папка **Default** — это то, что подключается, если не указано в параметрах API подключения, какую версию подключать. Соответственно, берет дефолт. Вот здесь параметры, то есть, какая версия, какая подпапка, соответственно, какие подключаются файлы, и эти файлы являются либо стилями, либо скриптами. Вот тип скриптов **Post**. Итак, соответственно, мы проходимся по всем конфигурационным файлам. В самом конфиге описаны все вот эти ресурсы, которые используются для подключения ассетов. Но из этого в проекте может использоваться не все, что именно используется, описано в папке, но в самом модуле. То есть, например, у нас подключается сейчас модуль **Simai**. Ну, например, **Simai Free**. Если здесь посмотреть, **In Cloud** — то подключается файл, видишь, автоматически подключаем. А это классы? Нет, это не то. Это классы, которые подключаются при регистрации модуля. Сейчас посмотрю решение. Вот самое со **SF4**. Не, я просто не помню, там разные версии по-разному делались. Мы перенесли, и сейчас в последней версии мы перенесли большую часть самого модуля фреймворка. Эта версия до объединения модуля фреймворка с модулем решения. Вот видишь, здесь вот... Погоди, что не вижу. Так, да, я посмотрю в другом месте. Встреч не помню, куда это мы внесли. Так, секундочку. Да, да, работа с... То есть, мы подключаем. Вот здесь, видишь, используйте **Simai Mind**. Это подключается класс по работе с этими ресурсами. И дальше, в принципе, просто указываем **Asset** год **Instant Slots**, какое нам нужно подгрузить. Если мы не указываем версию, то здесь, по идее, можно указать запятую и версию, то подгружает именно дефолт. Если указываем, и в конфиге прописано эта версия, то он может погрузить определенную версию. То есть, тебе нужно, например, там, не знаю, **jQuery** версии 2, а не 3, то можно в конфиге прописать версию 2 и 3, и здесь погрузить вторую версию. Ну вот так вот работают. Удобно в плане того, что чем удобно? Не нужно каждый раз вспоминать, какие тебе нужны скрипты, стили. Но для подключения ты можешь эту строку использовать несколько раз, но при этом он определяет, подгрузил он уже эти стили или не подгрузил. Если подгрузил второй раз, он уже не будет подгружать. То есть, мы решаем несколько проблем. С одной стороны, нам не нужно запоминать, какие стили, скрипты подгружать нужно и какой версии. То есть, там всегда актуальная версия подгружает последние, и нам не нужно помнить, подгружали мы или не подгружали. То есть, основное мы устанавливаем, и даже если мы повторимся, ничего страшного нет. То есть, во второй раз подгружать не будет. Ну и также здесь используется механизм объединения стилей, скриптов Битрикса. Тайсон, на самом деле, это настройка над Битриксом, с методами по работе с данными. То есть, она полностью как бы сделана подвести под подключение. Просто она, как искать удобства, создаёт. Вот и в результате можно быстро определить, что подключить, что не подключить. Но смысл и это уже использовать. Вот дальше с ассетами понятно, да? То есть, папку **Asset** засовываем сами ресурсы, причем три уровня. Первое — это вот сама папка, здесь уже версии, а версии уже сами папки и файлы, которые используют. А в конфиге, если добавляется, это все должно быть прописано, а потом уже через API мы подключаем то, что есть в конфиге. Вот папка **Config** используется для конфигурационных файлов. Вот **Config** — это такой же, как сказать, конфигурационный файл, который позволяет подключать скрипты. Он содержит в себе название скриптов и какая строка подключается при этом. Соответственно, когда ты выбираешь через API, какой скрипт использовать, то автоматически подтягивается нужный **script tag**. Где это интересно? **Font Body Property Guide Instance**. Вот видишь, используется. То есть, она определяет из настроек сайта, какой шрифт использовать. И точно также **Font Get Instant Slot** указывали, какие загружать. Механизм абсолютно везде одинаковый, поэтому с **Sape** нашим достаточно легко работать. Шрифт указывается. Вот если посмотреть сайт, здесь есть оформления сайта, шрифты. Один ваш **Rift**, и ты можешь выбрать, какой шрифт используется для текста. Но до сих пор это все как разберется из конфига. Но точнее, это из конфига внесено, да, автоматически берет из конфига, вроде формирует список, и здесь, какой шрифт для заголовков, он, соответственно, берет вот эти параметры и подгружает их через метод в виде стиля. То есть, определяет, что подгружать. Вот с этим тоже понятно, да? Вроде **Regtime Flag**. Вот фреймворк **Config** — это, скажем, редко используемые параметры самого фреймворка. Ну, скажем так, системные настройки. Вот здесь какие-то параметры мы задаем, но они редко. Это типа у Битрикса конфигурационный файл, то есть он конфигурирует весь фреймворк. Здесь задается, но различные значения. Ну и, соответственно, потом используются **SMTP** настройки. **Property** — это наш модуль универсальные свойства, называются. Суть такая, что мы разработали технологию, которая позволяет отделять отображение свойств от самих данных. То есть, ну вот, например, вот это все построено на универсальных свойствах. Мы сюда задаем просто тип свойства, грубо говоря, интерфейс по работе с свойствами строится с помощью этого модуля. Мы ему задаем, какие свойства используются и типа этих свойств. Он, соответственно, выстраивает весь интерфейс, исходя из этих свойств. И дальше, когда нам нужно, мы обратно забираем значение. Ну, то есть, вот здесь какие-то значения есть, мы значение забираем, эти значения уже сохраняем. То есть, модуль универсальные свойства нужен для построения интерфейсов по работе с любыми свойствами. То есть, мы не можем на входе иметь массив данных откуда угодно, выстроить интерфейс по работе с этими данными, потом забрать значения и сохранить это значение куда угодно. Понимаешь? Я не настраивал там флакончик, и это, допустим, там, кроме 3, можно было через сибирский носи маску пора добавлять. Ты нажимаешь и добавляешь до значения. Столкнулся, причем вот это все, это как бы шаблоны отображения. Есть несколько, идут два варианта шаблона. У нас сейчас есть шаблон дефолт, он используется. Но в таких интерфейсах типа Битрикса внутри он очень приближенный. Я сейчас не помню, где этот файлик находится, но в самого модуля сейчас посмотрю. То есть, здесь вот есть модуль **Simai Property**. Вот он, наверное, админ. Меня вот тест до **SF Property** тест. Да, я попробую так сделать. Попробуем вот так вот. Да, вот здесь едешь разные типы данных. Это вот системные, то есть так выглядят системные поля. Но где шаблон дефолт? То есть, можно выстраивать интерфейсы прямо внутри админки Битрикса с различными типами. Выглядит это как методы, представляешь? Метод, он сам рисует тебе интерфейс. Но, в смысле, дальше, соответственно, ты можешь забрать в результате данные. Здесь вот уже используется шаблон из **SF4**. Шаблон **SF4** заточен уже под именно под фронтенд часть, но построена на базе **SF4**. То есть, вот это, например, список, он может быть в таком виде. Список может быть, например, ну, то есть одни и те же данные могут быть в разном виде. Список может быть выпадающий, может быть, например, вот такой. То есть, это тоже, например, какой-то список. Он, то есть, радио бокс такой вот, такой вот может быть в виде кнопок. Радио бокс может быть, например, вот такую вещь или этом. То есть, мы сделали разные отображения для одних и тех же данных. В результате получается, что налито можно выстраивать интерфейсы, нужно получать данные, работать. Ну, очень удобная штука. Вот так, дальше папочка с **Property** понятно, да? Здесь как раз хранятся именно сами шаблоны. То есть, вот, например, **Checkbox**. Здесь компоненты по работе. Вот, то есть, сказать **Property** посмотреть. То есть, ты можешь, по идее, используя эти же шаблоны, свой шаблон создать. То есть, вот есть **Default**, есть, например, **SF4**. Из **SF4** **Image**. **SF4 Switch**. Вот этот префикс **SF4** позволяет понять, что он как бы строится именно на базе **SF4**. То есть, это один и тот же **Checkbox**, только он может быть у разных ипостасей. Может быть просто как **Checkbox**, может быть в виде картинок, может быть в виде переключателей. Вот и так по всем. То есть, у нас вот есть, например, по цветам, по датам. Эта сущность файл, наверное, самый большой — это список какой-нибудь, лист или радио бокс и счетчик. Но получается, **Checkbox** от, и у каждого из них есть параметры. По-моему, документации это все описано где-то. Может быть, здесь на я немного почитал. Дайте пара геймерам доводка верхами свойства. Здесь вот написано, да, есть переключатель цвет. Но здесь надо проверить, почему нет. Если где-то видишь какие-то проблемы, постарайся разобраться и подправить, потому что документации у нас создается, скажем так, дружненько, и возможно, что где-то постоянно что-то отваливается. Но не должна быть такова работа. Нашел там, как добычу редактировать у Ренаты. Уточняя, везде по-разному. То есть, вот это у нас тренируется. Точно также, как то решение правишь. То есть, у нас есть этот по четвертому фреймворку, отдельно образ, который тебе давал. В этом образе, соответственно, есть уже, но на Google Open Server, это **MySQL 4 Local**, и можно подгрузить. И там вот то же самое, только в локальной версии можно подправлять и отгружать. Она здесь будет обновляться. Шар. Вот так с этими свойствами понятно, да? То есть, вот **Property** — это фактически компоненты, шаблоны по работе именно с этими свойствами. **Wizard** — это еще одна наша уникальная разработка. Это универсальный мастер, который позволяет пошагово выполнять действия. У него отдельно документация, как бы частично присутствует. Я скину в виде файла, по-моему, я не выкладываю никуда. Дании укладываю. Суть такая, что есть действие, но каждое действие может выполнить какое-то что-то такое. Сейчас посмотрю, может быть, у меня есть описание. То есть, от вас нет, она присутствует. А, она нет. Так, пока грузится. Очень принцип какой есть конфигурационный массив, когда выполняется вот мастер, например, тестовой и лесов 4. То есть, эта папка обслуживающая мастер. Здесь индексный файл и самое главное — тут профиль **Wizard Config**. **Wizard Config** — то он делает, что он описывает какие-то параметры визарда. То есть, мастер на лету собирается. Он вообще как бы мне такого, что модель на мастер прописывая, он на лету собирается выполнять действие с помощью этого конфигурационного файла. Здесь пошли действия. У каждого действия, ну, есть определенное название, которое вводится. Есть входящий массив, он может брать, например, откуда-то данные. Но фактически эти данные сохраняются, скажем так, в сессии. Он может, например, выполнить одно действие, получить какие-то данные, ну, например, список инфоблоков и загрузить в сессию. Дальше второй, например, этот 7 может перечень инфоблоков, например, упаковать в архивы. На второе действие ты ему указываешь, откуда он берет данные, и, соответственно, источник данных. И он, ну, пакует их. То есть, здесь вот, например, действий у нас используется код сайт, чего сын стал. Мы указываем, куда он записывает эти данные. Он записывает их в параметр сайт конфиг. Дорогих нет, он выполняется, выбирается. Дальше пошел распаковка файлов. То есть, соответственно, мы используем действие **File Andi**. Это массив, куда он выгрузит, ну, как бы информацию о том, что нас паковал. Дальше параметр, какие, ну, какие файлы и там, что нам нужно запаковать. Дальше пошел, например, там добавление чипу. Здесь, соответственно, какие параметры, откуда чего берется. Ну и откуда данные берем сайт конфиг. Ну, то есть, вот и таким образом получается, что отдельные блоки выполняют маленькую часть работы и взаимосвязаны через вот этот конфигурационный файл и, скажем, хранение данных, ну, в этой сессии взаимодействуют между собой. То есть, сам вот этот конфигурационный файл описывает методику взаимодействия отдельных этих частей между собой, кто что делает, откуда данные берет, расами действия при этом неизменно. Вот тоже блочная система. То есть, мастер на лету собирается. У нас есть большое количество уже описано, как бы действия, которые выполняют разные вещи. Ну и по сути сейчас упаковка. То есть, вот этот мастер, например, я не знаю, мастер установки, скорее всего, еще есть мастер упаковки. То есть, принцип такой, что все в топ действия, которые требуется автоматизировать, мы закидываем в мастера. Мастера делают автоматически. Вот с этим понятно, да? Ну, более потом, как этому придешь, скажешь мне, что тебе нужны, тебе скину документацию. Сейчас тебе не хочу грузить, там большая дыра. Имитация есть интересна. Мол, кастрик вместе работает действие. Можешь просить его, он тебе покажет. Например, я просто не знаю, где это. Ну, здесь я боюсь запускать, но сломаешь. Так вот, какой не тестовый полигон можно будет поднять и запустить. Вот когда больше решение устанавливают, месяцев 4 установка, это мастер как раз запускается. Вот, ну то, что эти обрезал, это мастер установки. Дальше в папку. То есть, в папке сайта это необязательно. Папку может быть, это тоже может быть корень. Если, ну, сайт находится в корне, если **of popki ru** находится, то это будет в папке **ru**. Есть папка **Simai Data**. Это **Simai Data** — это данные для конкретного сайта. Ну, то есть, Q1 на сайт может быть в режиме много сайтов. Асти, ну, например, может быть русская, английская, там, японская версия, и у каждой в отдельной своей папке будет вот эта папка. Она содержит данные конкретно для данного сайта. Ну, то есть, вот для него эта папочка содержит следующие. То есть, админ — это, но те же конфигурационные различные эти элементы. То есть, конфигурация, настройки, демонстрационная настройки, настройка страницы, настройка раздела, настройка сайта — это то, что здесь. То есть, стране развелся демонстрационные настройки. Вот это вот все конфиги и блока выми делает. Едет, едет, едет. Это, по-моему, какие-то тоже связаны с этими вещами. То есть, вот здесь вот не помню, где то что-то редактировать. Ну, просто не помню. Вот используется. То есть, этот файл для редактирования конфиге — это конфигурационные файлы для сайта. Уже **Dima Config** — это демонстрационная конфиге. Я то, что показывается. Ну, тоже механизм абсолютно везде одинаковый, что сильно упрощает работу. Это код параметра, идет название параметра, тип параметра и, соответственно, дефолтное значение. Работает очень просто. То есть, когда ты нажимаешь, например, настройки страницы, запускается один компонент, который считывает именно настройки данной страницы, использует конфигурационный файл раздела. Но здесь конкретно у нас сайта загружает исходные данные через компонент, пропускает, выстраивает полностью вот этот весь интерфейс. Когда нажимаешь сохранить, он, соответственно, берет полученные данные и сохраняет настройки сайта. Вот это позволяет все вот эти вещи налит устроить. То есть, и не нужно лазить, как в обычных, это в коде искать эти параметры и значения. Ты просто в конфигурационном файле меняешь, у тебя на лету все выстраивается. Также очень просто с точки зрения сохранения данных. То есть, например, настройки сайта все сохраняются в конфиге. Вот здесь вот видны, если что-то не так, можно всегда зайти, посмотреть сам искать исходный конфликт. Но, в смысле, что здесь сохранена. Принцип здесь один и тот же. То есть, код параметра и его значение. Все вот эти параметры при загрузке сайта **SFC 4** подгружаются. Все **SE** доступно через параметры считывания кодов. То есть, ты можешь запросить код параметра, и, соответственно, тебе выдаст его значение. Ну, например, это вот идет через **Property** **USSI** **Mai-Mai** конфигурации **Property**, но дает используется. И, соответственно, вот **Property Guide Instance** запрашивает **SFC** одеру. Это текущий сайт. Ну, то есть, он через константу берет текущий сайт, это значение параметра. То есть, он запрашивает настройки сайта, и, соответственно, он выдает значение по данному коду. Причем нюанс в чем заключается? Здесь есть и архи я свойств. То есть, сначала грузится, значит, параметры сайта, потом сверху грузится параметры раздела. И если они есть, пересекаются, то перезаписываю параметры сайта. Ну, то есть, параметры раздела более приоритетны, чем над параметрами сайта. Потом грузится параметры страницы, и они более приоритетные, чем параметры раздела. Потом грузится, но если используется **Dima** данные, и они более приоритетны, чем параметры страницы. Ну, то есть, ты можешь здесь указать параметры, и, соответственно, сайт поменяется на лету. Причем это будет сделано для каждого пользователя персонально. Все это сохраняется в сессии. Соответственно, когда сайт загружается, он и сессия подтягивает весит массив параметров. То есть, сайт не разбирается, где что. Просто вот при за счет приоритетности так выигрывать. Также есть параметры, которые как бы уже параметр пользователя называются. Вот эти темы параметр, параметры пользователя относятся. Или вот эти вот параметры. То есть, ты, когда вы здесь указываешь, видишь, здесь идет **Property Code** равно почти **View**. **Property Value** равно **List**. Мы через **URL** можем заменять через **URL**. Может заменять значение некоторых параметров. И за счет этого, когда ты нажимаешь кнопку, происходит, но как бы установка параметров. И дальше этот параметр уже, ну, сохраняется, и ты его можешь использовать. То есть, когда пользователь следующий раз зайдет на эту страницу, то есть, например, зашел вот сюда, зашел сотрудники, она, видишь, уже погрузилась, хотя здесь этот параметр не установлен. То есть, этот параметр записался всей сервиса от этого **Mirza** ватель уже с ним работает. Если мы нажмем другую кнопку, опять же запускается такая строка, что **Property Core** такой. Это когда система считывает эти значения, на перезаписывает параметры. И, соответственно, мы можем с помощью кнопок или каких-то вещей полностью менять значение любых параметров. Интерфейс на лету перестраивается для конкретного пользователя. То есть, это вот как бы методика полностью персонализированного построения сайта. Ну, то есть, в идеале должны мы дойти до того, что есть некий массив настроек, некий массив данных, и пользователь на лету выстраивается ему сайт персональном виде, с которым он работает. Но и с помощью искусственного интеллекта все это может как-то модифицироваться, подставляться. Суть такая, вот все облачно. То есть, вот все мой дата сайт **Property**. Ну, то есть, в конфиге это, соответственно, у нас два типа. Есть самое главных — это вот сайт конфиг, это настройки сайта. **Structure Config** используется для настроек раздела. То есть, это грубо говоря те параметры, которые используются для того, чтобы сохранить их потом в настройке сайта. То есть, сюда мы можем добавлять нужные параметры, например, и эти параметры появятся в настройках сайта. Но, в смысле, очень легко. То есть, нам не нужно мучиться. Мы вот эти настройки сайта можем легко и быстро выно делать. Настройки разделы, страницы работают немножко по-другому, поэтому у них отдельно есть **Structure Config**. В них, во-первых, не все параметры используются, но не все нужно для из разделы сайтов. Для разделов, и здесь видишь такая штука, есть та часть свойства, они затемненные. Это означает, что эти параметры установлены в сайте, но здесь не приоритетные. То есть, для того, что если ты хочешь, например, чтобы эти параметры в разделе отличались от параметра сайта, просто кликаешь свойства, активируется и можно поменять его значение и установить, например. То есть, весь сайт будет, например, на всю ширину, а здесь будет ограничено щелями. За счет этого можно создавать персонализированный вид или какие-то модификаторы для отдельных разделов или страниц. То есть, система позволяет полностью делать различный вид сайта для абсолютно разных разделов, используя всего лишь, ну, как сказать, один фреймворк. Также и на страницах мы можем что-то включать, отключать, ну и, соответственно, что-то показывать и переназначать эти данные. Но это может вносить **Miki House**. Но смысл, если человек не в правильном порядке идет, ну, то есть берет, например, вместо того, чтобы настройки сайта менять, меняем настройки страницы, то получается, что на некоторых страницах будут сбито отображение. Поэтому нужно проверять и смотреть, что возможно, что есть такое. Еще одна из проблем, которую мы не устранили, это то, что если ты настройка сюда внесёшь, ее нельзя уже убрать. Ну, то есть, например, несешь, а сохранишь, нельзя ее будет сделать снова открепленной. То есть, это вот как раз нюанс. Нужно будет заходить сам конфигурационный файл и удалять это значение, потому что она даже пустое будет играть рождение. То есть, будет переписывать, но это вот как бы мы не проработали еще, просто не было времени. Но есть вот такой вот нюанс. То есть, если настройка страницы или сайта какие-то настройки менялись, эти настройки, они заходят в реестр, и даже пустые они как бы могут влиять. Вот поэтому это периодически надо проверять, смотреть. Дальше что здесь у нас? **IBlock Sex Config** — это используется для конфигуратора изменения **Royal**. Нет, помог, не помню с конфеты блока. Вот и блок конфиг — это наш публичный редактор. Здесь задаются настройки. То есть, мы полностью хотим отказаться от Битрикса. Мы хотим, чтобы пользователь не лазил в админку. Там уж тяжело найти, когда у тебя-то много этих данных, что где используется. Ну, то есть, откуда ему лезть. Соответственно, мы делаем так, чтобы пользователь мог сразу работать с интерфейсом. Напрямую в Битриксе, конечно, есть вот их режим редактирования, но он не очень удобен в том плане, что он не адаптивно. Вторых, там не все правильно показывается. Поэтому у нас есть режим редактора данных. То есть, его включаешь, сайт переходит в специальный режим. Видишь, я начинаю показывать это с помощью этого конфига. Он позволяет загрузить данные вот этого элемента. Опять же, здесь видишь, используется этот конструктор на основе универсальных свойств. То есть, механика одна и та же. От кур это подтягиваем данные быстро, и вам интерфейс меняем, это **Tendon** и сохраняем куда нам нужно. С один и тот же компонент используется. От не держит свойство позволяет выстраивать на лету интерфейс. Вот, мы выстроили. Ну и, соответственно, здесь вот человек может поменять и данные сохранить. Ему не нужно знать, где это новость хранится, как она делает. Все обработки производятся здесь. Также здесь, соответственно, можно добавить новую новость, если нужно. Вот, или удалить. То есть, такая очень удобная штука. Она тоже развивается. В дальнейшем будет еще более развиваться. Сейчас оперативка начинается. Давай ее проведем и дальше продолжим. Маша, запись идет, слышно меня? Накрашен у нас вот есть Люси Чарт. Здесь, в общем, показана структура модулей, но есть, в том числе, я вот не помню сейчас объединение с 4. По-моему, вот этот вот самый фреймворк — это как должны выглядеть трепать ног, как должны сами модули выглядеть. Я тебе ссылочку сброшу, мой час, вы бы посмотришь это структура самого модуля и структуры решения после обновления. Вот здесь папки, я думаю, по названию будет понятно, для чего они нужны. И тут сами модули решения. Мы с тобой становились на **IBlock Config**, то есть я тебя показал, для чего это нужно. Это для режима редактирования. У нас там остался, по-моему, файлик **Section Config**. Это, по-моему, я сейчас точно не помню, а вспомнил. Это когда страницу редактируешь какую-нибудь статическую, вот, например, а центре у нас есть возможность к статической странице прикрепить динамические данные. Вот, то есть ты, например, документ выбираешь, документы, и он, я не буду что сохранять, и он, в общем, снизу подключит документы, будут показывать их. То есть шаблон построен таким образом, что он позволяет, кстати, к любому динамику из нужных разделов. Ну, не любую динамику, вот эту динамику, которую цеплять, как раз про привязку к инфоблокам. Этот северный блок здесь у нас — документа, фотогалерея, видеогалерея, новости, мероприятия, объявления. Вот это как раз что цеплять, она указана. И блок **Section** очень удобен в том плане, что пользователям не нужно мучиться с динамикой, они спокойно это редактируют как статику и при необходимости цепляют динамические данные. Здесь не знаю просто где, но используется на нож. У Маргариты спросить, она покажет. Так, дальше у нас в конфиге мы все файлы посмотрели на венгу, что-то, соответственно, перевод. То есть везде, где текст, стараемся использовать языковые файлы и файлы переводить. При необходимости делаем **ru**. Дальше с помощью модуля перевода мы можем переводить это на любой нужный язык, но у нас есть свой модуль перевода, который позволяет переводить сайт. Так, **Simai Data Config** — все понятно. **Grid** — это наш, скажем так, блочный редактор первой версии, построенный на компонентах Битрикса. Он содержит в себе две папки: **Block** — это блоки, здесь разбита категории, ну, блоки для **Futura**, для **Fedora**, для главной страницы, для центральной части страницы, **Sidebar** для боковой части страницы. Выглядит это следующим образом: переходим в режим редактирования, это Битрикс новый режим, и здесь у нас режим редактирования. Вот они подсвечиваются, то есть **Header**, **Sidebar**, **Monbar**, **Main** сверху, **Main** снизу и **Footer**. Но если главный зайдем, соответственно, будет здесь, видишь, центральная часть. Это особый компонент, который на лету выстраивает с помощью вот этих блоков. Можно выстроить интерфейс. То есть мы отделяем функционал от внешнего вида. То есть у нас есть принцип один во фреймворке — это принцип разделения внешнего вида, данных и функционала. Ну, точнее, внешний вид, настройки и данные. Все эти три составляющие собираются на лету. То есть у нас, например, компонент специальности **Simai** с **Ingrid** позволяет собирать сетку. То есть ты вне определяешь количество строк, вот 1, 2, 3, можно порядок здесь менять. Вот между ними в каждой из этих строк ты можешь определить, сколько будет колонок. Ну, например, вот здесь главный баннер, мы определяем количество колонок 1, например, можем 2. Видишь, где ставим колонка 1, колонка 2. Каждой колонки мы можем указать параметры, это колонки, то есть сколько она будет ширина, там 8, 12, 12, 12. Ну, то есть если один, например, то ширина не спрашивается, ну, потому что 12. В каждой колонке может быть количество областей, но количество областей — это, как бы, строки в колонке. Но области, в отличие от строк, могут идти не только вниз, но и в сторону. Но область 1, область 2, быстрей область 4. Или она удалась, Алина вызвал быстрее вас 4. Параметры того, как они идут, определяются с помощью модификаторов. Здесь много модификаторов. То есть, вот, например, главный баннер, есть модификатор обертки — это то, что снаружи, модификатор строки — это сама arrow. Но ты же с быстровым знаком сетку **Bootstrap** посмотришь, ее часто будешь использовать. Сетка во фреймворке, посмотри на такая же, как **Bootstrap** четвертом. То есть она состоит, если вот сетку посмотреть, макет сетка, вот оно. То есть она включает в себя строки. Вот строка, вот контейнер пошел, вот пошла строка, вот пошла колонка, колонка 1, колонка 2, колонки 3. Вот, соответственно, модификаторы на контейнер, они вешаются как бы на обертку. В это обертки может быть несколько строк. Вот сама строка, модификатор на строку вешается на строку, модификатор на колонку вешается на колонку, а в этой колонке может быть еще несколько областей. Это модификаторы области. Соответственно, можно повесить модификаторы. Что это дает? Это дает возможность полностью управлять с помощью настроек внешним видом вот этого грида. То есть фактически мы все это на лету выстраиваем. То есть пользователь говорит нам: «Уберите вот это». Мы заходим сюда, например, новости и отключаем, вот колонка 1, например, и мы меняем содержимое области. Например, есть специально пустая область, все нужно там, ну, оставить область, но ничего не отображать. Вот пустая область, я в этом случае ничего не показываю. Также у самих областей есть дополнительные параметры, когда ты выбираешь эту область. Например, вот пустая область, видишь, параметров нет. Выбираем место области баннера, динамически подгружаются автоматически данные. И в чем прикол? В том, что ты управляешь, но как бы не вмешиваешься в сам блок. Берешь параметры этого блока, меняешь в этом компоненте и отображаешь как угодно. Что это дает? Один и тот же блок, например, новости или объявления, может несколько раз встречаться на странице, и при этом ты с помощью модификаторов можешь, ну, вот этих параметров и модификаторов задавать совершенно разный вид, разные источники данных, разные отображения, используя один и тот же блок. Понимаешь? Это дает возможность на лету собирать. Это предварительная версия. Следующая версия борщ этого редактора будет, скажем так, более простой для обывателя, это больше для разработчиков. То есть нужно понимать, что это значит. И параметров очень много, обычный пользователь с ума сойдет. Здесь вот как раз модификатор оберток. То есть часть модификаторов нужно просто знать. То есть это мы переключаем бегать. М — это background, модификатор построен по очень простому принципу. Если вот почитаешь, есть сокращение. Вот 10 модификатор, вот они, их просто нужно знать. То есть А — это абсолютная, Б — это граница, БГ — это фон, background цвета, color — цвет, Д — это получается дисплей, Ф — это вот Ф, это не очевидно, но это фил, вот Э — это height, Эль — padding, М — это merging, opacity, П — padding, С — строк, dice. Вот эти совершенно редко используются, типографии и в лифт. Дальше, соответственно, сторона идет live the right to bottom. X — это по горизонтали, Y — по вертикали, а дальше идет значение какое-то значение. Построены так, что они могут идти там от минуса до плюс, ну, максимум 9. И получается, что все очень просто в том плане, что, ну, указываешь ты потом какой-то параметр, потом значение. Ну, то есть если какой-то стране относятся, то есть, например, граница сверху будет быть, потом ширина границы, например, 1, 2, 3, 4, 5. Или, например, цвет границы тебе нужно установить, Б, а потом цвет границ. Но это будет цвет относиться границ. Почитаю, то посмотрите, принцип поймешь. Там, как сказать, даже контент-менеджеры быстро вне к это начинают работать. То есть здесь означает, что мы используем цвет темы. Первый цвет темы **mp4** — это **Martin Bottom**, ну, в смысле отступ снизу четвертый тип и по 1П, Y3 — это означает padding вертикальный Y3 размера. То есть все просто. Цвет темы — это отдельная штука, которая тоже есть только у нас. Это хитрая вещь, которая позволяет на лету перестраивать оформление сайта. То есть можно переключаться с светлой темы на темную тему, и там, где указано **bg тем 1**, она, соответственно, становится фоном. Как сказать, вот **bg тем 1** светом стиль выглядит вот так, вот светлой, беленький, а **bg м 1** тот же самый, как бы этот в темном стиле, он выглядит вот так. То есть он адаптируется к теме. Это позволяет, в общем, на лету выстраивать внешний вид. То есть мы, например, можем поменять светлую тему на темную, он автоматически поменяет все цвета с черного на белый, но и в шрифтов фон поменяет и дальше можно поднастроить. Вот здесь, соответственно, вот по каждому блоку идут какие-то параметры. То есть с помощью этого компонента можно, соответственно, выстроить вот этот грид. Это горячо нас называется, указать, какие блоки где располагаются, в каком порядке, что за чем идет, какие параметры отображения. Ну и, соответственно, внешний вид задается вот здесь. С помощью вот этих параметров задается где-то 80 процентов настроек этих блоков, 20 процентов задается старыми способами. Ну, например, объявлением, и только в таком виде, если используем, они обычного. Вот здесь задаются, то есть у нас разделены там объявление, виде карточек, объявления, виде строк. Они выглядят по-разному, и эти настройки задаются здесь. Это позволяет копировать блоки. Ну, то есть ты берешь один блок, тебе нужно, например, одни и те же данные по-разному отображать, то берешь блок, копируешь, переименовываешь его, меняешь через конфиг, но как бы настройки компонента, его параметры, и он отображается по-другому. Здесь нужно сказать, что у нас есть специальный шаблон. То есть мы используем также универсальные шаблоны. Этого тоже в Битриксе нет, которые позволяют сильно перенастраивать внешний вид отображения элементов, используя один и тот же компонент. По такому же принципу, как **Grid**. То есть вот это самое распространенное — это вот **sf Blog List**. То есть мы вводим перечень элементов инфоблока, дефолт называется, он позволяет вытаскивать данные и настраивать внешний вид. Во-первых, хочу сказать, что во всех компонентах нашего фреймворка мы используем, опять же, отличную систему от Битрикса, работа на кодах. То есть если в Битриксе 3А, кадиш ником все привязывается, ты привязываешь инфоблок, айдишник инфоблока, типа инфоблока и айдишник самого инфоблока, то здесь тип инфоблока привязывается по коду. Видишь, идет инфоблок, тоже привязывается по коду. Что это дает? Это дает возможность копировать данные с одного проекта в другой проект, копировать, использовать вот этот наш универсальный мастер и не задумываться над, скажем, глубокой проблемой Битрикса, что у них айдишники не совпадают. То есть ты, когда копируешь, вставляешь, например, у тебя перестает заработать, потому что айдишник ты не перенастроил. Проходит звезде, проходится, меняй о хищнике. Мы этой проблемы избежали. Это опять же все сделано по правилам Битрикса. У нас есть специальная отстройка, она позволяет на лету менять. На лету менять, ну, то есть здесь уже конкретно инфоблок используется. То есть у нас свои компоненты от **Simai**. **SF** и везде, где **SF** — это компоненты именно фреймворка. Они работают немножко по-другому, ну, как сказать, более расширенно, но по тому же принципу построены. То есть этот **sf Blog List** в Битриксе скин, доработанная система, которая работает с этими кодами. Во-первых, во-вторых, мы используем, в отличие от Битрикса, объектно-ориентированный подход в том плане, что мы превращаем исходные параметры в объекты. Сам шаблон работает с этими объектами. То есть еще одна проблема в Битриксе в том, что ты, например, шаблон делаешь, в нем указываешь свойства, которые используются, и дальше, если, например, пользователь другое использовать название свойств, велико свойства другое, ты с этим свойством работать не можешь. Тебе нужно везде в шаблоне проходить и менять настройки свойств, правильно? Вот здесь вот используется подход именно в этом шаблоне, когда исходные параметры конвертируются в объекты. А сам шаблон работает с объектами, и вообще без разницы, там какие коды, что там, как он, ну, как бы работать тоже по объектному принципу. Сейчас покажу. То есть вот здесь мы задаем параметры, задаем какие-то исходные данные, но это как обычно фильтр и прочее. Дальше пошло то, что отсутствует в Битриксе. Мы указываем вот эти вот объекты области показа. Это как раз объекты, с которыми работает шаблон. Но здесь у нас самые типовые вещи. То есть это, например, изображения, своя иконка, дата, раздел, заголовок, описание, свойства, кнопка. Включаем август для каждого из этих объектов открываются дополнительные параметры, которые включают себя источники данных. Вот, например, источник данных для даты, и система автоматически смотрит все свойства и поля, которые могут данные включать, и ты просто указываешь, что данные берем с даты начала активности. Источник данных для заголовка, она смотрит все подходящие свойства и поля и выводится. Берешь, откуда берется заголовок. Дальше, соответственно, задаешь параметры, например, что там длина заголовка максимально 120, порядок вывода, например, сначала дата, заголовок. Ну, то есть если, например, мы можем указать вот все свойства для сохранять, не буду просто указывать, лишь он погружает все данные. То есть окружают, откуда картинка берется, картинка анонса или детально, переходит на тебя ссылки, например, что будет делать при переходе по ссылке. Просто переход, просмотр изображения, просмотр видео, ну или отсутствует переход, например, источник данных для своего иконки, этот тип файл берет, указывает. Или же, но поле здесь со свагги называет. Источник данных для даты, источник данных для заголовков, но указываем параметры, источник данных для описания, указываем параметр описание, конвертировать, не конвертировать текст, максимально длина, если указано. Здесь весь объект свойства, вот, например, то появляется дополнительно перечень свойств, которые мы показываем. То есть он может вывести все эти свойства. Дальше, соответственно, задаем в каком порядке между собой выводится эти данные. Ну, например, мы можем указать, что будет сначала названием, пример будет заголовок, дата, потом описание, а потом включаем валгас, раздел, свойство, кнопка. Ну, то есть порядок выводу указываем. Дальше использовать, не использовать ссылки, источник ссылки, откуда берется, например, из настройки инфоблока, но если там другое, можно свойства указатель, еще что-то. Вот в новом, не ново, в окне, там теги какие-то могут быть нужны. Вот это все конвертируется в объекты. Вот это перечень объектов будет сам шаблон исходя из параметров этих объектов. Ну, то есть он уже знает, откуда берет данных, создает. То есть есть у компонента файл **Result Modify**, знаешь, да? Вот этот файл **Result Modify**, он как раз проходит по час. Открою этот компонент. Вот он **Simai**. Я почему ему такое внимание уделяю? 90 процентов всех списков сделано всего на одном шаблоне. Список баннеров, список новостей, список объявлений, список галереи партнеров. Вот здесь, если посмотреть главную страницу, сейчас дойдем и до нее. Давайте продублируем, ну, чтобы ты понял значение. То есть вот это, это один и тот же компонент, в котором один и тот же шаблон, в которой меняется только настройки и совершенно разные выводы выдают. Это вот, вот этот шаблон. Вот, например, баннеры, посмотришь, с блок весь дефолт. Это, например, вот этот вот, видишь, иконки, обществ, блоки, дефолт. Это, например, вот новости. Заходим с блок весь дефолт, это вот новость такая. Вот, например, **sf Blog List Default**. Если это, например, может быть вот такие баннеры списком с иконками, **sf Blog List Default** — это один и тот же шаблон. Из массы Битрикса ничего подобного нет. Этот объявлением, например, с **Blog List Default**. Мероприятие, например, заходим с **Blog List Default**. Заходим дальше публикации, но здесь, скорее всего, другой шагов, хотя не знаю, с **Blog List Default**. Ну, хотя здесь, здесь потом покажу. То есть здесь сетка стальные функционал можно делать. Здесь заходим с **Blog List Default**, видишь, с помощью одного и того же шаблона, одного и того же компонента, с помощью только параметров на создаем абсолютно разные виды, ну, разное контента, разные отображения. Вот и делается с помощью настроек. То есть здесь мы выбрали, какие данные, в каком порядке, как они отображаются. Дальше есть включаемые файлы. То есть для того, чтобы стабилизировать, например, функционал чего-то не хватает, мы можем подключать отдельные файлы, которые могут оперировать с данными инфоблока и менять контент. То есть, например, вот как раз если смотреть здесь, вот этот функционал, как раз отличается. Видишь, здесь у нас есть такая штука, которая позволяет файлу так просматривать. Вот, и чтобы это реализовать, как раз был подключен отдельный файлик, который, ну, это возможность добавляет. То есть вот данные шаблоны, и здесь у нас должна будет включаемая область. И, соответственно, включаем область. Видишь, включаемая область элемента, подключается один файлик **In Cloud** элемент, который находится в самом блоке вообще. Ну и он занимается тем, что вы вот эту кнопку, как бы, получать данные из отображает вот эту кнопку, и эта кнопка показывает содержимое свойства с публикации. Вот, то есть все сделано для того, чтобы, но вообще не плодили ничего лишнего. Поэтому фреймворк, вот, ну, когда он дошел до какой-то стабильной версии, он предоставляет настолько большое количество возможностей, что, в принципе, все решаются вопросы. Здесь вот есть макет, то есть можно использовать сетку. Здесь вот видишь, параметры идут вот такие. Это параметры берутся из грида. То есть получается, горит сюда передает параметры по отображению, и мы управляем параметрами компонента через параметры грида. Но вообще можно настроить отображение, то есть как это все будет выглядеть внешнем виде. Здесь мы отображаем, как это выглядит, либо это карточки, либо слайдер. Но отличается это тем, что карточки — это вот, ну, вот когда элементы идут один за другим, а вот это вот слайдер, когда элементы идут в слайдере. Вот здесь, дальше, соответственно, мы какие-то параметры даты выводим, там полноэкранный режим. И то это, в общем, используется, когда контент нужно вывести не в рамках вот этого контейнера, а на весь экран. Ну, то есть, например, вот полноэкранный режим, вот этот баннер, пишем, занимает весь экран, а вот это в контейнере находится. **With Animation** — то есть тут, в принципе, есть такая штука, что можно сделать, не знаю, используется, не используется. Сейчас попробую выйти отсюда, по-моему, выключена. Да, сейчас выключено. Но, в принципе, все компоненты поддерживают анимацию. Сейчас посмотрю внешний вид. На здесь отсутствует, да? Попробуем встать и кликнуть. Дата анимация при прокрутке, такие экспериментальные функции, непонятно для чего. То есть это когда прокручиваешь, видишь, все вот так анимируется, но не всех это радует, поэтому по умолчанию эта штука отключена. Но вообще все, все вот эти блоки, которые используются, они уже настроены с анимацией. То есть вот вид анимации, откуда появляется, и не задержка, ну, то есть скорость, с которой появляется. И дальше идут модификаторы. Вот эти как раз по модификаторы, это используется отсюда. Ну, есть frontend, а потом нужно будет на них ориентироваться. Они-то как раз вот эти модификаторы позволяют задать абсолютно любой внешний вид, используя один и тот же шаблон, разные данные, разные контенты, размеры. То есть все строение шаблона разбито на секции, ну, как бы блоки, они вложены друг в друга, и у каждого из этих блоков мы можем задавать модификаторы. То есть сам шаблон предоставляет скелет, с помощью модификаторов мы указываем параметры этого скелета, который, соответственно, внешний вид на лету выстраивается. Вот за счет этого не надо никуда лазить. То есть всегда зашел, например, в любой блок, у него есть дискрипшн, не нужно сидеть вручную прописывать. В принципе, берет, подтягивает зависимости от названия папок, какие-то вещи. Но, в смысле, делает. Единственное, что нужно будет зайти, все-таки его имя указать. Ну, то есть вот здесь вот **Language**, по-моему, тут только ими идет. Да, вот здесь баннер одиночно. Дальше все остальные параметры, они походу подтягиваются. Ну, то есть здесь шаблон зайти, уже у него есть вступительная часть, он подтягивает какие-то данные, а дальше, видишь, но очень простое строение блока. Обычный компонент, в нем, соответственно, живо указывается, например, айдишники. То есть он берет текущие настройки сайта, и это получается у нас настройки для баннера. Если же там используются параметры, то идет сложнее. То есть, например, возьмем какой-нибудь **Header Blog**. Ну и, например, простенькое что-нибудь **For Kleem** или **Or Kleem**. Вот **Or Kleem**. Здесь, видишь, появляется параметр, он определяет, какие параметры подтягивать. Здесь вот один параметр, этот параметр автоматически подгружается в **Grid**. Здесь дефолтное значение пользователь, соответственно, может поменять это значение, и дальше этот параметр, значение этого параметра подтягивается в шаблон, и ты можешь его использовать. То есть вот здесь уже, вот видишь, идет **Blog Property**. Здесь идет **Name Template**. Это, чтобы ты не мучился с кодами, ну, как сказать, с названиями этих параметров, он автоматически подтягивает, как бы, как объяснить. Так как это все выстраивается в рамках одного компонента, но это же все в **Grid** участвует, то может получиться, что если, когда ты используешь одинаковые значения, то эти значения перед записываются. Может, сталкивался с языковыми файлами. То есть второе такое же название перепишет предыдущее название за кого файла, но, в смысле, языка и файл, а параметр языковой, и она будет выводиться. Также здесь, чтобы избежать вот этих дубликатов, соответственно, автоматизирована эта система, ну, как бы выстраивает назначение этих параметров. То есть думать не нужно там особо, и создает их уникальность зависимости от названия папки. То есть вот это **Name Template** — это вечно берет название парке, а название папки — это код, по сути, шаблона. Ну, точнее, код блока. Вот и все очень просто. Но на этом еще не все. Есть такая штука, как представление. То есть, например, мы имеем вот такую компоновку страницы, а мы хотим другую. Мы хотим дать пользователю возможность, например, выбрать такая страница или другая страница. Есть такая штука, как представление. То есть это, грубо говоря, мы сохранили настройки и сохранили под определенным названием. Настройка, например, сборка настройки 1, сборка настройки 2, сборка настройки 3. Это называется подключаемой области. Ой, нет, макеты областей. Вот и здесь вот идут, например, вот шапка сайта. Например, мы хотим, ну, вот такую шапку сайта. Вот вообще убираем, нажимаем сохранить, и у нас шапка должна пропасть. Виде шапки нет. Хотим, например, шапку сайта поменять на другую. Заходим, макеты областей, выбираем вот такую шапку сайта, и оно вот такое делает. Чтоб, видишь, и так мы можем менять, в принципе, ну, любую вещь. Вот так получше видно. Да, да, но здесь расскажу, ну и заодно и к другим придет. В общем, почему мы используем свой фреймворк? Потому что Битрикс, как я говорил, уже не развивается много лет в плане управления сайтом. Мы, соответственно, разрабатываем технологию, которая позволяет, скажем, достигнуть определенных целей. Скажем, той целью, которую хочется достигнуть, является искусственный интеллект для управления сайтом с помощью искусственного интеллекта. Для этого у нас была задача разбить весь сайт на блоки, вплоть до отдельных вещей, и создать систему сборки данных, состоящую из фронтенда и бэкенда. Frontend, соответственно, на сайте либо Free, максимальная версия — старая версия, либо SF4, Saw 4. Самая последняя версия уже не 4.8.1, больше это все время подправляем. Бэкенд состоит из следующих вещей: он состоит из двух папок. Ну, точнее, раз, два, три, четыре. Сейчас перечислю все вещи. Так, самая важная папка фреймворка — это папка **Simai**. Папка **Simai** находится всегда в корне сайта. Ну вот, прямо в корне, в корне. То есть, если есть сайты на папках, то есть, к примеру, это папка сайта, а это корень сервера. Как это называется? Очень в корневой папке находится папка **Simai**. Она содержит в себе вот следующие подпапки. Одним из них являются те формы, которые для администрирования используются. Они сюда выкладываются для того, чтобы к ним был доступ. Так они находятся в модуле. То есть, если в любую из них зайти, то будет ссылочка на файл, который сам модуль находится. Ну и, соответственно, здесь админские все формы, которые есть во фреймворке. **Post** — это проверка почты, про почту **SMTP** настройки. **Property** — не помню, тоже не помню, в смысле, этот принцип неважно. Вот папка **Asset** — здесь все, что используется, и скриптов, и стилей. У нас есть целая API по подключению всех этих скриптов и стилей. Сюда выкладываются папка первая, папка содержит, грубо говоря, папку какого-то ресурса, а в ней могут быть подпапки по версии. То есть, фреймворк поддерживает одновременную работу с несколькими версиями. Есть конфигурационный файл, в котором описывается, какая версия подключается. Этот конфигурационный файл находится в папке **Config**. Вот здесь вот, то есть, если посмотреть, **AssetConfig** как раз описывает, какие стили и скрипты подключаются. То есть, вот такой вот массив есть в нем. Соответственно, мы потом сделаем конфигуратор, который позволит добавлять и убавлять. Пока все это в виде конфигов сделали, но принцип очень простой. То есть, что мы подключаем здесь по умолчанию? Дефолт. То есть, по умолчанию подключит версию 4, но папка **Default** — это то, что подключается, если не указано в параметрах API подключения, какую версию подключать. Соответственно, берет дефолт. Вот здесь параметры, то есть, какая версия, какая подпапка, соответственно, какие подключаются файлы, и эти файлы являются либо стилями, либо скриптами. Вот тип скриптов **Post**. Итак, соответственно, мы проходимся по всем конфигурационным файлам. В самом конфиге описаны все вот эти ресурсы, которые используются для подключения ассетов. Но из этого в проекте может использоваться не все, что именно используется, описано в папке, но в самом модуле. То есть, например, у нас подключается сейчас модуль **Simai**. Ну, например, **Simai Free**. Если здесь посмотреть, **In Cloud** — то подключается файл, видишь, автоматически подключаем. А это классы? Нет, это не то. Это классы, которые подключаются при регистрации модуля. Сейчас посмотрю решение. Вот самое со **SF4**. Не, я просто не помню, там разные версии по-разному делались. Мы перенесли, и сейчас в последней версии мы перенесли большую часть самого модуля фреймворка. Эта версия до объединения модуля фреймворка с модулем решения. Вот видишь, здесь вот... Погоди, что не вижу. Так, да, я посмотрю в другом месте. Встреч не помню, куда это мы внесли. Так, секундочку. Да, да, работа с... То есть, мы подключаем. Вот здесь, видишь, используйте **Simai Mind**. Это подключается класс по работе с этими ресурсами. И дальше, в принципе, просто указываем **Asset** год **Instant Slots**, какое нам нужно подгрузить. Если мы не указываем версию, то здесь, по идее, можно указать запятую и версию, то подгружает именно дефолт. Если указываем, и в конфиге прописано эта версия, то он может погрузить определенную версию. То есть, тебе нужно, например, там, не знаю, **jQuery** версии 2, а не 3, то можно в конфиге прописать версию 2 и 3, и здесь погрузить вторую версию. Ну вот так вот работают. Удобно в плане того, что чем удобно? Не нужно каждый раз вспоминать, какие тебе нужны скрипты, стили. Но для подключения ты можешь эту строку использовать несколько раз, но при этом он определяет, подгрузил он уже эти стили или не подгрузил. Если подгрузил второй раз, он уже не будет подгружать. То есть, мы решаем несколько проблем. С одной стороны, нам не нужно запоминать, какие стили, скрипты подгружать нужно и какой версии. То есть, там всегда актуальная версия подгружает последние, и нам не нужно помнить, подгружали мы или не подгружали. То есть, основное мы устанавливаем, и даже если мы повторимся, ничего страшного нет. То есть, во второй раз подгружать не будет. Ну и также здесь используется механизм объединения стилей, скриптов Битрикса. Тайсон, на самом деле, это настройка над Битриксом, с методами по работе с данными. То есть, она полностью как бы сделана подвести под подключение. Просто она, как искать удобства, создаёт. Вот и в результате можно быстро определить, что подключить, что не подключить. Но смысл и это уже использовать. Вот дальше с ассетами понятно, да? То есть, папку **Asset** засовываем сами ресурсы, причем три уровня. Первое — это вот сама папка, здесь уже версии, а версии уже сами папки и файлы, которые используют. А в конфиге, если добавляется, это все должно быть прописано, а потом уже через API мы подключаем то, что есть в конфиге. Вот папка **Config** используется для конфигурационных файлов. Вот **Config** — это такой же, как сказать, конфигурационный файл, который позволяет подключать скрипты. Он содержит в себе название скриптов и какая строка подключается при этом. Соответственно, когда ты выбираешь через API, какой скрипт использовать, то автоматически подтягивается нужный **script tag**. Где это интересно? **Font Body Property Guide Instance**. Вот видишь, используется. То есть, она определяет из настроек сайта, какой шрифт использовать. И точно также **Font Get Instant Slot** указывали, какие загружать. Механизм абсолютно везде одинаковый, поэтому с **Sape** нашим достаточно легко работать. Шрифт указывается. Вот если посмотреть сайт, здесь есть оформления сайта, шрифты. Один ваш **Rift**, и ты можешь выбрать, какой шрифт используется для текста. Но до сих пор это все как разберется из конфига. Но точнее, это из конфига внесено, да, автоматически берет из конфига, вроде формирует список, и здесь, какой шрифт для заголовков, он, соответственно, берет вот эти параметры и подгружает их через метод в виде стиля. То есть, определяет, что подгружать. Вот с этим тоже понятно, да? Вроде **Regtime Flag**. Вот фреймворк **Config** — это, скажем, редко используемые параметры самого фреймворка. Ну, скажем так, системные настройки. Вот здесь какие-то параметры мы задаем, но они редко. Это типа у Битрикса конфигурационный файл, то есть он конфигурирует весь фреймворк. Здесь задается, но различные значения. Ну и, соответственно, потом используются **SMTP** настройки. **Property** — это наш модуль универсальные свойства, называются. Суть такая, что мы разработали технологию, которая позволяет отделять отображение свойств от самих данных. То есть, ну вот, например, вот это все построено на универсальных свойствах. Мы сюда задаем просто тип свойства, грубо говоря, интерфейс по работе с свойствами строится с помощью этого модуля. Мы ему задаем, какие свойства используются и типа этих свойств. Он, соответственно, выстраивает весь интерфейс, исходя из этих свойств. И дальше, когда нам нужно, мы обратно забираем значение. Ну, то есть, вот здесь какие-то значения есть, мы значение забираем, эти значения уже сохраняем. То есть, модуль универсальные свойства нужен для построения интерфейсов по работе с любыми свойствами. То есть, мы не можем на входе иметь массив данных откуда угодно, выстроить интерфейс по работе с этими данными, потом забрать значения и сохранить это значение куда угодно. Понимаешь? Я не настраивал там флакончик, и это, допустим, там, кроме 3, можно было через сибирский носи маску пора добавлять. Ты нажимаешь и добавляешь до значения. Столкнулся, причем вот это все, это как бы шаблоны отображения. Есть несколько, идут два варианта шаблона. У нас сейчас есть шаблон дефолт, он используется. Но в таких интерфейсах типа Битрикса внутри он очень приближенный. Я сейчас не помню, где этот файлик находится, но в самого модуля сейчас посмотрю. То есть, здесь вот есть модуль **Simai Property**. Вот он, наверное, админ. Меня вот тест до **SF Property** тест. Да, я попробую так сделать. Попробуем вот так вот. Да, вот здесь едешь разные типы данных. Это вот системные, то есть так выглядят системные поля. Но где шаблон дефолт? То есть, можно выстраивать интерфейсы прямо внутри админки Битрикса с различными типами. Выглядит это как методы, представляешь? Метод, он сам рисует тебе интерфейс. Но, в смысле, дальше, соответственно, ты можешь забрать в результате данные. Здесь вот уже используется шаблон из **SF4**. Шаблон **SF4** заточен уже под именно под фронтенд часть, но построена на базе **SF4**. То есть, вот это, например, список, он может быть в таком виде. Список может быть, например, ну, то есть одни и те же данные могут быть в разном виде. Список может быть выпадающий, может быть, например, вот такой. То есть, это тоже, например, какой-то список. Он, то есть, радио бокс такой вот, такой вот может быть в виде кнопок. Радио бокс может быть, например, вот такую вещь или этом. То есть, мы сделали разные отображения для одних и тех же данных. В результате получается, что налито можно выстраивать интерфейсы, нужно получать данные, работать. Ну, очень удобная штука. Вот так, дальше папочка с **Property** понятно, да? Здесь как раз хранятся именно сами шаблоны. То есть, вот, например, **Checkbox**. Здесь компоненты по работе. Вот, то есть, сказать **Property** посмотреть. То есть, ты можешь, по идее, используя эти же шаблоны, свой шаблон создать. То есть, вот есть **Default**, есть, например, **SF4**. Из **SF4** **Image**. **SF4 Switch**. Вот этот префикс **SF4** позволяет понять, что он как бы строится именно на базе **SF4**. То есть, это один и тот же **Checkbox**, только он может быть у разных ипостасей. Может быть просто как **Checkbox**, может быть в виде картинок, может быть в виде переключателей. Вот и так по всем. То есть, у нас вот есть, например, по цветам, по датам. Эта сущность файл, наверное, самый большой — это список какой-нибудь, лист или радио бокс и счетчик. Но получается, **Checkbox** от, и у каждого из них есть параметры. По-моему, документации это все описано где-то. Может быть, здесь на я немного почитал. Дайте пара геймерам доводка верхами свойства. Здесь вот написано, да, есть переключатель цвет. Но здесь надо проверить, почему нет. Если где-то видишь какие-то проблемы, постарайся разобраться и подправить, потому что документации у нас создается, скажем так, дружненько, и возможно, что где-то постоянно что-то отваливается. Но не должна быть такова работа. Нашел там, как добычу редактировать у Ренаты. Уточняя, везде по-разному. То есть, вот это у нас тренируется. Точно также, как то решение правишь. То есть, у нас есть этот по четвертому фреймворку, отдельно образ, который тебе давал. В этом образе, соответственно, есть уже, но на Google Open Server, это **MySQL 4 Local**, и можно подгрузить. И там вот то же самое, только в локальной версии можно подправлять и отгружать. Она здесь будет обновляться. Шар. Вот так с этими свойствами понятно, да? То есть, вот **Property** — это фактически компоненты, шаблоны по работе именно с этими свойствами. **Wizard** — это еще одна наша уникальная разработка. Это универсальный мастер, который позволяет пошагово выполнять действия. У него отдельно документация, как бы частично присутствует. Я скину в виде файла, по-моему, я не выкладываю никуда. Дании укладываю. Суть такая, что есть действие, но каждое действие может выполнить какое-то что-то такое. Сейчас посмотрю, может быть, у меня есть описание. То есть, от вас нет, она присутствует. А, она нет. Так, пока грузится. Очень принцип какой есть конфигурационный массив, когда выполняется вот мастер, например, тестовой и лесов 4. То есть, эта папка обслуживающая мастер. Здесь индексный файл и самое главное — тут профиль **Wizard Config**. **Wizard Config** — то он делает, что он описывает какие-то параметры визарда. То есть, мастер на лету собирается. Он вообще как бы мне такого, что модель на мастер прописывая, он на лету собирается выполнять действие с помощью этого конфигурационного файла. Здесь пошли действия. У каждого действия, ну, есть определенное название, которое вводится. Есть входящий массив, он может брать, например, откуда-то данные. Но фактически эти данные сохраняются, скажем так, в сессии. Он может, например, выполнить одно действие, получить какие-то данные, ну, например, список инфоблоков и загрузить в сессию. Дальше второй, например, этот 7 может перечень инфоблоков, например, упаковать в архивы. На второе действие ты ему указываешь, откуда он берет данные, и, соответственно, источник данных. И он, ну, пакует их. То есть, здесь вот, например, действий у нас используется код сайт, чего сын стал. Мы указываем, куда он записывает эти данные. Он записывает их в параметр сайт конфиг. Дорогих нет, он выполняется, выбирается. Дальше пошел распаковка файлов. То есть, соответственно, мы используем действие **File Andi**. Это массив, куда он выгрузит, ну, как бы информацию о том, что нас паковал. Дальше параметр, какие, ну, какие файлы и там, что нам нужно запаковать. Дальше пошел, например, там добавление чипу. Здесь, соответственно, какие параметры, откуда чего берется. Ну и откуда данные берем сайт конфиг. Ну, то есть, вот и таким образом получается, что отдельные блоки выполняют маленькую часть работы и взаимосвязаны через вот этот конфигурационный файл и, скажем, хранение данных, ну, в этой сессии взаимодействуют между собой. То есть, сам вот этот конфигурационный файл описывает методику взаимодействия отдельных этих частей между собой, кто что делает, откуда данные берет, расами действия при этом неизменно. Вот тоже блочная система. То есть, мастер на лету собирается. У нас есть большое количество уже описано, как бы действия, которые выполняют разные вещи. Ну и по сути сейчас упаковка. То есть, вот этот мастер, например, я не знаю, мастер установки, скорее всего, еще есть мастер упаковки. То есть, принцип такой, что все в топ действия, которые требуется автоматизировать, мы закидываем в мастера. Мастера делают автоматически. Вот с этим понятно, да? Ну, более потом, как этому придешь, скажешь мне, что тебе нужны, тебе скину документацию. Сейчас тебе не хочу грузить, там большая дыра. Имитация есть интересна. Мол, кастрик вместе работает действие. Можешь просить его, он тебе покажет. Например, я просто не знаю, где это. Ну, здесь я боюсь запускать, но сломаешь. Так вот, какой не тестовый полигон можно будет поднять и запустить. Вот когда больше решение устанавливают, месяцев 4 установка, это мастер как раз запускается. Вот, ну то, что эти обрезал, это мастер установки. Дальше в папку. То есть, в папке сайта это необязательно. Папку может быть, это тоже может быть корень. Если, ну, сайт находится в корне, если **of popki ru** находится, то это будет в папке **ru**. Есть папка **Simai Data**. Это **Simai Data** — это данные для конкретного сайта. Ну, то есть, Q1 на сайт может быть в режиме много сайтов. Асти, ну, например, может быть русская, английская, там, японская версия, и у каждой в отдельной своей папке будет вот эта папка. Она содержит данные конкретно для данного сайта. Ну, то есть, вот для него эта папочка содержит следующие. То есть, админ — это, но те же конфигурационные различные эти элементы. То есть, конфигурация, настройки, демонстрационная настройки, настройка страницы, настройка раздела, настройка сайта — это то, что здесь. То есть, стране развелся демонстрационные настройки. Вот это вот все конфиги и блока выми делает. Едет, едет, едет. Это, по-моему, какие-то тоже связаны с этими вещами. То есть, вот здесь вот не помню, где то что-то редактировать. Ну, просто не помню. Вот используется. То есть, этот файл для редактирования конфиге — это конфигурационные файлы для сайта. Уже **Dima Config** — это демонстрационная конфиге. Я то, что показывается. Ну, тоже механизм абсолютно везде одинаковый, что сильно упрощает работу. Это код параметра, идет название параметра, тип параметра и, соответственно, дефолтное значение. Работает очень просто. То есть, когда ты нажимаешь, например, настройки страницы, запускается один компонент, который считывает именно настройки данной страницы, использует конфигурационный файл раздела. Но здесь конкретно у нас сайта загружает исходные данные через компонент, пропускает, выстраивает полностью вот этот весь интерфейс. Когда нажимаешь сохранить, он, соответственно, берет полученные данные и сохраняет настройки сайта. Вот это позволяет все вот эти вещи налит устроить. То есть, и не нужно лазить, как в обычных, это в коде искать эти параметры и значения. Ты просто в конфигурационном файле меняешь, у тебя на лету все выстраивается. Также очень просто с точки зрения сохранения данных. То есть, например, настройки сайта все сохраняются в конфиге. Вот здесь вот видны, если что-то не так, можно всегда зайти, посмотреть сам искать исходный конфликт. Но, в смысле, что здесь сохранена. Принцип здесь один и тот же. То есть, код параметра и его значение. Все вот эти параметры при загрузке сайта **SFC 4** подгружаются. Все **SE** доступно через параметры считывания кодов. То есть, ты можешь запросить код параметра, и, соответственно, тебе выдаст его значение. Ну, например, это вот идет через **Property** **USSI** **Mai-Mai** конфигурации **Property**, но дает используется. И, соответственно, вот **Property Guide Instance** запрашивает **SFC** одеру. Это текущий сайт. Ну, то есть, он через константу берет текущий сайт, это значение параметра. То есть, он запрашивает настройки сайта, и, соответственно, он выдает значение по данному коду. Причем нюанс в чем заключается? Здесь есть и архи я свойств. То есть, сначала грузится, значит, параметры сайта, потом сверху грузится параметры раздела. И если они есть, пересекаются, то перезаписываю параметры сайта. Ну, то есть, параметры раздела более приоритетны, чем над параметрами сайта. Потом грузится параметры страницы, и они более приоритетные, чем параметры раздела. Потом грузится, но если используется **Dima** данные, и они более приоритетны, чем параметры страницы. Ну, то есть, ты можешь здесь указать параметры, и, соответственно, сайт поменяется на лету. Причем это будет сделано для каждого пользователя персонально. Все это сохраняется в сессии. Соответственно, когда сайт загружается, он и сессия подтягивает весит массив параметров. То есть, сайт не разбирается, где что. Просто вот при за счет приоритетности так выигрывать. Также есть параметры, которые как бы уже параметр пользователя называются. Вот эти темы параметр, параметры пользователя относятся. Или вот эти вот параметры. То есть, ты, когда вы здесь указываешь, видишь, здесь идет **Property Code** равно почти **View**. **Property Value** равно **List**. Мы через **URL** можем заменять через **URL**. Может заменять значение некоторых параметров. И за счет этого, когда ты нажимаешь кнопку, происходит, но как бы установка параметров. И дальше этот параметр уже, ну, сохраняется, и ты его можешь использовать. То есть, когда пользователь следующий раз зайдет на эту страницу, то есть, например, зашел вот сюда, зашел сотрудники, она, видишь, уже погрузилась, хотя здесь этот параметр не установлен. То есть, этот параметр записался всей сервиса от этого **Mirza** ватель уже с ним работает. Если мы нажмем другую кнопку, опять же запускается такая строка, что **Property Core** такой. Это когда система считывает эти значения, на перезаписывает параметры. И, соответственно, мы можем с помощью кнопок или каких-то вещей полностью менять значение любых параметров. Интерфейс на лету перестраивается для конкретного пользователя. То есть, это вот как бы методика полностью персонализированного построения сайта. Ну, то есть, в идеале должны мы дойти до того, что есть некий массив настроек, некий массив данных, и пользователь на лету выстраивается ему сайт персональном виде, с которым он работает. Но и с помощью искусственного интеллекта все это может как-то модифицироваться, подставляться. Суть такая, вот все облачно. То есть, вот все мой дата сайт **Property**. Ну, то есть, в конфиге это, соответственно, у нас два типа. Есть самое главных — это вот сайт конфиг, это настройки сайта. **Structure Config** используется для настроек раздела. То есть, это грубо говоря те параметры, которые используются для того, чтобы сохранить их потом в настройке сайта. То есть, сюда мы можем добавлять нужные параметры, например, и эти параметры появятся в настройках сайта. Но, в смысле, очень легко. То есть, нам не нужно мучиться. Мы вот эти настройки сайта можем легко и быстро выно делать. Настройки разделы, страницы работают немножко по-другому, поэтому у них отдельно есть **Structure Config**. В них, во-первых, не все параметры используются, но не все нужно для из разделы сайтов. Для разделов, и здесь видишь такая штука, есть та часть свойства, они затемненные. Это означает, что эти параметры установлены в сайте, но здесь не приоритетные. То есть, для того, что если ты хочешь, например, чтобы эти параметры в разделе отличались от параметра сайта, просто кликаешь свойства, активируется и можно поменять его значение и установить, например. То есть, весь сайт будет, например, на всю ширину, а здесь будет ограничено щелями. За счет этого можно создавать персонализированный вид или какие-то модификаторы для отдельных разделов или страниц. То есть, система позволяет полностью делать различный вид сайта для абсолютно разных разделов, используя всего лишь, ну, как сказать, один фреймворк. Также и на страницах мы можем что-то включать, отключать, ну и, соответственно, что-то показывать и переназначать эти данные. Но это может вносить **Miki House**. Но смысл, если человек не в правильном порядке идет, ну, то есть берет, например, вместо того, чтобы настройки сайта менять, меняем настройки страницы, то получается, что на некоторых страницах будут сбито отображение. Поэтому нужно проверять и смотреть, что возможно, что есть такое. Еще одна из проблем, которую мы не устранили, это то, что если ты настройка сюда внесёшь, ее нельзя уже убрать. Ну, то есть, например, несешь, а сохранишь, нельзя ее будет сделать снова открепленной. То есть, это вот как раз нюанс. Нужно будет заходить сам конфигурационный файл и удалять это значение, потому что она даже пустое будет играть рождение. То есть, будет переписывать, но это вот как бы мы не проработали еще, просто не было времени. Но есть вот такой вот нюанс. То есть, если настройка страницы или сайта какие-то настройки менялись, эти настройки, они заходят в реестр, и даже пустые они как бы могут влиять. Вот поэтому это периодически надо проверять, смотреть. Дальше что здесь у нас? **IBlock Sex Config** — это используется для конфигуратора изменения **Royal**. Нет, помог, не помню с конфеты блока. Вот и блок конфиг — это наш публичный редактор. Здесь задаются настройки. То есть, мы полностью хотим отказаться от Битрикса. Мы хотим, чтобы пользователь не лазил в админку. Там уж тяжело найти, когда у тебя-то много этих данных, что где используется. Ну, то есть, откуда ему лезть. Соответственно, мы делаем так, чтобы пользователь мог сразу работать с интерфейсом. Напрямую в Битриксе, конечно, есть вот их режим редактирования, но он не очень удобен в том плане, что он не адаптивно. Вторых, там не все правильно показывается. Поэтому у нас есть режим редактора данных. То есть, его включаешь, сайт переходит в специальный режим. Видишь, я начинаю показывать это с помощью этого конфига. Он позволяет загрузить данные вот этого элемента. Опять же, здесь видишь, используется этот конструктор на основе универсальных свойств. То есть, механика одна и та же. От кур это подтягиваем данные быстро, и вам интерфейс меняем, это **Tendon** и сохраняем куда нам нужно. С один и тот же компонент используется. От не держит свойство позволяет выстраивать на лету интерфейс. Вот, мы выстроили. Ну и, соответственно, здесь вот человек может поменять и данные сохранить. Ему не нужно знать, где это новость хранится, как она делает. Все обработки производятся здесь. Также здесь, соответственно, можно добавить новую новость, если нужно. Вот, или удалить. То есть, такая очень удобная штука. Она тоже развивается. В дальнейшем будет еще более развиваться. Сейчас оперативка начинается. Давай ее проведем и дальше продолжим. Маша, запись идет, слышно меня? Накрашен у нас вот есть Люси Чарт. Здесь, в общем, показана структура модулей, но есть, в том числе, я вот не помню сейчас объединение с 4. По-моему, вот этот вот самый фреймворк — это как должны выглядеть трепать ног, как должны сами модули выглядеть. Я тебе ссылочку сброшу, мой час, вы бы посмотришь это структура самого модуля и структуры решения после обновления. Вот здесь папки, я думаю, по названию будет понятно, для чего они нужны. И тут сами модули решения. Мы с тобой становились на **IBlock Config**, то есть я тебя показал, для чего это нужно. Это для режима редактирования. У нас там остался, по-моему, файлик **Section Config**. Это, по-моему, я сейчас точно не помню, а вспомнил. Это когда страницу редактируешь какую-нибудь статическую, вот, например, а центре у нас есть возможность к статической странице прикрепить динамические данные. Вот, то есть ты, например, документ выбираешь, документы, и он, я не буду что сохранять, и он, в общем, снизу подключит документы, будут показывать их. То есть шаблон построен таким образом, что он позволяет, кстати, к любому динамику из нужных разделов. Ну, не любую динамику, вот эту динамику, которую цеплять, как раз про привязку к инфоблокам. Этот северный блок здесь у нас — документа, фотогалерея, видеогалерея, новости, мероприятия, объявления. Вот это как раз что цеплять, она указана. И блок **Section** очень удобен в том плане, что пользователям не нужно мучиться с динамикой, они спокойно это редактируют как статику и при необходимости цепляют динамические данные. Здесь не знаю просто где, но используется на нож. У Маргариты спросить, она покажет. Так, дальше у нас в конфиге мы все файлы посмотрели на венгу, что-то, соответственно, перевод. То есть везде, где текст, стараемся использовать языковые файлы и файлы переводить. При необходимости делаем **ru**. Дальше с помощью модуля перевода мы можем переводить это на любой нужный язык, но у нас есть свой модуль перевода, который позволяет переводить сайт. Так, **Simai Data Config** — все понятно. **Grid** — это наш, скажем так, блочный редактор первой версии, построенный на компонентах Битрикса. Он содержит в себе две папки: **Block** — это блоки, здесь разбита категории, ну, блоки для **Futura**, для **Fedora**, для главной страницы, для центральной части страницы, **Sidebar** для боковой части страницы. Выглядит это следующим образом: переходим в режим редактирования, это Битрикс новый режим, и здесь у нас режим редактирования. Вот они подсвечиваются, то есть **Header**, **Sidebar**, **Monbar**, **Main** сверху, **Main** снизу и **Footer**. Но если главный зайдем, соответственно, будет здесь, видишь, центральная часть. Это особый компонент, который на лету выстраивает с помощью вот этих блоков. Можно выстроить интерфейс. То есть мы отделяем функционал от внешнего вида. То есть у нас есть принцип один во фреймворке — это принцип разделения внешнего вида, данных и функционала. Ну, точнее, внешний вид, настройки и данные. Все эти три составляющие собираются на лету. То есть у нас, например, компонент специальности **Simai** с **Ingrid** позволяет собирать сетку. То есть ты вне определяешь количество строк, вот 1, 2, 3, можно порядок здесь менять. Вот между ними в каждой из этих строк ты можешь определить, сколько будет колонок. Ну, например, вот здесь главный баннер, мы определяем количество колонок 1, например, можем 2. Видишь, где ставим колонка 1, колонка 2. Каждой колонки мы можем указать параметры, это колонки, то есть сколько она будет ширина, там 8, 12, 12, 12. Ну, то есть если один, например, то ширина не спрашивается, ну, потому что 12. В каждой колонке может быть количество областей, но количество областей — это, как бы, строки в колонке. Но области, в отличие от строк, могут идти не только вниз, но и в сторону. Но область 1, область 2, быстрей область 4. Или она удалась, Алина вызвал быстрее вас 4. Параметры того, как они идут, определяются с помощью модификаторов. Здесь много модификаторов. То есть, вот, например, главный баннер, есть модификатор обертки — это то, что снаружи, модификатор строки — это сама arrow. Но ты же с быстровым знаком сетку **Bootstrap** посмотришь, ее часто будешь использовать. Сетка во фреймворке, посмотри на такая же, как **Bootstrap** четвертом. То есть она состоит, если вот сетку посмотреть, макет сетка, вот оно. То есть она включает в себя строки. Вот строка, вот контейнер пошел, вот пошла строка, вот пошла колонка, колонка 1, колонка 2, колонки 3. Вот, соответственно, модификаторы на контейнер, они вешаются как бы на обертку. В это обертки может быть несколько строк. Вот сама строка, модификатор на строку вешается на строку, модификатор на колонку вешается на колонку, а в этой колонке может быть еще несколько областей. Это модификаторы области. Соответственно, можно повесить модификаторы. Что это дает? Это дает возможность полностью управлять с помощью настроек внешним видом вот этого грида. То есть фактически мы все это на лету выстраиваем. То есть пользователь говорит нам: «Уберите вот это». Мы заходим сюда, например, новости и отключаем, вот колонка 1, например, и мы меняем содержимое области. Например, есть специально пустая область, все нужно там, ну, оставить область, но ничего не отображать. Вот пустая область, я в этом случае ничего не показываю. Также у самих областей есть дополнительные параметры, когда ты выбираешь эту область. Например, вот пустая область, видишь, параметров нет. Выбираем место области баннера, динамически подгружаются автоматически данные. И в чем прикол? В том, что ты управляешь, но как бы не вмешиваешься в сам блок. Берешь параметры этого блока, меняешь в этом компоненте и отображаешь как угодно. Что это дает? Один и тот же блок, например, новости или объявления, может несколько раз встречаться на странице, и при этом ты с помощью модификаторов можешь, ну, вот этих параметров и модификаторов задавать совершенно разный вид, разные источники данных, разные отображения, используя один и тот же блок. Понимаешь? Это дает возможность на лету собирать. Это предварительная версия. Следующая версия борщ этого редактора будет, скажем так, более простой для обывателя, это больше для разработчиков. То есть нужно понимать, что это значит. И параметров очень много, обычный пользователь с ума сойдет. Здесь вот как раз модификатор оберток. То есть часть модификаторов нужно просто знать. То есть это мы переключаем бегать. М — это background, модификатор построен по очень простому принципу. Если вот почитаешь, есть сокращение. Вот 10 модификатор, вот они, их просто нужно знать. То есть А — это абсолютная, Б — это граница, БГ — это фон, background цвета, color — цвет, Д — это получается дисплей, Ф — это вот Ф, это не очевидно, но это фил, вот Э — это height, Эль — padding, М — это merging, opacity, П — padding, С — строк, dice. Вот эти совершенно редко используются, типографии и в лифт. Дальше, соответственно, сторона идет live the right to bottom. X — это по горизонтали, Y — по вертикали, а дальше идет значение какое-то значение. Построены так, что они могут идти там от минуса до плюс, ну, максимум 9. И получается, что все очень просто в том плане, что, ну, указываешь ты потом какой-то параметр, потом значение. Ну, то есть если какой-то стране относятся, то есть, например, граница сверху будет быть, потом ширина границы, например, 1, 2, 3, 4, 5. Или, например, цвет границы тебе нужно установить, Б, а потом цвет границ. Но это будет цвет относиться границ. Почитаю, то посмотрите, принцип поймешь. Там, как сказать, даже контент-менеджеры быстро вне к это начинают работать. То есть здесь означает, что мы используем цвет темы. Первый цвет темы **mp4** — это **Martin Bottom**, ну, в смысле отступ снизу четвертый тип и по 1П, Y3 — это означает padding вертикальный Y3 размера. То есть все просто. Цвет темы — это отдельная штука, которая тоже есть только у нас. Это хитрая вещь, которая позволяет на лету перестраивать оформление сайта. То есть можно переключаться с светлой темы на темную тему, и там, где указано **bg тем 1**, она, соответственно, становится фоном. Как сказать, вот **bg тем 1** светом стиль выглядит вот так, вот светлой, беленький, а **bg м 1** тот же самый, как бы этот в темном стиле, он выглядит вот так. То есть он адаптируется к теме. Это позволяет, в общем, на лету выстраивать внешний вид. То есть мы, например, можем поменять светлую тему на темную, он автоматически поменяет все цвета с черного на белый, но и в шрифтов фон поменяет и дальше можно поднастроить. Вот здесь, соответственно, вот по каждому блоку идут какие-то параметры. То есть с помощью этого компонента можно, соответственно, выстроить вот этот грид. Это горячо нас называется, указать, какие блоки где располагаются, в каком порядке, что за чем идет, какие параметры отображения. Ну и, соответственно, внешний вид задается вот здесь. С помощью вот этих параметров задается где-то 80 процентов настроек этих блоков, 20 процентов задается старыми способами. Ну, например, объявлением, и только в таком виде, если используем, они обычного. Вот здесь задаются, то есть у нас разделены там объявление, виде карточек, объявления, виде строк. Они выглядят по-разному, и эти настройки задаются здесь. Это позволяет копировать блоки. Ну, то есть ты берешь один блок, тебе нужно, например, одни и те же данные по-разному отображать, то берешь блок, копируешь, переименовываешь его, меняешь через конфиг, но как бы настройки компонента, его параметры, и он отображается по-другому. Здесь нужно сказать, что у нас есть специальный шаблон. То есть мы используем также универсальные шаблоны. Этого тоже в Битриксе нет, которые позволяют сильно перенастраивать внешний вид отображения элементов, используя один и тот же компонент. По такому же принципу, как **Grid**. То есть вот это самое распространенное — это вот **sf Blog List**. То есть мы вводим перечень элементов инфоблока, дефолт называется, он позволяет вытаскивать данные и настраивать внешний вид. Во-первых, хочу сказать, что во всех компонентах нашего фреймворка мы используем, опять же, отличную систему от Битрикса, работа на кодах. То есть если в Битриксе 3А, кадиш ником все привязывается, ты привязываешь инфоблок, айдишник инфоблока, типа инфоблока и айдишник самого инфоблока, то здесь тип инфоблока привязывается по коду. Видишь, идет инфоблок, тоже привязывается по коду. Что это дает? Это дает возможность копировать данные с одного проекта в другой проект, копировать, использовать вот этот наш универсальный мастер и не задумываться над, скажем, глубокой проблемой Битрикса, что у них айдишники не совпадают. То есть ты, когда копируешь, вставляешь, например, у тебя перестает заработать, потому что айдишник ты не перенастроил. Проходит звезде, проходится, меняй о хищнике. Мы этой проблемы избежали. Это опять же все сделано по правилам Битрикса. У нас есть специальная отстройка, она позволяет на лету менять. На лету менять, ну, то есть здесь уже конкретно инфоблок используется. То есть у нас свои компоненты от **Simai**. **SF** и везде, где **SF** — это компоненты именно фреймворка. Они работают немножко по-другому, ну, как сказать, более расширенно, но по тому же принципу построены. То есть этот **sf Blog List** в Битриксе скин, доработанная система, которая работает с этими кодами. Во-первых, во-вторых, мы используем, в отличие от Битрикса, объектно-ориентированный подход в том плане, что мы превращаем исходные параметры в объекты. Сам шаблон работает с этими объектами. То есть еще одна проблема в Битриксе в том, что ты, например, шаблон делаешь, в нем указываешь свойства, которые используются, и дальше, если, например, пользователь другое использовать название свойств, велико свойства другое, ты с этим свойством работать не можешь. Тебе нужно везде в шаблоне проходить и менять настройки свойств, правильно? Вот здесь вот используется подход именно в этом шаблоне, когда исходные параметры конвертируются в объекты. А сам шаблон работает с объектами, и вообще без разницы, там какие коды, что там, как он, ну, как бы работать тоже по объектному принципу. Сейчас покажу. То есть вот здесь мы задаем параметры, задаем какие-то исходные данные, но это как обычно фильтр и прочее. Дальше пошло то, что отсутствует в Битриксе. Мы указываем вот эти вот объекты области показа. Это как раз объекты, с которыми работает шаблон. Но здесь у нас самые типовые вещи. То есть это, например, изображения, своя иконка, дата, раздел, заголовок, описание, свойства, кнопка. Включаем август для каждого из этих объектов открываются дополнительные параметры, которые включают себя источники данных. Вот, например, источник данных для даты, и система автоматически смотрит все свойства и поля, которые могут данные включать, и ты просто указываешь, что данные берем с даты начала активности. Источник данных для заголовка, она смотрит все подходящие свойства и поля и выводится. Берешь, откуда берется заголовок. Дальше, соответственно, задаешь параметры, например, что там длина заголовка максимально 120, порядок вывода, например, сначала дата, заголовок. Ну, то есть если, например, мы можем указать вот все свойства для сохранять, не буду просто указывать, лишь он погружает все данные. То есть окружают, откуда картинка берется, картинка анонса или детально, переходит на тебя ссылки, например, что будет делать при переходе по ссылке. Просто переход, просмотр изображения, просмотр видео, ну или отсутствует переход, например, источник данных для своего иконки, этот тип файл берет, указывает. Или же, но поле здесь со свагги называет. Источник данных для даты, источник данных для заголовков, но указываем параметры, источник данных для описания, указываем параметр описание, конвертировать, не конвертировать текст, максимально длина, если указано. Здесь весь объект свойства, вот, например, то появляется дополнительно перечень свойств, которые мы показываем. То есть он может вывести все эти свойства. Дальше, соответственно, задаем в каком порядке между собой выводится эти данные. Ну, например, мы можем указать, что будет сначала названием, пример будет заголовок, дата, потом описание, а потом включаем валгас, раздел, свойство, кнопка. Ну, то есть порядок выводу указываем. Дальше использовать, не использовать ссылки, источник ссылки, откуда берется, например, из настройки инфоблока, но если там другое, можно свойства указатель, еще что-то. Вот в новом, не ново, в окне, там теги какие-то могут быть нужны. Вот это все конвертируется в объекты. Вот это перечень объектов будет сам шаблон исходя из параметров этих объектов. Ну, то есть он уже знает, откуда берет данных, создает. То есть есть у компонента файл **Result Modify**, знаешь, да? Вот этот файл **Result Modify**, он как раз проходит по час. Открою этот компонент. Вот он **Simai**. Я почему ему такое внимание уделяю? 90 процентов всех списков сделано всего на одном шаблоне. Список баннеров, список новостей, список объявлений, список галереи партнеров. Вот здесь, если посмотреть главную страницу, сейчас дойдем и до нее. Давайте продублируем, ну, чтобы ты понял значение. То есть вот это, это один и тот же компонент, в котором один и тот же шаблон, в которой меняется только настройки и совершенно разные выводы выдают. Это вот, вот этот шаблон. Вот, например, баннеры, посмотришь, с блок весь дефолт. Это, например, вот этот вот, видишь, иконки, обществ, блоки, дефолт. Это, например, вот новости. Заходим с блок весь дефолт, это вот новость такая. Вот, например, **sf Blog List Default**. Если это, например, может быть вот такие баннеры списком с иконками, **sf Blog List Default** — это один и тот же шаблон. Из массы Битрикса ничего подобного нет. Этот объявлением, например, с **Blog List Default**. Мероприятие, например, заходим с **Blog List Default**. Заходим дальше публикации, но здесь, скорее всего, другой шагов, хотя не знаю, с **Blog List Default**. Ну, хотя здесь, здесь потом покажу. То есть здесь сетка стальные функционал можно делать. Здесь вот есть макет, то есть можно использовать сетку. Здесь вот видишь, параметры идут вот такие. Это параметры берутся из грида. То есть получается, горит сюда передает параметры по отображению, и мы управляем параметрами компонента через параметры грида. Но вообще можно настроить отображение, то есть как это все будет выглядеть внешнем виде. Здесь мы отображаем, как это выглядит, либо это карточки, либо слайдер. Но отличается это тем, что карточки — это вот, ну, вот когда элементы идут один за другим, а вот это вот слайдер, когда элементы идут в слайдере. Вот здесь, дальше, соответственно, мы какие-то параметры даты выводим, там полноэкранный режим. И то это, в общем, используется, когда контент нужно вывести не в рамках вот этого контейнера, а на весь экран. Ну, то есть, например, вот полноэкранный режим, вот этот баннер, пишем, занимает весь экран, а вот это в контейнере находится. **With Animation** — то есть тут, в принципе, есть такая штука, что можно сделать, не знаю, используется, не используется. Сейчас попробую выйти отсюда, по-моему, выключена. Да, сейчас выключено. Но, в принципе, все компоненты поддерживают анимацию. Сейчас посмотрю внешний вид. На здесь отсутствует, да? Попробуем встать и кликнуть. Дата анимация при прокрутке, такие экспериментальные функции, непонятно для чего. То есть это когда прокручиваешь, видишь, все вот так анимируется, но не всех это радует, поэтому по умолчанию эта штука отключена. Но вообще все, все вот эти блоки, которые используются, они уже настроены с анимацией. То есть вот вид анимации, откуда появляется, и не задержка, ну, то есть скорость, с которой появляется. И дальше идут модификаторы. Вот эти как раз по модификаторы, это используется отсюда. Ну, есть frontend, а потом нужно будет на них ориентироваться. Они-то как раз вот эти модификаторы позволяют задать абсолютно любой внешний вид, используя один и тот же шаблон, разные данные, разные контенты, размеры. То есть все строение шаблона разбито на секции, ну, как бы блоки, они вложены друг в друга, и у каждого из этих блоков мы можем задавать модификаторы. То есть сам шаблон предоставляет скелет, с помощью модификаторов мы указываем параметры этого скелета, который, соответственно, внешний вид на лету выстраивается. Вот за счет этого не надо никуда лазить. То есть всегда зашел, например, в любой блок, у него есть дискрипшн, не нужно сидеть вручную прописывать. В принципе, берет, подтягивает зависимости от названия папок, какие-то вещи. Но, в смысле, делает. Единственное, что нужно будет зайти, все-таки его имя указать. Ну, то есть вот здесь вот **Language**, по-моему, тут только ими идет. Да, вот здесь баннер одиночно. Дальше все остальные параметры, они походу подтягиваются. Ну, то есть здесь шаблон зайти, уже у него есть вступительная часть, он подтягивает какие-то данные, а дальше, видишь, но очень простое строение блока. Обычный компонент, в нем, соответственно, живо указывается, например, айдишники. То есть он берет текущие настройки сайта, и это получается у нас настройки для баннера. Если же там используются параметры, то идет сложнее. То есть, например, возьмем какой-нибудь **Header Blog**. Ну и, например, простенькое что-нибудь **For Kleem** или **Or Kleem**. Вот **Or Kleem**. Здесь, видишь, появляется параметр, он определяет, какие параметры подтягивать. Здесь вот один параметр, этот параметр автоматически подгружается в **Grid**. Здесь дефолтное значение пользователь, соответственно, может поменять это значение, и дальше этот параметр, значение этого параметра подтягивается в шаблон, и ты можешь его использовать. То есть вот здесь уже, вот видишь, идет **Blog Property**. Здесь идет **Name Template**. Это, чтобы ты не мучился с кодами, ну, как сказать, с названиями этих параметров, он автоматически подтягивает, как бы, как объяснить. Так как это все выстраивается в рамках одного компонента, но это же все в **Grid** участвует, то может получиться, что если, когда ты используешь одинаковые значения, то эти значения перед записываются. Может, сталкивался с языковыми файлами. То есть второе такое же название перепишет предыдущее название за кого файла, но, в смысле, языка и файл, а параметр языковой, и она будет выводиться. Также здесь, чтобы избежать вот этих дубликатов, соответственно, автоматизирована эта система, ну, как бы выстраивает назначение этих параметров. То есть думать не нужно там особо, и создает их уникальность зависимости от названия папки. То есть вот это **Name Template** — это вечно берет название парке, а название папки — это код, по сути, шаблона. Ну, точнее, код блока. Вот и все очень просто. Но на этом еще не все. Есть такая штука, как представление. То есть, например, мы имеем вот такую компоновку страницы, а мы хотим другую. Мы хотим дать пользователю возможность, например, выбрать такая страница или другая страница. Есть такая штука, как представление. То есть это, грубо говоря, мы сохранили настройки и сохранили под определенным названием. Настройка, например, сборка настройки 1, сборка настройки 2, сборка настройки 3. Это называется подключаемой области. Ой, нет, макеты областей. Вот и здесь вот идут, например, вот шапка сайта. Например, мы хотим, ну, вот такую шапку сайта. Вот вообще убираем, нажимаем сохранить, и у нас шапка должна пропасть. Виде шапки нет. Хотим, например, шапку сайта поменять на другую. Заходим, макеты областей, выбираем вот такую шапку сайта, и оно вот такое делает. Чтоб, видишь, и так мы можем менять, в принципе, ну, любую вещь. **Flash пользовательские поля**, например, какой-нибудь нам здесь определялась, то есть вот добавить, видишь, вот здесь свои. Но здесь используется привязка к разделам в инфоблоке в виде кода и к элементам в виде корт. Тоже пришлось создать, потому что мы не можем привязывать по ID, вообще таких свойств уже больше. Мы здесь просто это, поэтому решение сколько уже год или два? Два года назад, но и вы пустую не обновляли свойства и больше. Сейчас уже вот потом дальше что еще здесь? **И блок копии** — это тоже такая утилита для разработчиков, очень мощная штука, которая позволяет нам, рассказывал, копировать инфоблоки, вставлять, копировать свойства. Она позволяет очень, как сказать, в Битриксе очень много времени занимает настройка инфоблока, добавить свойство, настроить поля, выстроить это красиво, чтобы выглядело. Когда один раз это сделаешь, то второй раз уже не хочется это делать. Этот модуль как раз позволяет экспортировать данные, то есть можно выбрать, какие данные, можно выбрать целую кучу инфоблоков, перенести уже настроенные. То есть у нас все инфоблоки настраиваются определенным образом во фреймворке. То есть если вот сейчас покажу, то есть все типы инфоблоков, они вот так идут: **sf** код языка, ну, код сайта, точнее **ru**, потом идет тип, но баннер, каталог, контент. Дальше идет название той сырого баннера. Если зайти в сам уже тип инфоблока, например, здесь, тут тоже идет все по кодам. То есть опять же **sf** — это название **ru**, это код сайта, бренчат, анусом, этот нас. Они так как система классификация одна и та же на всех проектах, мы можем брать просто целиком, копировать с одного проекта в другой и больше не думать об этом. То есть мы получаем полностью настроенный инфоблок с данными, с контентом, со всеми связями, и делается все это очень быстро. То есть мы можем с нуля поднять за несколько часов проект уже как бы с настройками, сайтами, с контентом, с данными. Вот то есть у нас как раз была в этом случае вот экспериментальный проект, сможем ли мы в течение, ну, как бы за короткое время построить проект. Вот этот проект первая версия был сделан за четыре часа с момента постановки до момента сдачи клиенту. Вам немножко по-другому выглядел, но смысле, но это был достаточно как бы серьезный проект с таким, ну, как бы внешним видом, там с каким-то примочками, сложности. Этот был наш эксперимент. То есть не вечера дали задание, я ночью разработал, т.д. Утром Сиура связался, на проработали структуру с 10, где-то до часу работал, в два часа мы первая версия отдали. **Clean** зайдешь, посмотри, это показывает как раз, насколько это может быть. Дальше имеет еще переделали, то есть это уже как бы не первая версия, она же более наваре, навороченная, содержит танк, прощенный CRM системы, система работы с заявками. Там, то есть их можно уже там как-то перетаскивать, но по разным статусам. Но вот эта первоначальная версия, то что ты в публичке видишь, она была сделана практически за короткий промежуток времени. Это показывает, насколько как бы фреймворк гибкий и мощный. Вот за счет этих кодов и с помощью вот этого как раз модуля можно экспортировать целиком. То есть, например, выбрать, какие нужны, потом с помощью этого файла загрузить, выбрать, например, что загружать. То есть можно внешний вид, там, например, накатить, можно дублировать, можно менять, смену типа инфоблоков проводить. С помощью него же можно переводить на другие языки, можно перевести весь контент инфоблока, например, с русского на казахский. Ну, то есть с помощью **Linux** у тебя будет целиком копия на другом языке. Вот это все входит во фреймворк, а в бэк-энд как раз то, что вот не нужен. А я тебе рассказал устройство бэк-энда фреймворка, ну так галопом по Европе. Дальше, а дума видео я выложу, ну, смысле, посмотришь еще раз, она как раз описывает, что входит в сам фреймворк. Но помимо того, что ты видел, здесь то, что как в айсберге, вся подводная часть. Есть вопросы пока? Не видишь что-то, как работает, не работает? Достаточно просто. То есть если взять на базе этого решения, как это все происходит. Во-первых, у каждого сайта, ну, то есть если брать вот как бы с точки зрения Битрикса, у каждого сайта есть шаблон. То есть заходим настройки сайта, список сайтов, вот он **site.ru**. Здесь, соответственно, стоит **симай фреймворк**. Дальше что происходит? Система берет, подгружается. Сейчас открою этот файлик, то есть так как она знает, что в этой папке должен загрузиться с фреймворк, она загружается. Соответственно, **header** и **footer**. В хедере у нас установлено, что необходимо загрузить модуль **симай фреймворк**, видишь? То есть погружается все классы, все методы, необходимые для работы фреймворка и подгружается, вот видишь, решение. То есть сыр **solution**. Этот старой версии используется, в новый уже, по-моему, нет. Давай новый открою, сейчас помню, что он основу **sf4** библию. Помогу просто сейчас решение. Мери Ринат уже больше занимается и командует с **yours**. Так, все загрузится. Так, расскажу там отличие есть, ну как бы как это сейчас происходит. Но не на небольшое тоже, он определяет модули, которые необходимо подгрузить. Такси, мая приварка, симай **solution**. Соответственно, когда эти модули подключаются, начинает загружаться файлы, которые входят в сам модуль. То есть если посмотреть модуль, у каждого модуля есть обязательная папка **or file in cloud** называется. Вот, например, **симай фреймворк**. У него есть **in cloud**. В **in cloud** это то, что грузится при подключении модуля. Здесь описано, что нужно сделать. Соответственно, когда **7 framework** грузится, начинает подгружать классы. Здесь вот описан перечень классов, которые загружаются. Дальше система может работать с этими классами. Здесь обычно подгружается еще второй модуль — это модуль решения, ну или проекта какого-то тоже через **input**. И здесь, соответственно, тоже есть какие-то действия, которые выполняют. Здесь вот видишь, это сейчас при объединении модуля перенесена уже, но здесь вот показана, что еще может вспомнить с **4**. Может здесь последний раз трус, последние версии мы оказали этот отказались от одного параметра, но это достаточно сильно все поменял. Вот подгружается, да, видишь, называется уже шаблон, называется просто **симай прибор**. И он один для абсолютно любого проекта. Носимая **from word**. То есть днем погружается **header**, в главной **futari** слева, там сверху, ну то есть это одна у вас **header**. Этом пошел **home** снизу, это **footer**. Если ты во внутрь заходишь, этот как раз используется. То есть у нас на главной странице на показано, что мы не используем колонки. Она всем на всем сайте, мы используем колонки. И когда мы переходим с главной вовнутрь, у нас появляется левая колонка, потому что только у главной странице есть параметр не использовать колонки. То есть если ты зайдёшь, например, настройки сайта, здесь у нас вот есть макеты. Вот макет сайт, видишь, мы используем и левую колонку, и правую колонку. Ну и здесь, соответственно, отображение по-моему стоит там левы, смысле мы используем. Это вот колонки внутри находятся. Здесь, по-моему, вот это должно стоять, нос послед. Или здесь стоит, для главной это сейчас помню, какая-то вообще логика там просто по-разному можно делать. Можно установить для всего сайта и для страницы сделать исключение. Но ответ здесь не отображает, стоит такая видимо схема параметры. Скорее всего, не на сайт распространяются, а да, здесь вижу, здесь установлено. То есть мы можем на сайт установить, но эту отверстие зависит, потому что фреймворком модифицировался со временем и вырабатывались наиболее оптимальные алгоритмы и методы использования. Вот и дальше, соответственно, страница погружается. То есть я показал здесь области, а здесь вот еще, еще есть лишь вот этот гриб. Есть это **live grid**. Вот этот грех и вот этот гриб. Причем в зависимости от колонок, но смысл, например, мы можем в разделе, то есть тут у нас было указано, что колонка съела, но также с успехом колонка может находиться слева и справа или только справа. Меня здесь поменяю, растут указано, например, вот здесь вот она будет справа. Ничего делать не нужно, сайт автоматически перенастраивается на лету, собирается. То какая же надо, иногда чистить нам здесь, видимо, какие-то настройки перенастроены. Да, вот здесь явно получается, что есть в корне настройка. То здесь вот, которые показал, давай вернем, как бы мог, а есть, скорее всего, еще в центре села. То есть в центре зайти, возможно, здесь тоже есть, раз она не давала перенастроиться. Да, видишь, она нажата. Ну, то есть она блеклая должна быть, но здесь она указывается, как вот здесь должно быть. Вот дальше все это собирается. Фактически тебе по большей части нужно будет собираться компонентов нужной страницы. Причем 90 процентов всего готово уже. То есть нужно просто знать, где что есть. Для этого как раз Маргарита начала собирать **in forest**. Специально шаблоны называются. Может быть, она его соберет. Вот оно здесь будет показано. Я не знаю, пока она сделала, пока не сделала. Тут будет показано, какие шаблоны где используются. Но вообще у нас была такая цель, ну, может, у тебя появятся силы и возможности сделать на сайте на сайте **sf4**, где мы часто бэк-энда, где будут представлены разные представления разных данных. Но как бы собрать вот эти все варианты отображения какого-то месте, чтоб можно было копировать и вставлять. Вот, то есть львиная доля работы — это по сути копировал, ставил, изменил настройки, параметры, подкрутил нас масел и все как нужно. Поэтому вот в этой структуре нужно разбираться самому. Программирование тут редко появляется, но как бы, то есть иногда нужно скопировать какой-то шаблон и создать свою вариацию. Но это будет только вариться. Но это надо подумать, потому что сам фреймворк позволяет собой подключать всякие данные, делать, менять, отображения. То есть, например, вот здесь вот, и вот это отображение, и вот это отображение — это один и тот же шаблон, один и тот же компонент, который вот этот **лист дефолт**. Они за чуть-чуть поменяли теги, ставятся, но это тоже поменяли исключительно для образовательных организаций, потому что здесь прописываются автоматически теги в коде, которые должны считываться автоматизированной системой. Но это тоже можно было сделать с универсальным шаблоном, но видимо Юра решил не заморачиваться. Вот так это все собирается, делается на лету. Тут, в принципе, устройство понятно. Есть вопросы? Попадание? Ладно, но если будут, не стесняйся, спрашивай. Я, в принципе, запись вроде как, надеюсь, сделал. Есть, выложу их.

Назад

Залогинтесь, что бы оставить свой комментарий