Warning: Cannot use a scalar value as an array in /home/admin/public_html/forum/include/fm.class.php on line 757

Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/include/fm.class.php on line 770
Форумы портала PHP.SU :: Версия для печати :: Новая архитектура CMS
Форумы портала PHP.SU » » CMS и фреймворки » Новая архитектура CMS

Страниц (6): [1] 2 3 4 5 6 »
 

1. man1 - 10 Марта, 2014 - 13:48:15 - перейти к сообщению
Захотелось в очередной раз вернуться к вопросу об архитектуре универсальной системы построения и управления веб-проектами/сайтами (далее СMS). Целью является спроектировать схему такой CMS. Приветствуется введение абстракций высокого уровня для сокращения кода. Присоединяйтесь к разговору, описывайте свое видение, предложения и т.д., а я, при вашей поддержке, постараюсь соединить это в единую
схему.

ВЕРСИЯ 0.1:

CODE (html):
скопировать код в буфер обмена
  1.  
  2. OBJECT = project
  3.    DATA = projects
  4.       ATTRIBUTE = name
  5.          DESCRIPTION_RU = имя веб-проекта
  6.          TYPE = text
  7.    OBJECT page
  8.       DATA = pages
  9.          ATTRIBUTE = name
  10.             DESCRIPTION_RU = имя веб-проекта
  11.             TYPE = text
  12.          ATTRIBUTE = title
  13.             DESCRIPTION_RU = заголовок окна страницы
  14.             TYPE = text
  15.          ATTRIBUTE = keywords
  16.             DESCRIPTION_RU = список ключевых слов
  17.             TYPE = text
  18.          ATTRIBUTE = description
  19.             DESCRIPTION_RU = текст описания страницы
  20.             TYPE = text
  21.          ATTRIBUTE = page.inc
  22.             DESCRIPTION_RU = файл макета страницы
  23.             TYPE = file
  24.  
2. caballero - 10 Марта, 2014 - 16:24:00 - перейти к сообщению
как вы можете что то соединить если понятия не имеете что делать?
(Добавление)
уже обсуждалось, кстати
http://forum.php.su/topic.php?fo...09331#1352109331
http://forum.php.su/topic.php?fo...49510#1308049510
3. man1 - 10 Марта, 2014 - 16:35:59 - перейти к сообщению
caballero пишет:
как вы можете что то соединить если понятия не имеете что делать?

Ну началось Ха-ха Я бы вам мог ответить что-то типа "докажите ваше утверждение", но это все лирика. Лучше напишите что-нибудь по делу. Хотя бы маленький аспект затроньте, чтобы был предмет для обсуждения.

(Добавлено)
Изучаю ссылки - учту в схеме. Но это не отменяет общения здесь.
4. caballero - 10 Марта, 2014 - 16:53:01 - перейти к сообщению
по какому делу?
Вы думаете можно накидать в кучу каких то аспектов а потом с них что то соединить?
Опишите вообще чего вы хотите и какие у вас проблемы.

Универсальная структура CMS - это ниачем.
(Добавление)
общение будет один к одному как было по этим ссылкам
5. esterio - 10 Марта, 2014 - 17:06:06 - перейти к сообщению
caballero пишет:
Универсальная структура CMS

Точнее не существует, ибо все учесть невозможно
6. digi - 10 Марта, 2014 - 17:16:46 - перейти к сообщению
На счет универсальности это вполне возможно. Например давно уже с другом разработали вот такую концепцию:

CODE (htmlphp):
скопировать код в буфер обмена
  1. http://smart-core.org/wiki/Алгоритм_(Архив)


Сейчас по большей части уже реализовано... заинтересован пообсуждать на сколько эта шуковина получилась "универсальной" ;)
7. esterio - 10 Марта, 2014 - 17:35:47 - перейти к сообщению
прорекламирую CMS пользователя DeepVarvar-а
http://www[dot]deep-cms[dot]ru/
Куда лучше архитектурой
8. digi - 10 Марта, 2014 - 18:37:13 - перейти к сообщению
Кстати да, на счет "архитектур" основанных на шаблонах, есть некоторые идейки ;)) можно будет реализовать, если кому-то понравится ;)

В общем вот наброски:

Как таковых "контроллеров" видимо можно и не делать ;))

Предположим, что вот так будем описывать наш сайт: https://github[dot]com/TDTeam/arfea/[dot][dot][dot]ree/dev/app/site

Это означает, что если пользователь запросил главную страницу http://site[dot]ru/ , значит будет выполнен шаблон: https://github[dot]com/TDTeam/arfea/[dot][dot][dot]/site/index[dot]twig

Допусти пользователь запросил страницу http://site[dot]ru/about/ , тогда будет выполнен шаблон: https://github[dot]com/TDTeam/arfea/[dot][dot][dot]/site/about[dot]twig в котором система автоматически подставит в качестве parent значение index.twig и будет соблюдена цепочка <html><title>

Далее, запрос http://site[dot]ru/about/contacts/ , выполнит шаблон https://github[dot]com/TDTeam/arfea/[dot][dot][dot]ut/contacts[dot]twig , а в качестве родительской уже выставит about.twig

Самое интересное, это работа с данными, например по запросу http://site[dot]ru/news/ , будет выполнен шаблон: https://github[dot]com/TDTeam/arfea/[dot][dot][dot]p/site/news[dot]twig , в котором сам шаблон достанет данные функцией
CODE (text):
скопировать код в буфер обмена
  1. {% set news = model('News') %}
и тутже их отобразит, при этом значение страницы можно будет прозрачно подхватить из параметра
CODE (text):
скопировать код в буфер обмена
  1. $_GET['page'];


В результате исходные коды проекта могут храниться в сжатом виде в phar формате, а файлы самого сайта будут достаточно лаконичны и просты. Здесь же можно предусмотреть и модульность. Также многое надо уделять работе с консолью т.к. для быстрой разработки надо предусмотреть ряд очень удобных инструментов. Кеширование в таком проекте тоже можно сделать очень продвинутым т.к. он рассчитан на простые сайты, а там можно кешировать буквально все страницы целиком.
9. Zuldek - 11 Марта, 2014 - 08:36:15 - перейти к сообщению
Цитата:
Как таковых "контроллеров" видимо можно и не делать ;))

Сервер обработки сообщений системы обмена сообщениями между пользователями социального сайта тоже во вьюхе будете делать? Или в могучую модель будете перемещать всю логику по обработке этих данных?

Обсуждение таких тем как универсальные CMS (в контексте именно универсальности, а не в контексте обучения программированию) обычно заканчивается тем, что их универсализм простирается от сайта-визитки-блога до корпоративного сайта и/или каталога, что охватывает лишь часть интернет-проектов.

Давным давно все пришли к согласию, что универсализм в широком смысле в проектировании интернет-сайтов достижим в контексте фреймворков, а не CMS. И то, зачастую, путём дописывания новых компонентов фреймворков, опираясь на базовые реализованные сущности. CMS обзывать фреймворками не нужно, их можно сделать на базе фреймворка, и, учитывая специфику новых задач при необходимости ( быстрее чем пересобирать свой велосипед) переделывать модули.
Двери давным давно выломаны несколько раз, починены и открыты, товарищи.
10. man1 - 12 Марта, 2014 - 10:07:55 - перейти к сообщению
МЫСЛЬ 1.

Что такое система построения и управления веб-проектами и сайтами?

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

Из вышесказанного следует, что система представляет собой примерно следующую структуру (далее будет уточняться):

/admin/
/data/
/modules/
/system/query.inc – функция межмодульного интерфейса
/updater/
(Добавление)


МЫСЛЬ 2.

В настройках сервера задаются доменные имена и каждому назначается корневая директория на сервере. Все клиентские запросы представлены в виде строки URL, состоящей из имени домена и пути к ресурсу (URI). Для скриптовой обработки запросов используется файл index.php. Для перенаправления запросов существует файл .htaccess (с модулем mod_rewrite).

Что это значит с точки зрения системы (CMS)? Представим что в одном серверном пространстве у нас есть несколько сайтов с разными доменными именами. Это бы означало, что для каждого сайта нужно было бы устанавливать свою копию системы и создавать свои index.php. Для устранения этой избыточности воспользуемся следующим способом: в настройках сервера для всех доменных имен назначим одну и ту же корневую директорию в которой будет лежать файл index.php и файлы системы в единственном экземпляре, а все запросы ко всем доменам будут обрабатываться в едином файле index.php. Отсюда у системы появляются такие свойства как мультидоменности и мультисайтовости.

Что касается URI, то они могут быть разного вида и их комбинаций:
/index.php?page=news&id=3;
/news/2014/03/14/
/about.htm
/contacts/index.php
/каталог/телевизоры/

Для поддержки всех возможных вариантов URI воспользуемся файлом .htaccess, который будет перенаправлять все запросы к любым доменам и URI в файл index.php. Тем самым реализуются такие свойства системы как ЧПУ и поддержка кириллицы.
11. digi - 12 Марта, 2014 - 11:24:04 - перейти к сообщению
man1 пишет:
мультидоменности и мультисайтовости.


пытался делать когда-то такую штуку... геморой не оправданный т.к. во первых всех ресурсы всех сайтов хранятся в одном месте и могут конфликтовать, а еще пытался в одной БД держать данных от нескольких сайтов - вообще мрак %)) фактически гораздо проще с точки зрения разработки держать каждый сайт отдельно, более того даже вендоры не надо делать общими т.к. нюансов может всплыть много и при "неудачном" обновлении одного проекта, может рухнуть вся система...

хотя в прицнипе некоторое подобие "мультидоменности и мультисайтовости" можно сделать, но только за счет конфигураций системы, а не впаенной в неё хардкора ;)
12. man1 - 12 Марта, 2014 - 11:53:54 - перейти к сообщению
digi пишет:
пытался делать когда-то такую штуку... геморой не оправданный т.к. во первых всех ресурсы всех сайтов хранятся в одном месте и могут конфликтовать, а еще пытался в одной БД держать данных от нескольких сайтов - вообще мрак %)) фактически гораздо проще с точки зрения разработки держать каждый сайт отдельно, более того даже вендоры не надо делать общими т.к. нюансов может всплыть много и при "неудачном" обновлении одного проекта, может рухнуть вся система...

хотя в прицнипе некоторое подобие "мультидоменности и мультисайтовости" можно сделать, но только за счет конфигураций системы, а не впаенной в неё хардкора ;)


Больше похоже на отговорку Ха-ха Данные сайтов конечно будут логически и физически отделены (файлы по разным папкам, а данные по разным базам данных). Для этого у каждого проекта (сайта) нужно ввести собственные настройки БД. При этом никто не отменяет возможность установки одной копии системы или нескольких, хочется - пожалуйста, но это не значит что надо отказываться от многосайтовости вообще.
13. digi - 12 Марта, 2014 - 13:08:44 - перейти к сообщению
Понятие "многосайтовость" слишком неоднозначное... например для пользователя - это возможность из некого единого интерфейса управлять несколькими его сайтами...

Программист же может подумать, что для него это будет единый набор исполняемых файлов а также все сайты в единой БД, где в таблицах везде есть поле site_id.
14. caballero - 12 Марта, 2014 - 13:59:49 - перейти к сообщению
многосайтовость нужна нечасто.
нет смысла усложнять систему изза редко используемой фичи.
15. Zuldek - 13 Марта, 2014 - 09:16:14 - перейти к сообщению
man1 пишет:
Пока не будем углубляться в частности. В самом общем виде, система - это набор директорий и файлов, обеспечивающих модульность с целью дальнейшей расширяемости функциональности системы по установленным правилам унификации модулей, а также интерфейс для связи между модулями. В систему также входит административная панель (GUI для настройки и управления системой, модулями и их данными) и механизм обновлений.


Дело в том, что это именно ваши мысли. В то время как в понятие Системы Управления Содержимым (CMS) в контексте сайтов входит только её представление, как системы обеспечения и организации совместного процесса создания, редактирования и управления контентом. А всё остальное — это ваши мысли на этот счёт. Вы считаете что лёгкая расширяемость под любые интернет-проекты и универсальность неотъемлимая черта CMS, но пратика популярных CMS показывает совершенно обратное, сохраняя возможности расширения функционала в рамках целевых задач и не претендуя на возможность построения на системе интернет-проекта любой специфики и сложности.

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

 

Powered by ExBB FM 1.0 RC1