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


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

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


Не все так просто. Добавить еще одно поле - простая задача (в будущем в системе появятся, надеюсь, что-то вроде "дополнительные поля" - если будет необходимость), сделать, чтобы это поле выводилось, скажем, в общем и подробном просмотрах - тоже просто.. А вот сделать поиск по этому полю, связать это поле каким-то условием для отбора контента и т.п. - вот это уже непросто. А если это поле - форма для загрузки файла на сервер?? - нужно еще и предусмотреть его удаление! Такие случаи не имеют простых решений в два клика: по-любому придется либо самому лезть в код, либо нанимать человека. Решение зависит от выбранного геморроя.


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

По этому вопросу, наверно нет смысла дискутировать )

В том-то и дело, что это не просто. Зато такая система очень близка к идеальной.

Это прогресс, безусловно. НО не решает проблемы. все равно нужно копировать, переименовывать. а если этот модуль сохраняет файлы в определенной папке? клон будет тудаже пихать... а если модуль ставит куку или переменную в сессии определяет? клон и тут мешать будет.
так что, и тут не все так просто

"определенная папка" привязывается к имени.. Так что не будет проблем.


Тоже самое: идет привязка к имени модуля.


Это не так сложно. Даже интересно немного. Просто невозможно сделать автоматизированное копирование модулей! Считаешь иначе? - подскажи алгоритм.

Я тебе не предлагаю ничего автоматически копировать. Ты проникнись идеей: модули создаются просто в админке путем составления форм из полей. грубо конечно объяснил, но в этом суть. как эти структуры задавать - вопрос другой (то ли интерфейс какой выдумать, то ли в xml или еще как..) абсолютно все модули сюда вписать не получится, т.к. фантазия пользователя неисчерпаема), но большинство - это точно.

Это будут простые и бесполезные модули. ИМХО, конечно. Как по мне-идея утопическая: добавить поля и вывести их - это простая задача, а вот вдохнуть в эти формы жизнь, логику, взаимодействие - не получится.
Впрочем, можешь сам проникнутся этой идеей или показать живой пример..

ну почему же бесполезные и безжизненные?
ты посмотри на стандартные модули "Новости, Файлы, Статьи, ...." что в них меняется? название переменных, количество полей, языковые константы, название таблиц БД. т.е. кардинально ничего) они ведь содержат, как ты говоришь, жизнь и логику? так чем хуже, если такой же модуль пользователь создаст в админке? с теми же возможностями (редактор, рейтинг, коментарии и т.п.)
какая там особая логика?

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

в общем, тема о другом.. увлеклись как-то. если интересно, я готов продолжить в другом месте)

Как минимум:
-В новостях есть теги. Логика которых проработана очень хорошо.
-В файлах и медиа - есть отдельные страницы для файлов и картинок.
- Модуля "статьи" у меня вообще нет.

Общем модули схожи лишь поверхностно.. К универсальной абстракции их свести невозможно. Единственные модули, схожи на 95% - это "файлы" и "медиа". А все остальное - сходства не имеет..

идея аля ucoz - собери незнаек и дай им сломать что-нибудьв движке. Ну зачем это? пусть модули пишут люди, которые умеют это делать, а не делитанты
подставляют не знама что в поля. И в конце концов - напишите модуль-(тире) конструктор, а большинству от движка только и нада максимальную простоту и удобство.

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

Единая конфигурация
Конфигурации модуля файлы.
...
...
...

*и далее ничего если добавить какой то модуль или функцию даже блок хоть что нить у чего есть конфигурации они бы инклюдились в эту страничку то есть вот так*

Конфигурации модуля доска объявлений (new)

1. Ты ведь понимаешь, что названия я взял условно?
2. сложность в том и состоит, чтобы заставить эти "виртуальные" модули работать в контексте системы.

объясню мысль более подробно.
модуль новости (минимум).
состоит из 1 формы (ввод) и двух шаблонов (анонс и подробно)
Форма имеет свое уникальное имя (название модуля)
максимальный набор собственных полей в форме ввода. здесь же задаем параметры каждого поля: название, тип, обязательное, как его использовать (вывести, картинка, скачать файл, открыть страницу и т.п.; возможно скрипты какие-то привязать - типа событий)
В шаблонах, естественно, задается вывод. Используются поля определенные в форме + системные объекты

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


вот и я о том же примерно) писал уже раньше - все модули не получится под эту схему вписать. т.е. получится Контент (новости, файлы, анекдоты, цитаты и т.п.), Галерея, Форум, Блоги (да и то, если остальные модули по структуре сложнее новостей ).....

А ты задумайся, как данные хранить будешь? Кстати, Apostal, пользуйся знаками пунктуации, а то я ничего не понял.


Это невозможно, скажу сразу. Модули должны быть независимыми. Т.е. система никак не можут (и не должна!!) знать что из себя представляет каждый модуль, как он настраивается, на какие части делится и т.п.


Это называется "дополнительные поля" и мало-как относится к абстрагированию модулей. Так, если "дополнительные поля" нам нужно просто вывести ПОСЛЕ самой новости (в краткой или подробном просмотре) - пробежавшись алгоритмом по массиву данных, которые хранятся в ОДНОМ поле в сериализированном виде. То, для разработки нормального модуля каждое поле должно отдельно обрабатываться и хранится каждое в своей ячейке в таблице БД. Давай возьмем твой минимум за основу и попытаемся найти способ прикрутить к нему весь тот функционал, которой сейчас есть у модуля "Новости".
1. Заголовок - эта часть должна выводится в заголовке окна. (отдельный алгоритм).
2. Дата - по этому полю сортируются все новости в категориях. (необходимо отдельное поле).
3. Основная категория - по этому критерию производится отбор новостей при запросе категории (необходимо отдельное поле).
4. Отображать ссылку "подробнее" при отсутсвии расширенного текста? - необходимы проверки, присутствует ли расширенный текст (отдельный алгоритм).
5. Теги - это вообще отдельная система, включающая отдельную таблицу в БД.
6. Отображать в категориях (см п.3)
7. Доступно группам (см. п.3).
...

Эти вещи ты никак не абстрагируешь. А если будет возможность к каждому таком полю написать свой скрипт - то идея вообще неясна: зачем писать скрипты к дополнительным полям, если то же самое можно сделать и в коде модуля? За дополнительные поля я писал выше - может будут.

ладно. ты, похоже, не хочешь слышать.

Возможно. Я хотябы попытался. Закодил бы кто-то что-то похожее - я бы глянул, может быть и понял

У меня стоит на сайте кое что похожее требованиям patriot-a. Если интересно, могу показать вам.

Покажи

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