Хотел бы посоветоваться на счет оптимальности.
Имеем CMS. Имеем index.php.
Вопрос в том, как лучше организовать ЯДРО системы. Ядро в моем понимании - функции, которые необходимы при каждом запуске скрипта и ылияют на его работу.
Раньше я делал как..
Создавал отдельно объекты для URI, TMPL, дополнительных функций, плдюс два массива с конфигурацией и лэнг-пак. И каждый класс описывал в отдельном файле.
Щас думаю все это объедигнить в один класс.
Что в нем должно быть:
- парс URI (с сохранением параметров в свойствах объекта).
- TMPL парсер (тут вопрос, а включать ли сюда парс BB кода или нет?).
- "Скелет" скина.
- Функции авторизации и персонализации пользователей.
- Функции проверки конфигурации, редиректа, установки кук.

Что скажете?

а зачем объединять? а если понадобятся функции парсера темплейтов без всего остального?
может держать эти классы отдельно и создать класс (ядро), который будет иметь по экземпляру от каждого класса?

Цитата(Irokez @ 4.6.2005, 22:22)

а если понадобятся функции парсера темплейтов без всего остального?

Это как так?

Цитата(Irokez @ 4.6.2005, 22:22)

создать класс (ядро), который будет иметь по экземпляру от каждого класса?

Как-то это запутанным мне кажется...

Я тогда уточню. Сами функции могут быть использованны только внутри системы.

Mal Hack
добавил бы ещё работу над ошибками. аля try, catch, вывод на экран при дебаге, запись в файл при "релизе"

Цитата(Opr @ 4.6.2005, 22:41)

обавил бы ещё работу над ошибками. аля try, catch,

Да, думаю ты прав.
Спасибо.

Цитата(Opr @ 4.6.2005, 22:41)

вывод на экран при дебаге,

Не совсем тебя понял. Выводит index.php.

Цитата(Opr @ 4.6.2005, 22:41)

запись в файл при "релизе" smile

Тоже не совсем понял

Mal Hack
да, немного коряво выразился.
Хотя это не везде и нужно.
Грубо говоря, при отладке скрипта - error_reporting(E_STRICT) // PHP5, иначе - 0, т.е полное их подавление, можно даже display_errors - off и запись в файл. Если оные всё таки будут возникать.

Добавлено @ 21:51
Т.к пользователю они могут ничего не сказать, а тебе помогут уж точно)

Это в index.php будет. Если в конфиге стоит параметр "debug", то будет вывод ошибок, а в противном случае нет.
ЗЫ: А что ты там на счет файлов говорил?

Mal Hack
Это в index.php будет - без разницы где.

Цитата

Если в конфиге стоит параметр "debug", то будет вывод ошибок, а в противном случае нет

а в противном случае фиксируем возникшие ошибки - пишем error.log (если к оному от апача нет прав)

Цитата(Opr @ 4.6.2005, 22:58)

а в противном случае фиксируем возникшие ошибки - пишем error.log (если к оному от апача нет прав)

Я думаю это на будущее... За идею спасибо.

Цитата(Opr @ 4.6.2005, 20:41)

добавил бы ещё работу над ошибками. аля try, catch, вывод на экран при дебаге, запись в файл при "релизе" smile

Так удобный логгинг в PHP уже есть, в релизе пишет в лог файл. Зачем своё, да ещё ошибки синтаксиса заноситься не будут...?

Mal Hack
по идее нужен ещё интерфейс для работы с базой.

Цитата(Opr @ 4.6.2005, 23:10)

по идее нужен ещё интерфейс для работы с базой.

Это отдельный класс. В ядро не входит.

Цитата(Sardar @ 4.6.2005, 23:05)

Так удобный логгинг в PHP уже есть, в релизе пишет в лог файл. Зачем своё, да ещё ошибки синтаксиса заноситься не будут...?

Я так понимаю, тут лог ведется на ошибки системы, которые обработал скртипт.
да и к тому же если появляются ошибки PHP это недопустимые вещти для хорошей системы.

Цитата(Mal @ 4.6.2005, 21:12)

Я так понимаю, тут лог ведется на ошибки системы, которые обработал скртипт.

Я всегда использую trigger_error функцию. Доволен, уговаривать не буду

Цитата(Sardar @ 4.6.2005, 23:14)

Я всегда использую trigger_error функцию. Доволен, уговаривать не буду smile

Так. стоп.. Что ты пишешь в лог?

Mal Hack
если юзает trigger_error - вроде ничего