Ответы:
Ядро лучше и с точки зрения стабильности системы. (чтоб "кривой" модуль не уронил всю систему) . Так же и с точки зрения отладки.
Опять же Ядро решает неизбежные апгрейда.
Да, на счет апгрейда я думал и о стабильности думал... но и там и там есть плюсы минусы... мне кажется я не всю картину могу видеть, посему хотел бы услышать видимость плюсов и минусов каждого... да и ваще прошу раскрывать ответы... До таких банальных вещей я и сам додумался :)
P.S. может блог и правда по данной теме заветси...
опишите, какие плюсы и минусы видите Вы...
может быть и мы потом что-нибудь добавим :))
ко мне мона на "ты"
ядро плюсы:
стабильность
легкость апгрейда
функциональность CRM
ядро плюсы:
+легкая разработка новых модулей
+типизированные средства отладки модулей
+единая структура стандартов, что позволит легче разрабатывать модули разным людям
+единое документирование
+использование ядра в других проектах :)
единый интерфейс, при рассмотре модулей, может заключаться в нескольких строках, определяющих нужный модуль и его запуск.
Адаптация чужих модулей - это написание переходника с одного API на другой, что увеличит время обработки.
P.S. всерьез задумался над блогом.
Хотя используя ядро, можно лучше контролировать входные данные в одном мсте, не писать под это дело отдельный класс...
>единый интерфейс, может заключаться в нескольких строках, определяющих нужный модуль и его запуск.
это предположение :) которое может иметь место, а может и не иметь...
все зависит от серьезности проекта :)
при сквозной регистрации не погрязну, как и с увеличением модулей. Ибо мне достаточно будет написать один модуль, отвечающий за авторизацию пользователей, который будет применяться ко всем страницам.
По поводу увеличения модулей и доработки напильником - палка с двумя концами. Та же беда может случиться и с использованием ядра, только в первом случае, я тупо переделываю модуль и забываю, во втором мне еще придется выеснять кто на каком этапе глючит и, если это все же модуль (в 90% так и будет) так же его ковырять. Так что не сильный аргумент мне кажется...?
Хотя можно продолжать и здесь =) Туда буду цитировать и более осмысленные мысли выкладывать.
А если писать ядро, то ему понадобиться строго ограничивать параметры входа.
Т.е. надо изначально продумать, что первым параметром будет имя модуля, вторым id объекта, третим некие действия... и только этим ограничиться?
Ну вот допустим, те же новости, как будет выглядеть запрос GET:
www.server.ru?news&id=9 - так мы выведем на экран новость с 9-ым ID. А если к новости нужны коменты, то как обрабатывать запрос сохранения формы? www.server.ru?news&id=0&work=save... И при этом ядро должно понимать эти входящие параметры.
Допустим мона забить на rewrite mode и использовать в ядре только стандартизованные переменные, типа module, id, work и т.д. но (!) при обработке POST форм как быть? Или на этом действия ядра заканчиваются?
Вы как-то сужаете значимость и функциональность движка (ядра).
ядро может не только обрабатывать адреса и выхватывать параметры.
Ядро может обрабатывать шаблоны, рассылку... Отвечать за навигацию и т.д.
:)
ядро, беря на себя ответственность за ввод/вывод информации, по любому будет обрабатывать шаблоны и работать с навигацией. По поводу рассылки - я бы прикрутил отдельным модулем, потому как некоторым достаточно рассылать просто текст, а другим MIME Type падавай, да еще в 100% вариации аутлука =)
Хотя в ядро можно вмонтировать отсылку простого текста, всё равно ядро обрабатывает информацию.
вообще-то это уже отвлечение от первоначального вопроса:
"Сосбно вопрос в модульных CMS. Я вот думаю, следует ли писать некое ядро CMS, которе бы взаимодействовала с навешенными модулями или же предоставить этот функционал самим модулям...?"
:))
17 лет назад