Где-то с полгода-год назад мне конкретно так надоело плодить компоненты, перетаскивая один и тот же функционал. Даже писал мастер создания компонента, который бы учитывал, нужен ли выбор ИБ, какие параметры еще есть, а потом я становился умнее, Битрикс становился сильнее, и приходилось многое на текущих проектах пересобирать. Надоело, и я решил сделать универсальные штуки.
[spoiler]
Вы не поверите, но создание всего двух компонент (список и детально) полностью решили мои проблемы. Вся работа сводится фактически к созданию шаблонов. Есть еще маленький компонент формы, но он в очень зачаточном состоянии, так как его улучшения не требовались. И есть обертка комплексная, для списка и детального. Этакий скелет любого каталога. Тут особой универсальности добиться уже не удалось, и, если требуется, например, вместо 3-х ЧПУ страниц 5, то приходится выносить компонент в свое пространство. Но выносить только комплексный.
Изредка конечно чего-то не хватало, тогда я прибегал к помощи component_epilog.php да result_modifier.php. Но, справедливости ради, замечу, что их использование примерно равно, если бы я использовал стандартные компоненты. То есть логики в них не стало больше.
Спросите почему я не использую стандартные компоненты Битрикса. Потому что я их вообще никогда не использовал. Потому что универсальность всегда накладывает определенные минусы, один из которых - скорость. В общем, не будем о грустном
Очень сильно в моей идее мне помогли управляемое кеширование (когда не надо особо заботиться об идентификаторах), component_epilog, и некоторые другие моменты.
Инкапсуляция функционала позволила мне с легкостью улучшать основные проекты разом. Например, когда ввели возможность дергать файлы GetList'ом, я улучшил списочный компонент и избавился от десятков запросов. Ввели Эрмитаж, он появился и у меня. Круто, не правда ли?
Есть и минусы. Вместо списка компонент, получаем список разных шаблонов одного компонента. Но это я бы не назвал минусом. Есть второй минус - клиенты не получают той универсальности, которую им дают стандартные компоненты статей и новостей. Но никто не жаловался, да я и не считаю, что клиенту оно надо.
Вы скажете "наверное, там куча кода". Отнюдь. 194 строчки в списочном и 170 в деталньом. И это все полностью решает мои задачи последние полгода. Возможно, я халявно работаю
но по проекта не сказал бы.
По определенным причинам я не хочу выкладывать эти компоненты. Прежде всего потому что они довольно сильно заточены под мой стиль работы, они удобны мне, и вряд ли будут удобны вам.
Поэтому всему, я честно ответил одному человеку, который недавно стукнул мне в скайп с вопросом "нет ли у тебя каких-то прикольных компонент, которые я могу заиметь?". Я ответил "нет", потому что у меня всего два компонента.
После многабукв выкладываю скрины настроек. Как вы можете видеть, интерфейс заточен под разработчика. Есть и определенно бредовые опции. Но это уж дань невозможности откатиться назад.



[spoiler]
Вы не поверите, но создание всего двух компонент (список и детально) полностью решили мои проблемы. Вся работа сводится фактически к созданию шаблонов. Есть еще маленький компонент формы, но он в очень зачаточном состоянии, так как его улучшения не требовались. И есть обертка комплексная, для списка и детального. Этакий скелет любого каталога. Тут особой универсальности добиться уже не удалось, и, если требуется, например, вместо 3-х ЧПУ страниц 5, то приходится выносить компонент в свое пространство. Но выносить только комплексный.
Изредка конечно чего-то не хватало, тогда я прибегал к помощи component_epilog.php да result_modifier.php. Но, справедливости ради, замечу, что их использование примерно равно, если бы я использовал стандартные компоненты. То есть логики в них не стало больше.
Спросите почему я не использую стандартные компоненты Битрикса. Потому что я их вообще никогда не использовал. Потому что универсальность всегда накладывает определенные минусы, один из которых - скорость. В общем, не будем о грустном

Очень сильно в моей идее мне помогли управляемое кеширование (когда не надо особо заботиться об идентификаторах), component_epilog, и некоторые другие моменты.
Инкапсуляция функционала позволила мне с легкостью улучшать основные проекты разом. Например, когда ввели возможность дергать файлы GetList'ом, я улучшил списочный компонент и избавился от десятков запросов. Ввели Эрмитаж, он появился и у меня. Круто, не правда ли?
Есть и минусы. Вместо списка компонент, получаем список разных шаблонов одного компонента. Но это я бы не назвал минусом. Есть второй минус - клиенты не получают той универсальности, которую им дают стандартные компоненты статей и новостей. Но никто не жаловался, да я и не считаю, что клиенту оно надо.
Вы скажете "наверное, там куча кода". Отнюдь. 194 строчки в списочном и 170 в деталньом. И это все полностью решает мои задачи последние полгода. Возможно, я халявно работаю

По определенным причинам я не хочу выкладывать эти компоненты. Прежде всего потому что они довольно сильно заточены под мой стиль работы, они удобны мне, и вряд ли будут удобны вам.
Поэтому всему, я честно ответил одному человеку, который недавно стукнул мне в скайп с вопросом "нет ли у тебя каких-то прикольных компонент, которые я могу заиметь?". Я ответил "нет", потому что у меня всего два компонента.
После многабукв выкладываю скрины настроек. Как вы можете видеть, интерфейс заточен под разработчика. Есть и определенно бредовые опции. Но это уж дань невозможности откатиться назад.


