Собственный компонент VS Стандартный (модифицированный)

Берешь стандартный компонент и пилишь его под свои нужды. Зачем выдумывать велосипед?)

Но еще лучше пробовать через result_modifier.php + события делать, тогда можно переносить наработки из проекта в проект плюс получать доп. обновления функционала.

Да и доделывать после кого-то проект приятнее, когда на нем стандартные компоненты, а не пытаться угадать где и как их модифицировали

Левый Иван,  смотря какой функционал. Смысл модификацию класть в result_modifier, если там опять таки будет куча запросов?

Все надо делать адекватно и думая о последствиях.

Смысл есть если result_modifier расширяет, или дополняет стандартный функционал.
Если уже часть кода написана (например, создан компонент, иконка компонента, его описание, параметры, и тд), даже если используется только его малая часть (даже 20%) то не вижу ничего похого в том, чтобы остальные 80% написать в result_modifier.php.

Что потом делать с этим компоннетом (который мы модифицировали или сами написали), если он не универсален? будет ли он использоваться потом на других проектах, или это частное костыль-решение? Если частное - то в моем понимании, правильно вынести это в result_modifier.php. А компонент делать только если это уникальный функционал, которого в Битриксе нет.

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

Эта тема уже неоднократно обсуждалась

Противопоставляя собственный компонент стандартному, вы просто выбираете оптимальное соотношение с точки зрения экономии разработки (99% потерь на создание взяли на себя разработчики данного компонента) и противопоставляете им потери в процессе эксплуатации (по нагрузке или еще каким то параметрам)

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

Есть такие result_modifier, за которые руки бы вырвал писателям.
Когда доработка приводит в увеличению потерь производительности в десятки раз, у меня возникает вопрос: Стоит ли это той экономии?

Резюмирую:
либо экономим на разработке
либо оптимизируем производительность (В противном случае я не понимаю нужды писать свой компонент)

P.S. Внимание! Случай, когда свой компонент создается для реализации собственного уникального функционала я не вписываю в рамки данного сообщения

Коваленко Алексей,  видел чудесные result_modifier, сделанные поверх news.list, которые чистят весь $arResult и забивают новыми данными. =)

Евгений Зацепин, да я именно такие прелести и имел в виду
+ сюда еще отключенное кеширование потому, что с включенным почему то что то не работает а что понять что то не получается

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

,
Алексей Задойный, я имел в виду какой-нибудь модифицированный result_modifier в стандартном + отключенное кеширование.
Так как почему то при включенном кешировании начинаются баги
Пару раз попадались проекты с повсеместно отключенным кешированием
Зато быстроделаные

да я понял.
Просто отметил, что те, кто такие резалт_модифаеры курочат обычно и свои компоненты лабают абы как.
Я тоже встречал такие приколы, как вы описываете. Обвинять никого не хочется, ибо всегда бывают пережатые сроки, невнятные ТЗ и т.п.

Коваленко Алексей,  чаще всего выставление мета-тэгов.. Под админом без кэширования в result_modifier выставляются, с включенным конечно нет ) Поэтому кэширование - долой )

Все зависит от проекта и сложности бизнес логики. Для своих проектов пишу все свое.

А скорость сайта?
Пробовал пойти по такому пути, твердо решил. Но прежде заглянул в код и узнал что происходит при высчитывании (например) скидки - стало грустно, закрыл код и больше не возвращался.

Это не плохо и не хорошо. Это универсальность. У универсальности всегда есть свои минусы.

PS: Но если под КАЖДЫЙ проект пишутся свои компоненты - это нифига не рационально. Я давно с нуля уже не писал компоненты, свои использую, где "все только то, что нужно".

Лисицкий Денис,  святые слова =))

Все мы через это проходим, я изначально стараюсь делать все на стандартных, а вот где начинаются тормоза, там обрубаю все лишнее, иначе бывало, всплывали косяки, когда сайт разрастается до нескольки штук с коллективным пользованием, с проверкой прав и т.д. и т.п.
Еще и потому что, после того как отдашь сайт клиенту еще несколько раз там половину переделаешь, то так, то сяк, пока все понравится, обкатается, замучаешься на своих компонентах добавлять параметры, обрабатывать их и т.п.
Выросла посещалка, начало что-то тормозить, вот, пожалуйста, делаем то-то и все будет ок, иначе изначально клиент может быть не готов пожертвовать ради скорости в каталоге кнопочками для редактирования, изменением настроек, сортировок и прочей красотой, нужно что бы он уже был готов к этому, потом он сам напишет, с вопросом, как и что нужно сделать, чтобы это работало быстрее, я будет на все готов