Как сделать правильную CMS

ОК, тогда еще хочу спросить одну вещь, может немного тупой вопрос, но как называть эти объекты, например объект класса Pages, стоит ли называть $pages или лучше вообще делать так: Pages::method(), ну или Pages::getInstance()->method()
(Добавление)
caballero, да, я неудачно сопоставил, я имел ввиду, если например использовать абстрактный Pages, то сам класс будет выступать в роли... не знаю как сказать, просто получится что мы не можем создать объект данного класса, но можем работать с его статическими методами и переменными, и получается как бы только одно хранилище. В случае с синглтон мы можем создать только один объект данного класса и получится тоже как бы одно хранилище. Например я видел что для работы с БД одни используют синглтон а другие - абстракцию. Ну и я подумал, что они все-таки чем-то схожи жруг с другом
(Добавление)
P.S. Я знаю что Singleton это паттерн, а абстрактный класс - это абстрактный класс.

(Отредактировано автором: 18 Ноября, 2011 - 19:47:11)

работа с БД и работа о страницами кагбэ оразныве вещи

синглетон используют для хранения коннекта с базой не более того.

В остальном я так и не понял чего вы хотите сказать или сделать. Может вам сначала объяснить что и как хотите сделать без специальных терминов, а потом будет видно где там какие паттерны или классы. Потому как вообщне непонятно о чем речью.

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

Мне нужно создать маленькую CMS (если ее так можно назвать) систему. Логика такова, что каждый модуль состоит из ядра самого модуля, вида и пользовательского интерфейса (последние два необязательны). Страницы - тоже модуль (т.е. не сами страницы а модуль для создания/удаления/редактирования /выборки/и т.д. их). Этот модуль будет состоять из ядра (функции для выборки, создания, удаления, редактирования страниц), пользовательского интерфейса (грубо говоря - страница в админке) и вида (вид это как бы просто переменная в которой содержится обработанный результат выборки страниц(ы), для того чтобы шаблонизатор мог подставить эту переменную в шаблон). Вот такая вот логика.

morph-x начните как есть, сейчас - тогда поймете вкус.. Размышлять можно вечно.. Девушка перед открытым шкафом тоже думает "Что же сегодня одеть?".
Одевайте сейчас не думая. Думать будете с опытом, каких и сколько "функций" и классов-объектов будет.
Всеравно 100500 раз переделаете.

-----
Шта? Репозиторий?

DeepVarvar, да я уже начал, и переделывал... и даже запутался . Поэтому спрашиваю здесь советов. Но ладно уже, разберусь походу...

А что это? Я знаю что просто фраза такая...

-----
Шта? Репозиторий?

То что вы описали подпадает под стандартный MVC который юзается в подавляющем боьшинстве фреймворков и CMS (хотя лично я считаю что этот паттерн для веба как собаке пятое колесо)

И кстати как во всех этих фрейморках встает проблеммма а кто будет всеv этим управлять? Кто и как соберет в кучу страницу на которую как правило выводятся данные нескольких модулей? и д.
Это я к тому что сначала нужно продумаьб архитектуру конецептуально. А какие там классы это уже прояснится потом и не надо будет гадать а куда воткнуть синглетон или абстрактный клас потому что без этого фреймворк не крутой.

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

Тоочно.
caballero, вопрос слегка не в тему (если я правильно понял авторство).
Как приходила мысль написать зиппи и почему?

-----
Шта? Репозиторий?

Очень просто - поюзал явовский фреймворк Wicket. Идея понравилась. Решил портировать на PHP. По дороге учел самые удобные фишки с asp.net и Delphi (тем более появился Delphi 4 PHP).
Конечно городить очередной MVC фреймворк смысла никакого не было. В этом и проблемма "велосипедистов" - они либо приходят к тому что в других фреймворках - либо переделывают пока не надоедает и бросают.

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

Уже ёпт... Теперь думаю какой из фреймворков выбрать.. Хотя свой велик бросать не собираюсь, есть интересные вещи, но больше на стороне ЦМС (т.е. конечного интерфейса), чем самой реализации как базы.
Организовал динамические св-ва объектов, конструктор.
Прямо в админке. Очень отдаленно похоже на битриксовые инфоблоки,
неткатовские фишки для разраба и чуток на ПМА..
Только гораздо нативнее и понятнее. Сейчас все это допиливаю.
Цель - не нагромоздить интерфейса и оставить максимум настроек...

-----
Шта? Репозиторий?

Ну для этого я решил сделать класс Template. Это будет выглядеть типа так:

DeepVarvar
На самом деле не обязательно должны быть оригинальная идея. Можно взять и стандартные решения но собрать в кучу не что попало а самые удобные фишки.
Например - пространства имен в 5.3. Отпадает одна из заморочек - как организовать файлы - модули в каталогах, каталоги в модулях или еще надцатью способами. Если ипользуете неймспейсы - размещаешь как хочешь и когда хочешь переразмещаешь простым перепиливанием логики в одной функции автолоада.
Или.
Админка. Святая святых. Божество всех разработчиков и пользователей (как фреймворка так и конечных пользователей). А всегда ли нужнв выделенная админка. Ведь гораздо проще если админ будет логинится той же страницей как обычный пользователь только ему откроются дополнительные пункты меню и тут же на обычной странице можно работать с контентом администратора. Гораздо проще не дублировать в админке вывод каких нибуть статей или галерей или профилей юзеров для администрирования а просто проверив что юзер-админ появить ему дополнительные кнопки или иконки для управления.

Если собрать в кучу удобные и разумные решения - как раз и получится удобный инструмент как минимум для себя чтобы по быстрому сайты лабать. А там глядишь и колегам по работе понравится на очередном проекте и т.д.
(Добавление)
morph-x

Понятно - торчат уши smarty. А теперь подумафте где вы будет брать начинку для этих переменных. Кто подергает ваши модули выковыряет из них данные и скормит их шаблону. В каком виде модули будут отдавать данные. Если скаларная переменная не проблемма. А если чего посложнее. Где будет дизайн.
Если в одном темплейте - тогда вы разносите данные и представление модуля (как логической структуры) по разным частям сайта и разбивка на модули получается чисто условно -вы не сможете просто вынуть или добавить модуль. А если дизайн той части данных где модуль находится при самом модуле (к примеру модуль поиска с формой поиска) . То осложняется работа дизайнера потому что ему надо по кускам дизайнерить и то что код отделен от дизайна его не сильно обрадует если дизайн разпросан по всему сайту.

(Отредактировано автором: 18 Ноября, 2011 - 22:50:20)

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

caballero, у меня класс Template для сбора переменных пробегается по всех каталогах внутри каталога modules проверяет есть ли там файлик view.php, если есть то подключает:

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