да в общем-то хотелось описывать связи через в orm и иметь стандартный битриксовый интерфейс работы с HL почему-то подумал, что это совместимые штуки, но, кажется, приснилось)

минус одна загадка

а как сделать поле UF_ID с auto_increment для HL ИБ?

Никак

вопрос отпал

ID записи у вас в любом случае будет

)

уже попробовал)

Привязка к Иб идет по полю UF_XML_ID

Если что

привязка к HL?

ну да, логично

а xml_id обычно на автогеренацию настраивают?

это обычное свойство HL?

да в общем-то хотелось описывать связи через в orm и иметь стандартный битриксовый интерфейс работы с HL почему-то подумал, что это совместимые штуки, но, кажется, приснилось)

Для любой таблицы можно описать класс орм

да, вы правы, думал, как обойтись без UF_

каким образом можно реализовать наследование стилей в битриксе?

т.е общие стили на нескольео шаблонов сайта?

~/css/main.css и подлючать его во всех шаблонах Bitrix\Main\Page\Asset::getInstance()->addCss('/css/main.css');

только так?

Дефолтных каких то битриксовых возможностей нет?

плюсег

Насколько мне известно, только так.

Можно извращаться. Но оно вам надо?

Мы делаем просто

Свой класс, где подключаются все ассеты, в разных шаблонах вызывается от него метод установки ассета

Как вам картинка

А почему одни блоки обведены жёлтым, а другие зелёным?

а где легенда? =)

В первом блоке copmonent, ошибка в слове

Картинка яд)

Бизнес логика - это часть модулей?

SQLзапросы то же самое...

Бизнес логика - это часть модулей?

А разве нет?..

Ну в таком виде написания нет

модули: iblock, sale, main

или уже без модулей

надо упомянуть, что component_epilog не кэшируемая часть, исходя из схемы это очевидно бывалому разработчику

но не новичку

Как вам картинка

Отличная...

В первом блоке copmonent, ошибка в слове

спасибо

Легенда такая

- $arResult(**) – в кеше сохраняется не весь arResult, а только те данные, которые используется в некешируемой части! Иначе растет файл кеша и нагрузка от его парсинга. В component_epilog.php будет доступен именно этот arResult, а не «полный», как в template.php - result_modifier.php – нужен чтобы дополнить arResult типового компонента нужными вам данными для использования в шаблоне. В template.php поступит дополненный массив $arResult(*) - result_modifier.php и template.php – не исполняются когда хит попадает в кеш, сразу берется итоговый HTML, а значит нет смысла вызывать в них отложенные функции, они не исполнятся. - component_epilog.php – не кешируется, можно расширить логику типового компонента, необходимую на каждом хите, но будет не верно реализовывать в нем ресурсоемкий код, все «тяжелое» должно кешироваться. - $arResult (**) – если вам нужные данные в component_epilog.php, но их там нет (компонент не кеширует), то их можно добавить в кеш из result_modifier.php

А почему одни блоки обведены жёлтым, а другие зелёным?

зеленые - не исполняются на хите в кеш

тогда почему первый component жёлтый?

Иван, а не думали, что вот эту идею с эпилогом и модифаером стоит пересмотреть в рамках D7, все же есть наследование, колбеки и много других возможностей, как вклиниться в код компонента, чтоб его не править.

Ну в таком виде написания нет

Исходил из того что модель это все же модуль.

тогда почему первый component жёлтый?

потому что файл вызывается, а показывать что часть нет - не такой уровень абстракции схемки

может component.php на три части разделить?

Иван, а не думали, что вот эту идею с эпилогом и модифаером стоит пересмотреть в рамках D7, все же есть наследование, колбеки и много других возможностей, как вклиниться в код компонента, чтоб его не править.

Логично, но я тут не отвечу за разработку, реально или нет и какие планы

может component.php на три части разделить?

class.php может?

может component.php на три части разделить?

можно попробовать

class.php тоже хорошо, но он сейчас вообще вне этой схемы))

а для совместимости пускай component.php останеться как есть

class.php может?

да, можно

Мне кажется, пока самые часто используемые штатные компоненты без class, в схеме важно показать вариант работы без него

Вот знаете, что еще очень надо? возможность удаления стандартных параметров по средством обнуления их в файле .parameters.php шаблона.

Мне кажется, пока самые часто используемые штатные компоненты без class, в схеме важно показать вариант работы без него

тоже хорошая мысль

Добрый день! Подскажите, если у товара уже созданы торговые предложения, то у этих тп параметры (вес, габариты) массово никак не заполнить? Т.к. чаще всего предложения различаются цветом, а габариты и вес одинаковый

Добрый день! Подскажите, если у товара уже созданы торговые предложения, то у этих тп параметры (вес, габариты) массово никак не заполнить? Т.к. чаще всего предложения различаются цветом, а габариты и вес одинаковый

через апи лупани

а те что цветом - сгенеррируй в генераторе СКУ

Мне кажется, пока самые часто используемые штатные компоненты без class, в схеме важно показать вариант работы без него

не, без class любой друка напишет а вот с классом сложнее

не, без class любой друка напишет а вот с классом сложнее

почему сложнее?

значит я дурак, но так и не дошли руки постич

как по мне использование ООП подхода в компонентах - отличная вещь

Лучше - преотличнейшая вещь

ERROR: S client not available

Тоже не поняла, почему сложнее) и насчёт любого — это очень оптимистично, это же схема для обучения новых разработчиков, а не для развлечения существующих

а в эпилоге точно SQL запросы нужны, они не закешируются?

Вы наследуете нужный вам класс, возможно и Base (базовый для компонентов) и там уже есть основная логика

а переопределяете только нужную Вам часть

Вот знаете, что еще очень надо? возможность удаления стандартных параметров по средством обнуления их в файле .parameters.php шаблона.

Ребят, я в прямом виде не могу повлиять на продукт. Ну типа приду в разработку и такой "там ребята в чате пишут, надо, сделайте". Но при этом очень хочется сделать открытый диалог и менять продукт под реальную потребность разработчика. Не "хорошо бы нам...", а "ну так жмет что сил нет терпеть, тут нам поможем вот такая возможность/API" Есть такая потребность, чтобы вот прям всем нужно и реально полезно, например времени сэкономите в каждом проекте. _Одна потребность_, чтобы не распыляться сейчас.

если она не final функция конечно )

а в эпилоге точно SQL запросы нужны, они не закешируются?

так..... и вы уже сдали экзамен №2?

Ребят, я в прямом виде не могу повлиять на продукт. Ну типа приду в разработку и такой "там ребята в чате пишут, надо, сделайте". Но при этом очень хочется сделать открытый диалог и менять продукт под реальную потребность разработчика. Не "хорошо бы нам...", а "ну так жмет что сил нет терпеть, тут нам поможем вот такая возможность/API" Есть такая потребность, чтобы вот прям всем нужно и реально полезно, например времени сэкономите в каждом проекте. _Одна потребность_, чтобы не распыляться сейчас.

Верно говоришь. Просто вот сижу сейчас проект делаю, компонент сделал, параметры еще пустые, а открываешь и там уже список на 2 экрана почти :(

Ребят, я в прямом виде не могу повлиять на продукт. Ну типа приду в разработку и такой "там ребята в чате пишут, надо, сделайте". Но при этом очень хочется сделать открытый диалог и менять продукт под реальную потребность разработчика. Не "хорошо бы нам...", а "ну так жмет что сил нет терпеть, тут нам поможем вот такая возможность/API" Есть такая потребность, чтобы вот прям всем нужно и реально полезно, например времени сэкономите в каждом проекте. _Одна потребность_, чтобы не распыляться сейчас.

Ха ха ха

а я то думал...

а я то думал...

ну что тут думать, Иван не продакт менеджер проекта БУС, все логично.

так..... и вы уже сдали экзамен №2?

нет)

нет)

эвоно как...

я ж не просто так первых хвалю, не до него

насколько я помнб логику ядра данные после result_modifer кешируются

в эпилоге данные уже из кеша идут

соответственно сомневаюсь что они потом добавятся в кеш

насколько я помнб логику ядра данные после result_modifer кешируются

--

ну а как?

template.php не считаю

т.к. это вьюха

логики там быть не должно

result_modifier.php последний файл для изменения логики или ее дополнения, который кэшируется.

мой вопрос имено про component_epilog и резонности в нём SQL запроса

мой вопрос имено про component_epilog и резонности в нём SQL запроса

если такой запрос необходим на абсолютно каждом хите и он не большой - можно

если такой запрос необходим на абсолютно каждом хите и он не большой - можно

ну я это и сказал

а в эпилоге точно SQL запросы нужны, они не закешируются?

тут ничего такого небыло

ладно упустим полемику, истинна одна.

что там SQL запрос сомнительный, и больше как возможость исключения "а в эпилоге точно SQL запросы нужны, они не закешируются"

Лучше - преотличнейшая вещь

+100500

если такой запрос необходим на абсолютно каждом хите и он не большой - можно

хмм.. правда? или всетаки антипаттерн?

чтож это за запрос такой, который необходим именно на каждом хите, в реалтайме стопроцентно не обрушит при желании сайт.. чтото я сходу даже не придумал..