Меню
Что нового?

Принципы построения CMS

chaan

Guest
Принципы построения CMS

Вот не могу сформировать у себя в голове архитектуру системы. Поэтому буду писать мысли несколько сумбурно.

1. Принцип "получение">"обработка">"вывод ". Как я понимаю, с точки зрения системы это соответствует "получение основных данных из первичных, т.е. св-в страницы из урл">"формулирование контента, работа модулей">"натягивание дизайна, шаблоны ". Правильно?
2. Что есть "ядро"? В моем понимании, это базовый скрипт, который подключает конфиг, стандартные функции, модули и, возможно, сам является неким главным модулем.
3. Есть где-нибудь доки по вопросу построения CMS/CMF? Я нашел очень мало дельного и исключительно абстрактного. Хотелось бы практической инфы. Возможно, инфа о организации(хотя бы примерной) Битрикс, NetCat и др.

Мои мысли. Данные->index.php->Получаем параметры->Обрабатываем(Например, модуль рекламы показ. рекламу. Формулируется контент в xml/<div>'ах и т.п., что не есть важно)->передаем все это пользователю через некий шаблон, XSLT или просто HTML + CSS. Мне видится пока только такая организация системы. Что думаете
 

Gas

может по одной?
Теоритической инфы не мало в этом форуме, поищи по словам cms,cmf,mvc. Если хочется пощупать уже готовые системы, скачай какие-нибудь опен сорсные и посмотри.
 

Нечто

Психолог РНРClub
Качни Content Management Bible в PDF, полистай доки по ez.no и typo3.com. Архитектура у всех разная, так что "правильно" и "неправильно" можно разграничить только в рамках реализации.
Тут еще на форуме валялось интересное ТЗ (c) Antonio. Там на "русском английском" все конкретно и красиво расписано.
 

Angel Echo

Guest
Что есть "ядро"?
Нажмите для раскрытия...
Ядро - это библиотека функций, т.е. один или несколько php-файлов, содержащих только функции, которые вызываются из остальных скриптов. Все другие скрипты содержут только интерфейсную часть и вызов функций ядра.

-~{}~ 14.04.05 22:11:

1. Храним данные пользовательских страниц в XML файлах
2. Редактируем эти данные этих XML-файлов с помощью php-шной библиотеки DOM XML
3. Редактор данных пишем скажем на JavaScript
4. Все XML файлы парсим в одном файле index.php с помощью XSL шаблонов (парсер Sablotron). В качестве параметра в index.php кидаем id страницы xml.
5. Меню сайта храним в отдельном xml-файле иерархической структурой с элементами типа <LINK id="id" address="файл.xml">
6. На полученный после парсера HTML накладываем для разнообразия дизайна CSS (т.е. за шаблоны отвечают XSL+CSS)

Вот и контент-менеджер почти готов :)

-~{}~ 14.04.05 22:14:

Конечно для полного удовольствия необходимо еще редактор меню сваять и файловый менеджер, сделать модуль пользовательских аккаунтов, скажем с сохранением данных в MySQL.

Но конечно все это требует развития :)
 

Bosha

Новичок
Интересная схема. Меня вот всегда интересовало в таком подходе что такое данные страниц в xml файлах.
Что там собственно говоря хранится?

-~{}~ 15.04.05 13:53:

Автор оригинала: chaan
2. Что есть "ядро"? В моем понимании, это базовый скрипт, который подключает конфиг, стандартные функции, модули и, возможно, сам является неким главным модулем.
Нажмите для раскрытия...
Не стоит его в модули записывать. Тут нужно задать себе вопрос, а что такое модуль, а то этим понятием все спекулируют как хотят. Как по мне лутше все делить на компоненты - часть самой системы и модули - сторонние классы написанные по установленным правилам и дополняющие НОВЫЕ возможности в систему.

Возможно, инфа о организации(хотя бы примерной) Битрикс, NetCat и др.
Нажмите для раскрытия...
Я недавно тоже этим интересовался, даже нашел кое-что, но это не сильно помогает. Каждый реализует по своему. Ты вот как по мне правильно понимаешь процесс и лучше просто думать о том как это без глюков реализовать
 

chaan

Guest
Вот я столкнулся с такой проблемой. Написал стандартные функции в ядре. Но у каждого модуля проверка данных, например, своя. Конечно, можно написать очень большую функцию, которая будет учитывать все, но какой реальный плюс? Только централизация? Как я понимаю, если писать очень уж универсальные функции, то страдает производительность, т.к. обрабатывать функцию с 1-3 параметрами быстрее, чем с десятком, половина из которых к тому же не задействованна. Да и ту же проверку делает лишь несколько модулей, остальные спокойно работают через if.

В общем, как я понял, ядров данном случае -- это лишь набор стандартного функционала?

За Библию спасибо, поищу.
 

Alexandre

PHPПенсионер
Но у каждого модуля проверка данных, например, своя
Нажмите для раскрытия...
должен быть определен базовый класс проверки входных данных, а его методы использоваться в модулях.

структура CMS - дело индивидуальное для каждого разработчика и по этому вопросу можно спорить до хрипоты.

у меня, например , реализованно так:

ядро, содержит API + контроллер запросов
+ каркас админского интерфейса.

библиотека модулей.
xml конфиг, описания логики обрабтки модулей и взаимодействие с библиотекой шаблонов

-~{}~ 15.04.05 14:35:

проверка вх данных осуществляется в класе, производным от контроллера, и в зависимости от результата проверки вызывается тот или иной класс реализации модели.

Конкретная модель вызывает класс реализации того или иного представления модели. А Представление модели может иметь один или несколько шаблонов. т.е. Представление - это только набор данных , а не результирующий HTML, который потом отображается через соответствующий шаблон. т.е. одно Представление может иметь несколько шаблонов (вариантов вывода HTML ).

Сложно? может быть...
 

Pixxxel

Новичок
У меня есть эта забавная книжка Content Management Bible, но в инете ее вряд ли найдешь. Могу выслать по почте, но она на английском и занимает несколько метров. А вообще она не очень
 

Bosha

Новичок
chaan
У тебя будет не так уж много универсальных функций как ты можешь подумать. Мне кажется, что главное для ядра, обеспечить нормальное, гибкое взаимодействие модулей, а не брать на себя их функции
 

Bosha

Новичок
Pixxxel
Несколько метров? Прикольно я недавно закачал ее в 70мб варианте!!
 

betik

Новичок
Моя CMS не идеальна, сразу же скажу.

Принцип:

Админский интерфейс ПОЛНОСТЬЮ оторван от пользовательского. Это даёт приемущества:

1. Можно управлять любым сайтом с любого компьютера на котором есть ПХП и веб-сервер, если на удалённом сайте разрешён доступ с данного ИП.
2. Админку в любой момент можно убить напрочь, при этом сайт будет работать абсолютно нормально.
3. Внести исправления в админку можно без внесения изменений в пользователькую часть.

Админка сделана не оч. хорошо, поэтому о ней пока рассказывать не буду.

Пользовательская часть состоит из:

1. Ядро
2. Модули
3. Шаблоны (smarty)

Ядро занимается тем, что на основе тех или иных методов подготавливает содержимое для шаблона, не привязываясь к конкретному шаблону, это обеспечивает поддержку неограниченого количества шаблонов.
Ядро анализирует структуру страницы и подключает необходимые библиотеки и модули, конфигурации и файлы описания лицензионных ограничений. Содержимое библиотек и модулей ядру совершенно безразлично.
Затем ядро подготавливает данные и отправляет их на обработку смарти, а смарти отправляет данные в браузер.
 

chaan

Guest
Вот книжка http://www.essentialmind.com/files/cmb.pdf(13,1 Мб).
Вот еще какая-то документация, пока не читал -- Content Management Design.

Резюмируя, я пока пришел к такой организации, поправьте, где надо:

1. Инициализатор index.php запускает систему, ну это понятно).
2. Запускается ядро, подключает конфиги(все инклуды, короче), подключает стандартные библиотеки(не совсем абстрактно, наверно).
3. Далее управление передается главному классу/модулю системы и он полностью отвечает за вывод страницы, все свои функции выполняет через ядро, т.е. подключение модулей, проверка данных и т.п. Также главный модуль формирует контент и именно он передает его шаблонизатору.
4. Далее уже дело техники.

Вопросы:

5. Если дизайнер/верстальщик понимает пхп код, то использование Смарти не оправданно? ХТМЛ со вставками пхп вроде быстрее, я прав?
6. Не соображу, как получить данные о том, какие странице нужны модули/блоки. Пока надумалось только получение из шаблона. Что-то я явно туплю здесь...
 

Angel Echo

Guest
Интересная схема. Меня вот всегда интересовало в таком подходе что такое данные страниц в xml файлах.
Что там собственно говоря хранится?
Нажмите для раскрытия...
А хранится там может, например, весь HTML твоей страницы, заголовок страницы, имя страницы в меню, параметры настройки (типа отображать/не отображать, главная/не главная и проч.), еще скажем отдельные блоки, типа каталога товаров или галереи. Обрабатываться все это будет с помощью XSLT, а вот редактировать каждый такой блок отдельно с помощью DOM XML !

-~{}~ 16.04.05 18:57:

Например,

<PAGE>
<SETTINGS show="1" index="1"></SETTINGS>
<HEADER>Название страницы</HEADER>
<CONTENT>Текст страницы</CONTENT>
<GALLERY>
<IMAGE address="img1.jpg"></IMAGE>
<IMAGE address="img2.jpg"></IMAGE>
</GALLERY>
</PAGE>

-~{}~ 16.04.05 19:01:

DOM XM будет извлекать нужные узлы и выводить соответствующие элементы редактирования формы, в которых можно будет содержимое этих узлов изменить или добавить новые. Для редактирования HTML можно редактировать, слив его содержимое во фрэйм IFRAME? задав для него document.designMode='On'; и дальше функциями JavaScript менять HTML ! Довольно известная процедура.
 

Нечто

Психолог РНРClub
Angel Echo
Разве правильно хранить служебную информацию вместе с данными?
Как осуществлять выборку по полям с сортировкой? Наверное, нужно иметь еще общий xml-карту материалов?
 

Angel Echo

Guest
Верно, можно в отдельном xml-файле хранить иерархическое меню меню сайта. Любую сортировку можно учинить с помощью XSL-шаблонов, которые предоставляют весьма широкие возможности интерпретации данных !!! Служебная информация ? Ее минимум и она относится по сути к данным страницы и влияет лишь на ее отображение. Такие параметры как отображение страницы, страница-индекс задает пользователь, скажем во многопользовательском конструкторе сайтов.
 

chaan

Guest
Как вы думаете, что должно в ходить в стандартные функции ядра?
Реализация:
запрос->загрузка ядра(настройки, функции)->ядро(предпроцессорная , проц., постопроц. обработки)->shut down(обнуление, если надо)

*предпроц. обработка -- это, например, включение таймера системы в целом или проверка режима работы системы(дебаг, тестинг и т.п.);
*процессорная обработка -- это "функция" по работе с получение страницы и выдачи её пользователю;
*постпроц. обработка -- это, например, отключение того же тайиера, сюда же можно вкл. shut down

**Исходя из этой реализации, сам полагаю, что надо четко разделять работу ядра и проц. обработки, т.е. функции ядра и обработчика страницы не пересекаются. Т.е. в теории ядро не знает, что есть обработчик, оно лишь обеспечивает среду для работы. Следовательно, в функции ядра должны входить функции, никак не связанные с обработкой страницы, например: проверка окружения и режима окружения, дебаг и т.д.
 
Войдите или зарегистрируйтесь для ответа.
Сверху