я бы все-таки вынес бы HTML из кода класса, например, в config_html.php
Логично - подумаю, что и как можно вынести. Ведь вывод не обязательно должен быть html...
по-моему лучше более развернутые имена давать
Двумя руками - за. В этом месте я просто поторопился.
У php оказалось нехорошее поведение при возникновении ошибок синтаксиса: fatal error без возможности перехвата. Это меня несколько разозлило и, пока искал методы борьбы, не особо старался.
Насчет имен. Т.к. код практически весь сосредоточен в классах, а глобальных имен я использую минимум (да и для использования их нужно объявлять global или использовать $GLOBALS), то видимость имен переменных ограничена ф-ией. Из-за отсутствия в php4 контроля доступа и видимости членов класов, я использую следующее соглашение: private члены начинаются с '_'; public - с буквы; private члены, которые предназначены для специфических ф-ий - с двух '_'.
С настройками я до конца не определился.
Основная идея: если _модуль_ привносит своим кодом какой-либо функционал, то и настройки этого функционала должны принадлежать ему. Так, я предпологаю, можно изменять отдельные модули, добавлять в них функционал и соотв. им настройки не касаясь других модулей. Т.е., в принципе, апгрейд можно лекго сделать на ходу, используя только простую общую логику, а специфичную логику - только в исключительных случаях (изменения базы и т.п.).
Если какой-либо компонент системы подгрузит модуль, то ему будут доступны и его настройки, а иначе, если ему не нужен модуль, нафига ему его настройки...
Конечно, нужно хорошенько подумать и разложить все по полочкам. И с именами определиться. С одной стороны, не хочется использовать длинных имен, а с другой стороны - должен быть порядок.
Может я слишком сильно пытаюсь сделать все единообразно?
Пиши свои соображения.
Посмотри еще ф-ию core__config::proc_dir() - это архаизм от ранних вариантов. Удалять пока не тороплюсь, но применения уже не вижу.
Модуль ядра у меня на текущий момент состоит из: class.php (с классом и прочим кодом), config.php и macro.php (для различного кода вне классов). Последние два - не обязательны.
Модули config и core я не объединяю в единый блок по след. причинам:
1) чем меньше файл, тем легче с ним работать (core/class.php уже до 10кБ дорос);
2) эти классы выполняют разные ф-ии.
Я собираюсь в базовый комплект включить еще третий модуль. Он должен стать прослойкой к коду более высокого уровня. Сервисы сервисами, а надо заранее подумать и о том, что будет их использовать и какие правила для этих блоков определить.
Спасибо за критику и поддержку: +1