Вот эахотел сделать CMS
- Автор темы aprok
- Дата начала
aprok
Новичок
ДоступноАвтор оригинала: px
Ядро, как уже сказал mit - это "набор функций, классов (для работы с БД и др.)", а модуль - это некая сущность(класс, функция или что-то другое, всё зависит от конкретной реализации), которая реализует опред. функционал. Допустим есть модуль контента и его задача вывести 5 статей. Чтобы вывести эти статьи модуль пользуется функциями для доступа к бд, которые заложены в ядре, затем он (модуль) вызывает другой модуль - модуль шаблонизатора и передаёт ему массив со статьями. Шаблонизатор "применяет" к шаблонам данные полученные от модуля контента и вывводит их.
Доступно объяснил?
А па поводу меню.
Пока думаю сделать так
function menu {
По идеи когда добавляетца новый модуль в СMS идёт запись в базу (данныё о модуле,
тесть должен ли он виден в меню, доступен всем или тока админу, версия модуля…)
А эта функция будет выбирать названия модулей которые должны быть видны в меню
и формировать массив (название кнопки и ссылка который будут переданы в smarty)
}
-~{}~ 05.03.06 20:42:
А чем плоха, передавать название модуля в url,
Какие минусы, когда я так делаю?
px
Новичок
ход твоих мыслей понял - для начала сойдёт.
Насчёт названия в урле:
минусов немного, но все они существенные, например тебе могут сделать банальный php-injection, так что лучше обеспечить максимальную фильтрацию всех вход. данных.
Вот тут подумалось - а почему обязательно классифицировать контент по модулям(т.е. статья - это единица модуля статьи, новость - единица модуля новостей и т.д.), ведь можно обойтись без этого и избавить вашу систему от урлов вида сайт.ру/модульновостей/новостьномер6/, в пользу сайт.ру/новостьномер6/ и такая система будет намного логичнее (имхо конечно) выглядеть. Если хотите, то могу развернуть тему одробнее...
)aprok
Новичок
Разверни , буду очень благодарен.Автор оригинала: px
Вот тут подумалось - а почему обязательно классифицировать контент по модулям(т.е. статья - это единица модуля статьи, новость - единица модуля новостей и т.д.), ведь можно обойтись без этого и избавить вашу систему от урлов вида сайт.ру/модульновостей/новостьномер6/, в пользу сайт.ру/новостьномер6/ и такая система будет намного логичнее (имхо конечно) выглядеть. Если хотите, то могу развернуть тему одробнее...
Идея интересна так как большинство СMS используют модули. =)
px
Новичок
Ну в расширяемой системе модули будут ит ак, только роль немножко другая. Вообщем идея такова:
Обычно в кмс информация индентифицируется по модулю, которому она принадлежит и эта классификация выражается в урле (сайт.ру/модульновостей/новостьномер6/ или сайт.ру/?module=news&news_id=6). Такой подход считается как бы стандартным и более простым. Но такая система более примитивна и немного избыточна. Я предлагаю выход (хорошо звучит, правда?). Нужно ввести некую сущность которая будет классифицировать данные вместо модулей. На роль этой сущности на подойдёт поле в таблице. Что за таблица? Как что, мы же решили, что запретим модулям заниматься классификацией, соответственно в бд больше не будет табличек типа module_news_content или module_article_content. Теперь все записи должны хранится в одной таблице(назовём её content) вида id, pid, type, author, published, title, text (надеюсь ненужно говорить, что эта таблица ненормализована и хорошо бы древо документов(поля id, pid) вынести в другую таблицу). Сейчас для нас, ключевое поле - это type. Именно в нём будет хранится информация о типе документа(допустим у нас будут два типа - news_item и article).
Итак, как это будет работать?
Первым делом мы получаем урл вида сайт.ру/новость6 и выдёргиваем оттуда "новость6", далее делаем запрос к нашей таблице content вида select id, type from content where artitcle=mysql_real_escape_string("новость6"); и получаем айди и тип документа. Дальше нам нужно узнать, какой модуль обрабатывает документы типа news_item, для этого делаем запрос к таблице content_types(id, type_name, module_name) - select module_name from content_types where type='news_item'. Отлично, теперь мы знаем кто обработает наш документ - это будет модуль новостей (назовём его newser). Далее дело за малым - подключаем наш модуль (допустим он выполнен ввиде функции) и передаем ему айди документа: newser("id документа с title=новость6"). Newser загружает шаблон, пихает туда нашу новость и выводит пользователю. Ура.
З.Ы. Данный пост не является руководством к действию, а лишь показывает показывает схематичную реализацию идеи.
Обычно в кмс информация индентифицируется по модулю, которому она принадлежит и эта классификация выражается в урле (сайт.ру/модульновостей/новостьномер6/ или сайт.ру/?module=news&news_id=6). Такой подход считается как бы стандартным и более простым. Но такая система более примитивна и немного избыточна. Я предлагаю выход (хорошо звучит, правда?
). Нужно ввести некую сущность которая будет классифицировать данные вместо модулей. На роль этой сущности на подойдёт поле в таблице. Что за таблица? Как что, мы же решили, что запретим модулям заниматься классификацией, соответственно в бд больше не будет табличек типа module_news_content или module_article_content. Теперь все записи должны хранится в одной таблице(назовём её content) вида id, pid, type, author, published, title, text (надеюсь ненужно говорить, что эта таблица ненормализована и хорошо бы древо документов(поля id, pid) вынести в другую таблицу). Сейчас для нас, ключевое поле - это type. Именно в нём будет хранится информация о типе документа(допустим у нас будут два типа - news_item и article).Итак, как это будет работать?
Первым делом мы получаем урл вида сайт.ру/новость6 и выдёргиваем оттуда "новость6", далее делаем запрос к нашей таблице content вида select id, type from content where artitcle=mysql_real_escape_string("новость6"); и получаем айди и тип документа. Дальше нам нужно узнать, какой модуль обрабатывает документы типа news_item, для этого делаем запрос к таблице content_types(id, type_name, module_name) - select module_name from content_types where type='news_item'. Отлично, теперь мы знаем кто обработает наш документ - это будет модуль новостей (назовём его newser). Далее дело за малым - подключаем наш модуль (допустим он выполнен ввиде функции) и передаем ему айди документа: newser("id документа с title=новость6"). Newser загружает шаблон, пихает туда нашу новость и выводит пользователю. Ура.
З.Ы. Данный пост не является руководством к действию, а лишь показывает показывает схематичную реализацию идеи.
px
Новичок
имхо, избыточна параметром module, ладно если бы это нужно было для структуры сайта, но в нашем случае идет указание не на информационную структуру сайта, а на программную, которую пользователь знать не должен по определению А мод реврай здесь вообще не причём ибо ЧПУ можно и без него сделать.
А мод реврай здесь вообще не причём ибо ЧПУ можно и без него сделать.aprok
Новичок
Дета год ,но кодил тока для себя .
Всем спасибо, пока буду делать на модулях по старинке ?modul=news.
Вот тока одну вещ не понял для себя
Как лучше генерировать главное меню ,
с того класса что я написал меню будет всегда такое как в базе данных,
а нужна сделать чтобы модуль мог изменить меню.
Пока как я понимаю выход один => каждый модуль должен наследовать
ядро , но эта идея мне не очень =(.
Rammstein
PHPClub::News
2 px
Имхо, не ново. По крайней мере на это я и хотел читателей подтолкнуть в своей последней статье (PHPInside #17). Т.е. использовать "красивые" урл при модульном подходе, по меньшей мере бессмысленно. В случае же с VFS мы обращаемся не к модулю, передавая ему параметры, а к объекту, который может по своему желанию передать власть модулю (т.е. это заложено в логике самого объекта). Самый правильный подход.
Имхо, не ново. По крайней мере на это я и хотел читателей подтолкнуть в своей последней статье (PHPInside #17). Т.е. использовать "красивые" урл при модульном подходе, по меньшей мере бессмысленно. В случае же с VFS мы обращаемся не к модулю, передавая ему параметры, а к объекту, который может по своему желанию передать власть модулю (т.е. это заложено в логике самого объекта). Самый правильный подход.