Концепции современной CMS

[_RVK_]

Wingely Dog

кстати ктонибудь даст определение модулю

Я дал. Может не полное, но уж извиняйте....

для того чтобы можно было вставлять картинки из фотокаталога в статьи, можно хранить картинки в одном месте.

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

связанность между модулями имхо зло

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

 

[Gas]

кстати ктонибудь даст определение модулю?

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

В принципе согласен с этим. В рамках CMF, так же модуль использует базовые возможности/классы системы (DB, Error handling) и написан с учётом каких-то правил/стандартов.

связанность между модулями имхо зло.

Связь связи рознь. Вызов напрямую метода модуля A из модуля B - плохо. А вот "связать" как-то голосание и Image gallery это уже другое дело.

свалиться к банальному мерянью писюнами.

Не вижу в этом ничего плохого. Иногда можно почерпнуть что-то новое, взять и развить какие-то концепции.

 

[2NetFly]

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

 

[_RVK_]

2NetFly
Достичь этого не переписывая код других модулей, нереально, ИМХО. Модули должны знать хотя бы о возможности появления нового.

 

[2NetFly]

На примере модуля комментариев. Если в системе существует разделение на типы, то при добавлении комментария модулю к. необходимо знать только тип и ID комментируемой записи. При добавлении по типу определяется класс модуля, создается экземпляр объекта, вызывается метод isIdExists (из стандартного набора методов), которому предается ID и который возвращает булево значение. Если значение истинно, добавляем комментарий, иначе пишем сообщений об ошибке. Таким образом, при появлении какого-то модуля для того, чтоб интегрировать его с модулем комментариев достаточно будет в шаблоне прописать форму с указанным в хиденне типом.

 

[Screjet]

Модули должны знать хотя бы о возможности появления нового.

А это еще зачем?

 

[_RVK_]

2NetFly
Собственно это и называется API.

А это еще зачем?

Если по примеру предложенному NetFly: Cам модуль коментариев ничего не знает о других модулях. Получается что модуль статей пользуется возможностями модуля коментариев, но модуль коментариев ничего не знает о модуле статей, поэтому не имеет возможности воспользоваться последним. Полной интеграции все равно не получится.

 

[2NetFly]

А модулю комментариев и не нужно знать о модуле статей. О полной интеграции никто не говорит (лично я не говорю %). Пусть есть некоторое количество базовых модулей (комментарии, изображения, документы, голосования), которые могут быть интегрированы с любым другим модулем. Мне этого вполне достаточно.

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

 

[Screjet]

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

А ему и ненужно этого делать. Я бы назвал это противозаконным

Допустим, комментарию нужна статья: тогда коментарий создает в своем контексте статью и работает с ней.

Но этот "коментарий" уже не есть "коментарий" из примера 2NetFly. Сущность другая.

 

[_RVK_]

Ладно, еще проще: модулю "комментарии" нужно, в интерфейсе пользователей, разместить ссылки на все модули, которые его используют. Как это сделать? Сейчас у меня любой модуль может получить путь к любому из модулей, но только зная его имя. Етественно, если в момент написания модуля коментариев, не существовало модуля новости, то "коментарии" никак не могут знать имени модуля "новости", хотя и есть, общий для всех, метод получения пути GetPath($name). Вот об этом я и хотел сказать.

-~{}~ 06.12.04 15:15:

Или другой пример. Коментарии выводятся постанично, причем для "новости" по 20 на странице а для "статьи" по 10. Эти настройки задаются в интерфейсе к статьям и новостям соответственно, но выводом комментариев занимается модуль "комментарии". Как ему узнать, посколько на странице выводить те или иные комментарии?

 

[Wingely Dog]

о! пошел процесс! 8)

предлагаю всем поговорить о таких штуках, как плугинистость и клиент-серверная архитектура.

ЗЫ: Diesel. За базаром следи, я тебя вроде тупняком не назвал.

 

[_RVK_]

Wingely Dog

За базаром следи, я тебя вроде тупняком не назвал

Я тебя тоже, заметь. Все на твои посты я внимания не обращаю. Давно бы пора....

 

[2NetFly]

Или другой пример. Коментарии выводятся постанично, причем для "новости" по 20 на странице а для "статьи" по 10. Эти настройки задаются в интерфейсе к статьям и новостям соответственно, но выводом комментариев занимается модуль "комментарии". Как ему узнать, посколько на странице выводить те или иные комментарии?

Лично для меня эта проблема неактуальна %)
Для новости в шаблоне пишем:
[% INCLUDE &Comment::List("news_comment_list", { type => TP_NEWS}, { Limit => 20 } %]

Для статей:
[% INCLUDE &Comment::List("article_comment_list", { type => TP_ARTICLE}, { Limit => 10 } %]

Comment::List – это метод из дополнительного слоя (отображения), который обсуждается в соседней теме. Грубо говоря, некий view-API.

 

[_RVK_]

2NetFly
А как мне поменять твое значение limit? Только редактированием шаблона, верно? Но это уже не относится к тому, что мы сейчас обсуждаем, т.к. ни модкль 'коментарии', не модули "новости" и "статьи" ничего не зают об этих значениях. Или я ошибаюсь?

 

[2NetFly]

Да, в данном случае – редактированием шаблона. Но в общем случае, кто мешает сделать для каждого типа отдельный конфигурационный файл? Допустим, добавляется модуль новостей, о котором модуль комментариев ничего не знает. Создаем новый конфиг для модуля к., который будет действовать только для модуля новостей.

 

[_RVK_]

Ага, вот уже ближе. Просто у тебя выводом занимается не "коментарии", а отдельный универсальный View. Но если строго следовать MVC то выводом коментариев должен заниматься именно модуль "коментарии". Тогда у тебя ничего не выйдет. Потому что модуль "коментарии" не знает где лежит конфиг "новости".
Так, о чем это мы? Ах, да. Это я к тому что без правки кода (в том числе и кода шаблона), связать 2 модуля, в обе стороны, невозможно. Но сделать этот процесс наименее трудоемким, вот одна из задач при создании CMF.

 

[Screjet]

У 2NetFly конфиг интегрирован с шаблоном, но как он верно подметил, ничто не мешает использовать внешний конфиг. Каков вид/мерсторасположения = неважно ( у меня, напр. сериализованный массив). Кстати сий кофиг так же может быть аргументом модуля, раз такая необходимость

 

[2NetFly]

В моем случае выводом у меня занимается модуль комментариев, который содержит класс отображения (он является частью модуля). Метод List - это метод класса отображения. Классы отображения + шаблоны - это есть моя реализация View, которая не нарушает ни одно из "правил" MVC.

Что касается того, о чем мы %) Как я уже писал выше, лично я не стремлюсь связать модули в обе стороны. У меня есть четкое разделение: базовые модули и все остальные. Во все остальные можно интегрировать базовые, но не наоборот. Опять же, лично для меня предпочтительней сделать все возможное, чтоб при интеграции пришлось внести незначительные изменения в шаблон, а не в код. С теме же комментариями: врезали нужную форму, прописав два хидена, в нужном месте вызвали метод, который строит список и все дела. Этим у меня занимается верстльщик, который освоился менее чем за месяц.

 

[_RVK_]

Так, в конце концов в голове сформировалась некая структура будующей СMF.
Постараюсь описать.

Основа всего это древовидная структура где каждый узел имеет свои свойства, имя т т.д.
Для лучшего представления, того о чем я говорю вот скриншот приложения, служащего для управления такой структурой.

На основе этой структуры строится оболочка CMS.

Для каждого узла указывается XML документ который определяет структуру страницы CMS, действия(actions), каласс обработчик, валидаторы для полей, и т.д.
Перед выводом эта XMLка подвергается XSL преобразованиям, так же заданным для узла.

Таким образом от программиста требуется создать структуру, указать для каждого узла необходимые XML+XSLT документы, и написать классы модели, валидаторов и действий. (view пишется один раз).

Дело за малым. Нужно где то достать время на реализацию

 

[2NetFly]

Я тоже перенес регистрацию правил для валидации в главный xml-маппинг конфиг. Удобно. А для view по старинке использую шаблонизатор с возможностью вложенного вызова методов для построения контента, содержащихся в классах слоя отображения.