Предлагаю познакомиться с текущими наработками по сабжу. Скачать и пощупать движок можно отсюда https://sourceforge.net/projects/smart-core-cmf/ , тут же активный репозиторий на Гите. На http://smart-core.org/ поднят вики и форум. Вкратце ориентация движка, наверно ближе к аналогу битрикса, юми... т.е. какбы универсальная платформа для конструирования своих проектов, но в тоже время не на столько низкоуровневая, как обычные фреймворки, но и просто CMS "искаропки" не назвать Надеюсь кому-нить понравится задумка с архитектурой и присоединится к разработке!
Как вариант готов рассмотреть вариант сотрудничества при котором я помогаю создавать ваш сайт, на движке Smart Core, при этом от вас ожидается вклад в развитие движка
вроде бы что то похоже на правду, связи нод как то отражены в бд или рекурсивно по папкам собираются? данные модуля это шаблоны или что то скомпилированное?
Все ноды хранятся в таблице engine_nodes, там же можно наглядно посмотреть в какой папке, в каком контейнере, какой модуль она цепляет и с каими параметрами, также там задаются права доступа к ноде. Таким образом ядро (в частности метод Kernel->buildModulesData() этим занимается) имея данные о нодах, создает объект класса модуля, который прописан в ноде и передаёт конструктору модуля массив с параметрами подключения. Наример в демке самая первая нода, подключает модуль Texter в папку с ид = 1 и контейнер с ид = 3, также в качестве параметров подключения модуля ему передаётся параметр text_item_id = 1 (в БД это значение хранится в сериализованном виде a:1:{s:12:"text_item_id";s:1:"1";}). После того как модуль отработает он вернёт результат своей работы в виде массива, например такого: PHP: [text] => Футер. Но ядро в массив ЕЕ в секцию [modules_data] запишет следующие данные: PHP: [footer] => Array ( [1] => Array ( [module_name] => Texter [use_tpl] => auto [tpl] => Texter [node_action_mode] => popup [data] => Array ( [text] => Футер. ) ) ) Где можно видеть: [footer] - это контейнер, в который в данном случае подключена только одна нода. [1] - ИД ноды , которая подключена. [module_name] - имя модуля [use_tpl] - логика выбора какой использовать шаблон системный или пользовательский [tpl] - имя шаблона, который будет запущен шаблонизатором. [node_action_mode] - это для фронт-админки [data] - собственнго массив в кототом все данные , которые вернул сам модуль, формат этих данных известен тольк осамому модулю и с этими данными будут работать шаблоны самого модуля. Понятие рекурсия в движке применяется только при полном обходе списка папок, а ноды могут только наследоваться от родительских папок к дочерним, но сами по себе ноды этого не знают, наследование выполняется через контейнеры. Но прошу заметить "ноды" в Smart Core это совсем не то же самое, что ноды в Drupal!, а также модули не тоже самое, что модули в джумле
Для полноты картины можно добавить еще маленьку заметку как работает шаблонизатор Основной макет имеет примерно такой формат: PHP: <div id="v-menu"> <?php $this->container('v-menu')?> </div> <div id="breadcrumbs"> <?php $this->container('breadcrumbs')?> </div> <div id="content"> <?php $this->container('content'); ?> </div> <div id="footer"> <?php $this->container('footer')?> </div> Т.е. только код, который попадает в тег <body>, а все заголовки и т.д. генерирует сам шалонизатор. Далее в вышеописанном случае мы рассмотрели пример с контейнером footer, следовательно шаблонизатор в это место начнет выводить по порядку все ноды , которые в него подключены (в нашем случае это одна нода). в нашем случае запустится файл Texter.tpl который выглядит следующим оббразом: PHP: <?php echo $mdata['text'] . "\n"; где массив $mdata это тоже самое, что и массив EE->modules_data['footer'][1]['data'] т.е. данные модуля.
Категорически согласен! но сам я по ходу не смогу его сделать... т.е. я готов рассказать всё во всех деталях и с разных сторон, но кратко и чтобы всем было понятно, объяснить видимо не смогу тут нужен свежий взгляд, а еще лучше человек с опытом составления документации. С этим вопросом также обращаюсь за помощью к комьюнити... доку можно делать сразу на вики двика (http://smart-core.org/wiki/).
Предпринял попытку написать краткий обзор о концепции архитектуры. Прошу ознакомиться всех желающих http://smart-core.org/wiki/Архитектура
UML начал делать, но она еще не готова. С другой стороны, классов в движке сейчас совсем не так много и всё приниципе распределено по папкам, например всё что относится к ядру, лежит в папке Kernel, все модули в папке Modules и т.д. По этому разобраться с программным кодом думаю будет совсем не сложно Главное вникнуть в концепцию архитектуры
d1gi а ну, я еше в первый раз разобрался когда про ноды спрашивал, главное сделать хотябы кратенький ман по установке
кратко есть в install/readme.txt , а по хорошему надо написать инсталлятор... но мне сейчас не до него может кто-нить присоединится к разработке и вызовется инсталяшку написать ну а пока как-то так
как повторить эту ошибку? через пма импортировал в мускул версии 5.1.45 и 5.0.90 всё срабатывает гладко. а это не баг это фича! ))) дело в том, что движок имеет возможность для любого модуля (точнее экземляра модуля - ноды) указать отделдьное подключение к БД. вот посмотрите табличку engine_nodes, там нода с ид 35 в поле database_id имеет значение 1, это означает, что движок для этой ноды создаёт отдельное подключение к БД. пока что список возможнных подключений хранится в табличке engine_database_resources, возможно в будущем будет как-то по другому задаваться. при таком механизме можно например галереи хранить в одной БД, а новости в другой.
d1gi может я пытался второй раз дамп залить, все работает, подключение поменял на 0 заработало сколько времени ушло на написание?
суммарно месяца 2, к сожалению у меня подходы эпизодические но сейчас всё больше и больше возникает потребность в этом движке, вот с недельку опять плотненько сижу за ним какие у вас впечатление от архитектуры? как считаете на склько эта идея с папками, модулями, нодами и контейнерами жизнеспособна и эффективна? по мне так очень здорово что получается всё такое как конструктор, можно что угодно откуда угодно вывентить, ввинтить, переместить, разадать права и т.д.... и фронт админка хорошо технологически вписывается
d1gi я такими системами не пользовался, писал под конкретную задачу, в этом плане вам виднее очень тяжело оценить архитектуру, не зная изначальных требований к системе, без обсуждений и диаграмм, после нескольких тем про cms, сам сидел думал над этим, папку core/karnel именно так и представлял, именно с такими классами, UMl'ку потому и попросил, что бы лучше понять что там происходит в целом вроде бы очень гибко, правда от 100 таблиц в шок впадаешь)
ну да, табличек много хотя с префиксом zz_ сейчас не задействованы, также будут убраны таблицы news_ , так что не о принципильно будет отличально от большинства cms-ok
d1gi вспомнил замечательную цитату "Без тестов код нельзя считать завершенным" по мере использования скорее всего рефакторинг не избежен и вот еше одна цитата "После каждого рефакторинга все тесты должны быть запущены заново" (или как то так, уже каша в голове, даже не помню откуда)
изначальные требования у меня были: - легкость создания новых сайтов - легкое и логичное изменение структуры, компоновки и оформления сайта - легкое встраивание нового функционала в сайт - просто управление готовым сайтом и как следствие возможность адаптировать управление под конкретный сайт (у меня одна кипишная журналистка вполне нормально справляется с сайтиком на этом движке ну и разумеется легковесность, возможность кеширования как по частям, так и целиком страниц и/или фрагментов страниц или данных, в общем если сказать короче, то типа битрикс, только людской, понятный и адекватно работающий такая вроде бы универсальная цмс, но не хардкорный програмерский фреймфорк с двумя тыщами классов для "хелоу ворд"
с тестингом у меня туго как-то... пока все баги вылавливаются в процессе эксплуатации %))) если кто-нить присоеденится к разработке и поможет внедрить тестирование, думаю будет очень здорово! глядишь и со временем вообще толстое комунити образуется )
PHP: <?php /** * Выполенение действий запрошенных через URI. * * $action_name - может принимать несколько значений, в записимости от котого запускаются разные методы, наример: * 'new_folder' - действия для создания новой папки. * 'all_folders' - просмотр всех папок. * 'edit_folder' - редактирование папки. * 'all_nodes' - просмотр всех нод в заданной папке. * 'node_properties' - редактирование свойсв ноды. * * @param string|int $action_name - название дейсвия, это часть слова следующая за NODE_ACTION. * @param string $uri_part - часть запроса, следующая за папкой указывающей на действие. * @return bool - успешность выполнения действия. * * @todo сделать более секьюрно и гибко. * @todo установку title для шаблона. */ private function action($action_name, $uri_path) { // Если $action_name является числом, то считаем, что это действие над нодой. if (is_numeric($action_name)) { $this->nodeAction($action_name, $uri_path); return true; } $uri_path_parts = explode('/', $uri_path); $key = 0; switch ($action_name) { case 'new_folder': $Folder = new Admin_Folder(); $data = $Folder->getNewFormData(); break; case 'all_folders': $Folder = new Admin_Folder(); $data = $Folder->getAllFoldersData(); break; case 'edit_folder': if (is_numeric($uri_path_parts[$key + 1])) { $Folder = new Admin_Folder(); $data = $Folder->getData($uri_path_parts[$key + 1]); } break; case 'all_nodes': $Node = new Admin_Node(); $data = $Node->getListInFolder($this->current_folder_id); break; case 'new_node': $Node = new Admin_Node(); $data = $Node->getNewFormData($this->current_folder_id); break; case 'node_properties': $Node = new Admin_Node(); $data = $Node->getData($uri_path_parts[$key + 1]); break; default; } $this->EE->template['modules_tpls'] = DIR_KERNEL; $this->EE->modules_data['content'][1] = array( // @todo продумать админские шаблоны... сейчас пока применяется контейнер 'content' и в ноду №1 складываются данные. 'module_name' => 'Admin', 'node_action_mode' => 'popup', 'tpl' => $action_name, // @todo сделать секурность. 'data' => $data ); $Head = Helper_Head::getInstance(); $Head->setData('popup_iframe.css', '<style type="text/css"> @import "' . HTTP_SYS_RESOURCES . 'styles/popup_iframe.css"; </style>'); $this->front_node_action = 'popup'; // @todo возможно переименовать в "front_end_action" или "front_end_action_mode"... return true; } тут можно добавить какую нибудь фабрику, по сути одни и те же действи выполняются что то типа PHP: <?php /** * тут определяем что нужно отправить в метод * $uri_path_parts[$key + 1] или $this->current_folder_id */ $var; /** * что нужно Admin_Folder или Admin_Node */ $type; /** * какое действие new, all, edit */ $action; $manager = new FolderManager(); $folder = $namager->get($type); $data = $folder->$action($var); ?> и все это будет объект, только методы нужно детализировать и над названиями подумать исходя из того что он делает, если по фен шую
можно попробовать, но там не толко работа с папками, но еще и с нодами, да и параметры разные передаются... в общем-то этот момент сейчас не критичен... имхо для начала популяризации движка нужно развить некий базовый функционал, вот сейчас работаю над компонентом Юникат, на нём же будут сделаны новости и каталог, также один паренек занимается веб-формами... дальше по списку задач идет модуль рассылки... а для полноты картины еще бы инсталлятор сделать и будет вообще красота
обращаюсь за советом. сейчас есть некоторые наработки и в прицнипе всё работает как задуманно архитектурой проекта, но архитектура самого кода на РНР далека от идеала, в частности нет прописанной в методах и классах и разложенной по папками и фалам идеологии паттерна MVC. очевидно, что это негативно сказывается сообществом программистом и я в принципе готов сделать полный рефакторинг программного кода, но очень хотелось бы оставить архитектуру самого движка т.е. методику организации и взаимодействия данных (концепцию «папок», «модулей», «нод» и «контейнеров»), которыми манипулирует сам программный код (который в частности сейчас пишется на РНР, а в будущем можно будет переписать и на другой язык, и он будет также корректно работать с данной структурой БД). либо возможно в процессе рефакторинга кода выяснятся недостатки архитектуры движка, тогда конечно нужно будет пересмотреть и её. собственно вопрос в том, может кто-нибудь помоч, с чего начать, как правильно изобразить прогаммный код, так что бы он и сообществом принимался на ура и работал с данной архитектурой данных и конечно же, чтобы скорость выполнения кода и потребление ресурсов было как минимум не больше существующего кода.