Цитата:
Если у нас нету опыта, чтобы учитывать наперед, то мы хоть запроектируйся, все равно чего нибудь забудем. А если опыт есть, то нет смысла детально описывать все модули с ходу. Это конечно IMHO, но основанное на опыте
Ну, допустим, некоторый опыт есть. Если не в области разработки порталов, то по крайней мере в области разработки промышленного расширяемого кода. Так что не все так плохо. :)
Предложенный список более чем правильный. И именно подобную (расширяемую) структуру хотелось бы получить в итоге.
Цитата:
1. Подключаемость модулей (в том числе взаимную - чтобы к модулю соревнования можно было подцеплять ленты новостей или часть новостей прикреплять к конкретным соревнованиям);
Обычно делается так: регистрация модулей проводится при помощи центрального координатора (фактически, топология "звезда") с последующим предоставлением каждым модулем некоторого набора сервисов (например, провайдер ленты новостей - отличный пример подобного сервиса).
Вывод: у модуля должен быть внешний интерфейс, доступный другим модулям, позволяющий узнать предоставляемые им сервисы.
Цитата:
2. Система поиска по всему сайту;
Аналогично можно реализовать через механизм провайдеров. То есть модуль предоставляет интерфейс для выполнения операций индексирования и поиска.
Цитата:
3. Система навигации по всему сайту;
Вот это не очень понял. Общее дерево всех разделов? Тогда опять можно было реализовать через механизм провайдеров...
Цитата:
4. Подключение шаблонов (как всего сайта, так и модулей);
Вот слово "шаблон" нужно уточнять. Слишком много смыслов может быть. Пока что безусловно рассматривается возможность использования двух типов шаблонов: шаблон страницы (в рамках модуля) и шаблон соревнования (общая информация, информация для рубрикатора, принципы построения команд для модуля регистрации и т.п.)
Цитата:
5. Порядок передачи параметров в модули при отправке форм и т.п.;
Пропущено слово "основных". :) Фиксация формата нужна лишь для основных параметров. Плюс, имеет смысл вводить понятие пространства имен, чтобы исключить взаимодействие параметров разных модулей при отправке форм. Но, кстати, пространства имен в любом случае возникают, поскольку систему авторизации тоже надо строить по подобному принципу, когда права не зафиксированы заранее, а могут предоставляться конкретным модулем.
Цитата:
6. Система авторизации, группы пользователей и наборы прав;
Да. Это без вариантов.
Цитата:
7. Определить порядок публикации и сборки обычных страниц со вставками из модулей;
Пока предполагается такой подход: портал имеет некоторый внешний программный интерфейс, через который внешние модули (коннекторы) могут закачивать в портал информацию, собираемую из внешних источников. Подобная подкачка может выполняться в одном из двух режимов: премодерируемом и постмодерируемом.
Цитата:
8. Определить порядок использования и хранения разнообразных меню (верхние/нижние/левые/правые);
Скорее определить правила интеграции модулей в единое целое. Как следствие появятся правила формирования страниц портала, правила формирования меню и т.п.
Цитата:
9. Если будет нечего делать - сделать WYSIWYG-редактор для страниц
:)
Для начала было бы неплохо предусмотреть минимальный редактор, наподобие редактора задач на Тимусе.