Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Vingrad CMS > CMF или подобие...

Автор: Wowa 17.6.2005, 15:25

Цитата(xolod @ 16.6.2005, 15:12) На мой взгляд собственная CMS не стоит трудов, и вот почему: 1.) Как бы дизайн не изменялся, модульная сетка все равно будет одна и та же, как и структура. 2.) Сайтов-клонов (построенных на одной и той же CMS) и так уже море. А будет еще больше. 3.) Чем универсальнее инструмент, тем чаще он ломается и тем медленне он работает. Оптимальным решением, опять же imho, было бы создание набора эдаких классов вроде Pear::..., для работы с новостями, гостевая, форум, статьи, фотогаллерея, портфолио, сведения о компании и прочее-прочее. С помощью которых можно было бы получать/добавлять, например, новости в виде "{Date}:{Time}:{Title}:{Content_Small}:{Content_Full}" и выводить их с индивидуально разработанным дизайном в любом месте. Буду рад оспариванию (да и поддержки тоже) моего мнения  Цитата(Irokez @ 16.6.2005, 15:21) это уже CMF .. про это должен быть отдельный разговор.. Давайте продумаем этот момент. Очень к интересным вещам можно прийти..

Автор: xolod 17.6.2005, 19:30

Кажется, все хором за CMS. Я здесь новичек и ко мне вряд ли кто прислушается, но... может быть стоит разрабатывать модули, способные существовать отдельно (в базовом комплекте: модуль, админ-модуль к нему, набор БД-оберток), а на основе этих модулей паралелльно разрабатывать готовую CMS, для тех, кто, скажем так, не хочет заморачиваться на программировании-построении дизайна-настройке.. "Имеем два продукта под одной торговой маркой" © Гейтс Б. Один -- для тех, кому нужен комплект модулей для быстрого встраивания в свой сайт и чтобы меньше писать кода. Второй -- для тех, у кого сайта нет, программировать не умеет, дизайнить не умеет, а сайт хочет. Без заморочек. Быстро и просто.

Автор: Irokez 17.6.2005, 19:36

CMF - Content Management Framework - конструктор конструкторов - то на чем строится CMS, так что вопрос CMS vs CMF - по-моему неуместный, любая CMS базируется на фреймворке, поэтому нужно определиться что будет в его комплекте

Автор: skalex 25.6.2005, 12:54

Важнейшая вещь в CMF - это грамотно заложить основу. CMF для меня - это минимальный(!) набор компонентов, которые реализуют модель работы веб-приложения. Абстракция, другими словами... CMF можно реализовать за 2-3 дня, а на разработку CMS могут уйти месяцы, но поддержку и развитие - годы! Причем CMF не должна быть ориентирована именно для написания CMS, она должна быть как основа для написания веб-приложения любого уровня. Вот список компонентов моей CMF: 1) класс ядра Core 2) класс управления ядром CoreController 3) класс-анализатор конфигурации ConfigParser 4) абстрактный класс контроллера AbstractController (интерфейс) 5) класс стандартного контроллера Controller (для наследования уже конкретными контроллерами для реального веб-приложения) 6) класс формирования оформления (темы, скина) веб-приложения SkinController (наследуется от Controller) 7) Plugin - абстракнтый класс плагина (расширения) Замечание: Контроллер - это класс, который непосредственно осуществляет генерацию контента запрошенной страницы. Например, контроллер новостей (NewsController), контроллер баннерной системы (BannerController) или контроллер авторизации (AuthController). С помощью контроллера также можно осуществлять переадресацию и любые другие механизмы. Этих компонентов мне достаточно, чтобы начать разработку любого веб-приложения. Все остальное (шаблонный движок, класс для работы с БД и т. д.) - это плагины, которые проектируются согласно концепции, закладываемой классом Plugin. Естественно допускается возможность подключения любой внешней библиотеки, которую можно использовать либо в чистом виде, либо в интегрированном. Например, Smarty я реализую также в виде самописного контроллера.

Автор: Sardar 25.6.2005, 15:07

Mace интресная концепция контроллеров Приведи пример интерфейса базового Controller и любого потомка.

Автор: skalex 25.6.2005, 15:47

Конструкция контроллеров до безобразия проста. Я специально старался сделать ее максимально простой. Покажу как я создал контроллер, использующий шаблоны Smarty. Код абстрактного контроллера AbstractController. Код <?php class AbstractController {    function AbstractController($name) {       $this->name  = $name;    }    function perform($parms) {       return false;    } } ?> Код Smarty-контроллера TController. Код <?php class TController extends AbstractController {    function TController($name) {       $this->AbstractController($name);       $this->templet = new Smarty();    }    function perform($parms) {       return false;    }    function display($name) {       if ($this->is_templet_exists($name)) {          $this->templet->display($this->name.'/'.$name.'.tpl');       } else {          WCC::Error('Templet', "Can't find templet [".$this->name."/".$name.".tpl]");       }    }    function is_templet_exists($name) {       return (file_exists($this->templet->template_dir.$this->name.'/'.$name.'.tpl')) ? true : false;    } } ?> Код реального контроллера StaticController (контроллер статических страниц). Просто подгружает статический шаблон. Код <?php class StaticController extends TController {    function StaticController($name) {       $this->TController($name);    }    function perform($parms) {       $this->display($parms['name']);       return true;    } } ?> Код реального контроллера NewsController (контроллер новостей). Получает список новостей, подготавливает данные для шаблона и загружает шаблон. Код <?php class NewsController extends TController {    function NewsController($name) {       $this->TController($name);    }    function perform($parms) {       // тут размещен код, получающий список новостей ($news) например из БД       $this->templet->assign('news', $news);       $this->display('news');       return true;    } } ?>

Автор: Opik 25.6.2005, 15:59

разве в PHP есть множественное наследие?

Автор: Sardar 25.6.2005, 19:47

Opik а где ты видишь множественное наследование? Mace идею понял

Автор: Opik 25.6.2005, 20:21

Sardar Может я конечно что то путаю... но 2 extends 1 3 extends 2 разве не множ наследие? ) *стыдна* ну раньше так низя было...

Автор: Sardar 25.6.2005, 20:34

Нет это не множественное наследование Множественное это: class 1 class 2 class 3 extends 1, 2 Другими словами тип не расширяеться, а вноситься новый, совершенно левый тип.

Автор: Opik 25.6.2005, 21:57

Sardar ок, спасибо. что пояснил

Автор: Wowa 23.2.2007, 13:02

Цитата(Sardar @  25.6.2005,  17:47 ) Mace идею понял smile  и как тебе эта идея?

Автор: Semenov 23.2.2007, 20:33

Идея хорошая. Это есть MVC. Самая актуальная структура, ихмо.

Автор: Sardar 24.2.2007, 18:29

Цитата(Wowa @  23.2.2007,  12:02 ) и как тебе эта идея?  MVC позволяет сделать реально гибкий и расширяемый движок. Тоже своё поделие как MVC фреймворк пишу  Есть интерфейс Controller, способный инициализироваться и порождать разные view, почти всегда это TextStreamView, который генерит просто вёрстку текстом (потоком документа). Контроллер отвечает за любой функционал, например генерация меню с "хлебными крошками", выдернуть новости с конкретной даты или выдать статичную страницу. Есть PageComposer, в который регистрируем все контроллеры по функциональному тегу (content, widget, navigation etc). Штука простая, выполняет шаблон генерируя события-метки в шаблоне (header, menu, content etc). Используется только для полных (X)HTML страниц, ибо одна страница содержит массу контроллеров, которые взаимодействуют друг с другом. Например контроллер с тегом content может послать сообщение всем контроллерам с тегом navigation о том, что он сейчас будет показывать (ресурс). Для XML сервисов PageComposer не используется, ибо почти всегда выполняется ровно один контроллер. Есть RequestDispatcher, задача которого рассмотреть входные параметры и выбрать какой процесс запустить. При этом работаем не только с REQUEST_URI, а вообще с чем угодно, т.е. без mod_rewrite и подобных трансляторов продолжаем работать (что конечно плохо). Подобная гибкость конечно заставила возложить генерацию ссылок на ResourceMap, который всегда генерит правильные ссылки. Оба класса используют XML схемы, разумеется кешируемые. Процесс сдержит информацию как инициализировать PageComposer и какие контроллеры к нему добавить. Затем страница отрабатывает и рисуется. За один запрос отрабатывает один процесс. Так сделал я. Код ещё отшлифовывается и документируется, будет в ближайшие две недели положен в http://svn.vingrad.ru/svn/vijio/ImaEngine/ На lib/view не обращаем внимания, устарели. Дерево view обьектов оказалось не удобным. Сейчас используются множества помеченные тегами, что гибче.

Автор: ImamMahdi 15.2.2008, 14:58

Я вообще считаю, ядро должно состоять из одного базового класса, в которому не нужно ни интерфейсов, ни абстракция. Суть этого базового класса - подключение всего остального: драйвера (конфигов, бд, etc), контроллеры модулей и т.п. Также ядро должно организовывать взаимодействие между контроллерами модулей - этакое подобие взаимодействия уровней в сетевых протоколах, например TPC/IP

Автор: Wowa 17.2.2008, 12:24

Цитата(ImamMahdi @  15.2.2008,  13:58 ) Я вообще считаю, ядро должно состоять из одного базового класса, в которому не нужно ни интерфейсов, ни абстракция. У меня тоже такие мысли.. Пока не вижу необходимости излишне усложнять.

Автор: CyClon 25.2.2008, 10:12

Хм... По мне так, ядро - это один файлик, например /kernel/kernel.php... У меня так: Код <?php require_once 'kernel/config.php'; function __autoload($class_name) {     $class_name = str_replace('_', '/', $class_name);     require_once 'kernel/classes/' . $class_name . '.class.php'; } Ну, и далее пляшем от этого. Т.е. в ядре в основном иклюдятся конфиги/классы и так далее. Не понимаю, какие функции должно еще выполнять ядро. Работа с бд - уже дело определенного класса, шаблонизатор - то же самое. Логгер или еще что-то - туда же  Как считаете? Или хотя бы опишите, что ваш класс ядра будет делать, кроме как инлюдить конфиги.

Автор: ImamMahdi 29.2.2008, 12:28

Цитата(CyClon @ 25.2.2008,  10:12) Как считаете? Или хотя бы опишите, что ваш класс ядра будет делать, кроме как инлюдить конфиги. Он больше ничего и не должен делать. Просто обеспечивать взаимодействие между драйверами и модулями. Котролировать что должно быть подключено, что далжно быть отработано.

Автор: Sardar 29.2.2008, 14:57

"Ядро" в PHP - штука IMHO бессмысленная. Цитата(ImamMahdi @  29.2.2008,  11:28 ) Просто обеспечивать взаимодействие между драйверами и модулями. О каком взаимодействии идёт речь? Любой класс, любая функция доступна штатными средствами (require/include), динамическая подзагрузка кода по требованию - это лишняя потеря производительности. Если указать require  константной строкой, то парсер ещё при первом проходе поднимет файл, а следовательно и кеш кда сохранит сразу полный имейдж, а не по сорцы кусочкам. Любой копонент публикует свой функционал в виде статических методов "входного" класса (фасад). По любому ты знаешь, что используешь. Взаимозаменяемые по функционалу модули должны описываться общими интерфейсами (в смысле сущности interface). Движок PHP отвечает за всё остальное.

Автор: ImamMahdi 29.2.2008, 15:05

Цитата(Sardar @  29.2.2008,  14:57 ) О каком взаимодействии идёт речь? Лень много писать. Почитайте как взаимодействуют уровни в TCP/IP протоколе. Мб станет ясно

Автор: Sardar 29.2.2008, 15:11

Цитата(ImamMahdi @  29.2.2008,  14:05 ) Почитайте как взаимодействуют уровни в TCP/IP протоколе. Интересное сравнение...  быть может я путаю, под взаимодействием считается концептуальные вещи, в коде же само ядро - лишь набор коментариев (guide-line)? ;-) Хотя пример не удачный, IP оборачивает TCP, добавляя понятие адреса (+сам протокол адрсации, TTL и т.д.), второй же вводит понятие порта (+ понятия коннекта, sequence и т.д.). Могу расписать побайтово, т.к. это был один из моих проектов (сетевуха на микроконтроллере). Корреляции с понятием "ядра" в этом топе не вижу...

Автор: ImamMahdi 29.2.2008, 15:17

Ясно, что ясно не стало. Нашелся лишь повод кинуть "понт"

Автор: solenko 29.2.2008, 17:04

Цитата О каком взаимодействии идёт речь?  Например о сообщеиях типа "авторизация пользователя", "изменение контента" etc. Конечно, если нет общего понятия контента, то нет и необходимости в большинстве этих сообщений. Правда тогда и наповедение этого контента можно повлиять только если залезть в исходники. Да и систематизировать те же блоги сможет только модуль "блог" и никто больше. То, как я вижу это пытался изложить в  http://forum.vingrad.ru/index.php?showtopic=197424&view=findpost&p=1421344 Цитата Любой класс, любая функция доступна штатными средствами (require/include), динамическая подзагрузка кода по требованию - это лишняя потеря производительности. А отсутсвие подгрузки по требованию -- статичный набор модулей. Цитата Взаимозаменяемые по функционалу модули должны описываться общими интерфейсами (в смысле сущности interface). Вот и добрались до самого интерестного. "Ядро" и должно определять эти интерфейсы.

Автор: Sardar 29.2.2008, 17:30

Цитата(solenko @  29.2.2008,  16:04 ) Например о сообщеиях типа "авторизация пользователя", "изменение контента" etc. Смотря как реализовать. Пусть: Код $user = User::currentUser(); $user->checkPermission('gallery.upload'); //throws SecurityException if($request->existsParam['commit']) {    $img= Gallery::newImageFromFile($_FILES['imgupload']['tmp_name']); //throws NotFoundException    $img->name = $request['imgname']; //throws IllegalValueException    //... } else {   //генерим формы etc. } Как такового ядра (код) не существует, есть лишь принцип дизайна, которому следуют все компоненты. Цитата(solenko @  29.2.2008,  16:04 ) А отсутсвие подгрузки по требованию -- статичный набор модулей. А чем плох статичный набор модулей? При использовании кода ты точно знешь, какой интерфейс ты собираешся использовать (в Java к тому же это на этапе компиляции проверить можно). Реализация набора интерфейсов может изменятся на момент исполнения, ты же не привязан к конкретному коду. Интерфейс - контракт, что и как ты хочешь использовать. Цитата(solenko @  29.2.2008,  16:04 ) Вот и добрались до самого интерестного. "Ядро" и должно определять эти интерфейсы. Как при проектировке "ядра" узнать какие интерфейсы будут в компонентах системы? Слишком абстрактные интерфейсы типа .get/.set и .callByName - штука глупая в PHP.

Автор: solenko 29.2.2008, 20:12

Цитата А чем плох статичный набор модулей? При использовании кода ты точно знешь, какой интерфейс ты собираешся использовать (в Java к тому же это на этапе компиляции проверить можно). Реализация набора интерфейсов может изменятся на момент исполнения, ты же не привязан к конкретному коду. Интерфейс - контракт, что и как ты хочешь использовать. Я бы не брал на себя отвтственность за решение "пользователю понадобится это и только это" Вы osCommerce случайно не проовали расширять?) Он спроектирован так, что добавлять можно только модули оплаты и доставки. Все остальное лепят программисты путем изменения core исходников. Мягко говоря очень неудобно, не говоря уже о user friendly.  Цитата Как при проектировке "ядра" узнать какие интерфейсы будут в компонентах системы? Вы читали то что я предлагал в соседней ветке? Я предлагал вынести в ядро некоторые базовые понятия. В частности, такие как контент, форма, пользователь.  Кроме того, я считаю, что система должна быть event-ориентированной, т.е. каждый модуль может добавить листенер на core объект (контент, форма, пользователь) и, соответственно, породить такое событие. Т.е. если есть некий модуль, занимающийся... ну например блогом и модуль, который в этот блог добавляет маааленькую фичу (например добавление поля со ссылкой), то достаточно обработать события (form, load, save) контента (blog) и выполнить действия.  Также должна быть возможность регестрировать новые виды событий (например модуль оплаты товара должен регестрировать событие "оплата завершена").

Автор: Sardar 29.2.2008, 22:19

Цитата(solenko @  29.2.2008,  19:12 ) ? Я предлагал вынести в ядро некоторые базовые понятия. В частности, такие как контент, форма, пользователь.  Всё, понял, за ядро принимаем набор базовых компонент, хотя и не обязательно "совершенно необходимых" (к примеру юзер не везде нужен). Просто было предложение: Цитата(ImamMahdi @  29.2.2008,  11:28 ) Просто обеспечивать взаимодействие между драйверами и модулями. Было интересно о каком взаимодействии идёт речь. Жаль что мысль испарилась вместе с автором... Цитата(solenko @  29.2.2008,  19:12 ) Я бы не брал на себя отвтственность за решение "пользователю понадобится это и только это" Так я не о пользовательском функционале говорю, а о банальной организации кода. Если есть несколько классов, способных выполнить задачу и им помощь некоторого общего "ядра" не требуется, то значит оно (ядро в понятии ImamMahdi) и не нужно вовсе...  То что ты называешь "ядром", обычно зовут коллекцией основных библиотек. К примеру http://svn.vingrad.ru/svn/vijio/ImaEngine/ (это лишь  кусочек движка, извиняюсь за жуткий код, писалось давно  ), можно взять Cache::getCache(.. и использовать. То же самое для любого другого компонента системы, причин писать отдельный код для "взаимодействия" пока не вижу...

Автор: solenko 1.3.2008, 16:33

Sardar, разница следующая -- программисты библиотеки могут использовать базовые классы должны При запросе конкретной записи блога запрос не идет на модуль "блог". Он иет на модуль "контент", который формирует базовый объект контента и отправляет сообщение другим модулям, которые могут этот объект дополнить/изменить. Т.е. в обход модуля "контент" работать просто нельзя.

Автор: Sardar 1.3.2008, 19:49

Цитата(solenko @  1.3.2008,  15:33 ) Т.е. в обход модуля "контент" работать просто нельзя. В принципе стандартный подход. В принципе ничего плохого в этом нет, хотя навязывает идею писать "плагин" для модуля "контент", не всегда удобно если "контент" не достаточно гибок. Ещё была идея полной анархии в движке  Представим есть дипетчер запросов, он ловит все запросы, согласно файлу-схеме (простой XML) находит и запускает "процесс". "Процесс" поднимает компоненты, как это прописано в его схеме, не вдаваясь в подробности зачем этот компонент и что он будет делать (к примеру инклюдит класс, вызывает статический метод). Компонент поднимает необходимые ресурсы (DataBase::getConnection(); Configuration::get(..); Output::registerProvider("me", $this) etc), затем сам делает полезную работу, формирует DOM дерево и ожидает пока его заберут. Он без понятия что будет с этими данными, как их отформатируют и куда вставят. Общий шаблонизатор поднимает необходимые шаблоны, как это задал дизайнер, собирает страницу. Именно "схема процесса" описывает всех провайдеров данных и применение к ним шаблонов. Главный шаблон раскладывает инфу по местам на странице. Заметим нет понятия ядра/проклейки, компоненты не обязательно должны знать друг о друге (хотя контент-генератор может сказать компоненте-главное-меню, что сейчас открыт такой то ресурс, хотя это можно реализовать и более элегантно). Все компоненты используют коллекцию базовых библиотек независимо друг от друга (один раз открытое БД соединение используется всеми). Удаление одного компонента не вызовет каких то проблем с зависимостями, можно даже Output удалить, все будут работать, только на выводе будет формироваться пустая страница (или страница ошибки, нет компонента-провайдера страницы). 2модератор - по моему пора разделить тему, последние посты во "Внутренняя организация движка" могут пойти.

Автор: solenko 1.3.2008, 22:04

Sardar, ты с drupal не знаком (думаю стоит ли пытаться расписать)? Просто идея, которую я пытаюсь продвинуть, вышла как раз оттуда. Там как раз и есть почти полная анархия + базовое понятие node, что позволяет оперировать контентом единообразно. Цитата не всегда удобно если "контент" не достаточно гибок. "контент" это несколько полей для сохранения в базу (title, user, дата создания и т.д.) + набор событий. То, что получается очень гибко доказано все тем же друпалом. Вот только он из за своей гибкости слишком уж  тяжеловесен -- хотелось бы найт золотую середину.

Автор: Sardar 1.3.2008, 22:13

Цитата(solenko @  1.3.2008,  21:04 ) думаю стоит ли пытаться расписать Стоит, быть может по ходу мыслей придём к удобному дизайну/архитектуре движка. Возьми для этого новую тему

Автор: Mushu 1.6.2008, 16:32

А может попробывать реализовать на модели VCL ...?

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)