Своя логика и где её хранить. init.php не резиновый

Причем инклудить эти файлы желательно через __autoload.
Штатными средствами это делается так:

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

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

ЗЫ: Раньше так и делал пока не начал активно пользоваться гемами. Теперь перетащил все в приватные гемы. Но эт из серии "кто о чем, а вшивый о бане"

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

На своих проектах использую структуру, описанную в конце поста о VCS. Оч удобно

С банальным коллбеком все понятно, но вы то пишите "Когда у вас есть классы, единые для нескольких сайтов (при многосайтовости, или на одном сервере), то для удобства сами файлы с классами располагаем лишь в одной папке, далее создаем символические ссылки."

Я так понял, что имеется своя либа наработок над API Битрикса. Соответственно ее логично обернуть в модуль, а не в шаблон.

Если я что то не так понял, тогда "ой". Но пихать свои наработки кода в шаблон - неправильно сто процентов.

Владимир Савенков,
скорее всего вы путаете понятия "шаблон" и "каталог на диске". Да и я выразился фигурально.

Но дело в том, что данная фраза должна пониматься так:
а если вам при многосайтовости лень делать символические ссылки, да и смысл их плодить то, воспользуйтесь уже готовыми "общими физическими директориями";)
и при втором и первом способах include $_SERVER["DOCUMENT_ROOT"]."/bitrix/templates/..." ведет в одно и то же место для всех сайтов, где можно разместить общие для всех проектов файлы. В том числе никто не мешает создать свою папку для своих классов и уж оттуда их инклудить.

Для системы с точки теоретически это "шаблон", для нас - просто общее хранилище.

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

По мне - записей 1 и 2 достаточно в данной ветке вполне достаточно, чтобы уже не быть скованным.

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

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

Не совсем понял, получается кто-то за разработчика должен выбирать инструмент?  

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

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

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

Вот еще одно "нетрадиционное решение", правда к сабжу не совсем подходит, так как не затрагивает init.

Для случаев, когда требуется легко переносимая библиотека общих классов (или даже несколько бибилиотек, независящих друг от друга), а лезть в модули или init.php не хочется:

В битриксе есть еще один интересный объект - компоненты.

Можно создать свой компонент (без шаблонов, т.к. они не понадобятся), внести классы к тело компонента, а затем просто подключать его в необходиымых участках.
(можно подготовить несколько компонент, включающих различные классы)
Чтобы компонент(ы) на замусоривал публичку, убиваем description или корректируем в соответсвии с рекомендациями Ban Dmitry
http://dev.1c-bitrix.ru/community/webdev/user/10337/blog/2409/#18462
или смотрим записи Максима Месилова
http://dev.1c-bitrix.ru/community/webdev/group/107/forum/message/33375/185717/#message185717


Данный прием понадобился лишь пару раз, когда создавал комплект компонент, использующих общие API (соответсвенно для общих API был сделан "системный компонент", включающий общие классы)