CMS нужна помощь по теории построения
- Автор темы SID
- Дата начала
SID
ReadOnlyТеаm
пока я не буду окончательно уверян в своих действиях, мне это не надоест. какой будет смысл если я опять напишу скелет который не будет поддерживать расширяемость?
у меня не стоит задачи написать супер-пупер-универсальную cms пригодную на любой случай, мне всего то нужно разработать окончательный вариант под свои задачи с расчетом на то что в будущем я даже не буду задумываться над тем правельно или не правельно спроектировано скажем так ядро системы.
так же после того как я начал понимать что в моей реализации фатальных ошибок нет, собсна все решается правельной установкой путей в .htaccess родился вопрос по алгоритму подключения модулей.
т.е. сейчас у меня происходит обычный переход по ссылкам в директорию /pages. модуль новости это отдельный скрипт в директории /pages под названием news.php
поискав по форуму я нашел еще один вариант реализации когда все запросы например mypage.com/pages/news.php будут редиректиться на index.php а уже в index.php разбирать переменную REQUEST_URI и инклудить необходимый модуль. таким образом все действия будут происходить в index.php
Какой вариант предпочтительнее использовать переход по ссылкам на нужный "модуль" в директории /pages или делать редирект всех запросов на index.php ?
SID
ReadOnlyТеаm
Фанат
для тебя как для опытного человека какой вариант более предпочтительнее?
Я вот например не понимаю на основании чего нужно принимать решение о том какой вариант изспользовать.
В чем заключается конструктивная разница двух привиденных вариантов?
Денч
спасибо за намек, но я уже сам разобрался ^^
для тебя как для опытного человека какой вариант более предпочтительнее?
Я вот например не понимаю на основании чего нужно принимать решение о том какой вариант изспользовать.
В чем заключается конструктивная разница двух привиденных вариантов?
Денч
спасибо за намек, но я уже сам разобрался ^^
твой вариант модульнее.
то есть, у тебя модуль независимее.
если же всё пихать в индекс, то тогда в него придётся пихать и те части скрипта, которые необходимо выполнить до того, что делается в индексе. скажем - задать title страницы.
плюс, твой вариант проще. внём отсуствует необходимость писать специальную программу по вызову других скриптов.
в результате вместо кучи модулей у тебя получается куча модулей и жуткий монстр индекс - в придачу.
второй проще при реализации ЧПУ.
то есть, у тебя модуль независимее.
если же всё пихать в индекс, то тогда в него придётся пихать и те части скрипта, которые необходимо выполнить до того, что делается в индексе. скажем - задать title страницы.
плюс, твой вариант проще. внём отсуствует необходимость писать специальную программу по вызову других скриптов.
в результате вместо кучи модулей у тебя получается куча модулей и жуткий монстр индекс - в придачу.
второй проще при реализации ЧПУ.
betik
Новичок
SID
Например у меня главный index, которому передаётся параметр PAGE организован так:
1. Проверяется целостность системы.
2. Проверяется лицензия (проверка на дурака, но в принципе можно при необходимости что-то наваять...)
При успешном пункте 1 и 2
3. Выбираем из базы информацию по id=page
3.1 Подготавливаем титлы, меты, подписи и прочую инфу по данным из базы. Делаем доступными переменные типа $title.
4. Если суть страницы текст - обрабатываем текст в переменную $content.
5. Если суть страницы обработка внешнего модуля - инклудим в индекс модуль, указаный в бд.
Внешний модуль занимается своими делами, не думая о БД, авторизации и проч.
В итоге занятий своими делами подготавливаем переменную $content.
Ассигнуем всё это добро в смарти.
+ ещё подключение библиотек
+ ещё работа с щаблонами (генерация меню, топов, проч)
+ ещё работа с блоками
+ ещё возможность "тюнинговать всё систему" - есть папка , допустим tune и индекс первым делом инклудит все файлы из неё.
Какие плюсы (имхо):
1. Простота создания новых модулей.
2. Легко пофиксить ошибки
3. ЧПУ - легко
Например у меня главный index, которому передаётся параметр PAGE организован так:
1. Проверяется целостность системы.
2. Проверяется лицензия (проверка на дурака, но в принципе можно при необходимости что-то наваять...)
При успешном пункте 1 и 2
3. Выбираем из базы информацию по id=page
3.1 Подготавливаем титлы, меты, подписи и прочую инфу по данным из базы. Делаем доступными переменные типа $title.
4. Если суть страницы текст - обрабатываем текст в переменную $content.
5. Если суть страницы обработка внешнего модуля - инклудим в индекс модуль, указаный в бд.
Внешний модуль занимается своими делами, не думая о БД, авторизации и проч.
В итоге занятий своими делами подготавливаем переменную $content.
Ассигнуем всё это добро в смарти.
+ ещё подключение библиотек
+ ещё работа с щаблонами (генерация меню, топов, проч)
+ ещё работа с блоками
+ ещё возможность "тюнинговать всё систему" - есть папка , допустим tune и индекс первым делом инклудит все файлы из неё.
Какие плюсы (имхо):
1. Простота создания новых модулей.
2. Легко пофиксить ошибки
3. ЧПУ - легко
betik
Новичок
SID
Нет. Не может. В некоторых случаях (простые модули) если установить соединение с БД и вывести переменную контент в браузер - будет работать.
А вообще зачем ему работать автономно?...
У тебя задача сделать CMS или отдельные модули?
Или ты хочешь подключать _ЛЮБЫЕ_ внешние скрипты?
Нет. Не может. В некоторых случаях (простые модули) если установить соединение с БД и вывести переменную контент в браузер - будет работать.
А вообще зачем ему работать автономно?...
У тебя задача сделать CMS или отдельные модули?
Или ты хочешь подключать _ЛЮБЫЕ_ внешние скрипты?
SID
ReadOnlyТеаm
betik
теперь нужно написать нечто такое, что позволит объединить весь этот "хлам" под единую cms с действием глобальных групп прав на различные функции.
думаю так оно и есть. т.к. имеется куча разных модулей но все они были написаны в разные годы и разными разработчиками. общих стандартов кодирования не придерживались.
теперь нужно написать нечто такое, что позволит объединить весь этот "хлам" под единую cms с действием глобальных групп прав на различные функции.