nSite

1. Система разрабатывается на Zend Framework и следует всем его законам
   Преимущество: понятность системы большому количеству разработчиков благодаря чётко документированному процессу написания кода и взаимодействия отдельных частей системы; не требуется освоение новых правил специально для этой системы.
2. Система состоит исключительно из модулей, каждый из которых можно легко заменить.
   Преимущество: высокая приспособляемость под конкретный проект при минимальных усилиях
3. Каждый модуль пишется однократно и в дальнейшем в нём только устраняются ошибки, но не добавляется новой функциональности. Вся новая функциональность реализуется в других модулях (которые могут основываться на уже существующих)
   Преимущество: образуется большое количество стабильных модулей, которые можно спокойно использовать для своего проекта, не опасаясь, что в во второй версии он будет полностью несовместим с предыдущей версией.

Идея очень простая, но эффективная. Вот маркап:

<a href=’#'>Заголовок ссылки <span>Подсказка</span></a>

Итак мы хотим, чтобы посетитель видел только заголовок ссылки, а подсказку видел при наведении мышкой.

  a {
	z-index:10;
  }
  a:hover {
	position:relative;
	z-index:100;
  }
  a span {
	display:none;
  }
  a:hover span {
	display:block;
	position:absolute;
	float:left;
	white-space:nowrap;
	top:-2.2em;
	left:.5em;
	background:#fffcd1;
	border:1px solid #444;
	color:#444;
	padding:1px 5px;
	z-index:10;
  }

Span мы спрячем, и покажем только когда мышка будет над ссылкой. Тогда сработает цсс селектор a:hover span. Также мы позиционируем a:hover релативно, а a:hover span абсолютно.

Источник.

В результате интересной дискуссии на Хабре был предложено очень полезное решение установки css-стилей для верхних и нижних индексов (тэги <sup> и <sub>)

sup { vertical-align: baseline; position: relative; top: -0.4em; }
sub { vertical-align: baseline; position: relative; bottom: -0.4em; }

Будем использовать этот способ в css-файле, который ставится по умолчанию для контентной области.

Проанализировав руководство пользователя по реализации моделей, контроллеров и видов, я пришёл к мнению, что реализация MVC в Zend Framework ближе к исходной архитектуре MVC, предложенной Trygve.

Вид никаким образом не контактирует с моделью, а все данные для отображения ему задаёт Контроллер.

Контроллер общается как с Видом, так и с Моделью. Он изменяет состояние Модели в соответствии с действиями пользователя и передаёт необходимые данные Виду.

Модель не зависит ни от Вида, ни от Контроллера и не имеет понятия об их реализации.

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

В результате получаем следующу стратегию использования триады MVC.

Вид.
Содержит в себе только информацию для представления пользователю и простейшие правила её представления (если пользователь авторизован – вывести его имя, если не авторизован – вывести форму авторизации).

Контроллер.
Воспринимает данные от пользователя. Проводит валидацию данных от пользователя на предмет хакерских атак (валидация логичности данных находится в модели). Инициирует изменение свойств Модели в соответствии с действиями пользователя. Инициирует необходимый Вид. Передаёт сформированные Моделью данные в Вид. Запускает Вид на отображение.

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

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

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

Впервые архитектура MVC была описана Trygve Reenskaug, когда он работал над Smalltalk в Xerox PARC в 1979 году. Но непосредственное внедрение MVC в Smalltalk происходило уже без Trygve, и архитектура была реализована не совсем так, как предлагал Trygve.

В результате под термином MVC понимают два варианта реализации архитектуры Модель-Вид-Контроллер:

Версия Trygve

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

Smalltalk-версия.

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

Источники и дополнительные материалы по теме:

1. MVC XEROX PARC 1978-1979
2. Программирование приложений в Smalltalk-80: Как использовать Model-View-Controller (MVC) eng
3. Wikipedia
4. MVC для начинающих и для интернета в частности
5. Обобщённый Model-View-Controller
6. The Definitive Guide to symfony
7. Триада MVC в действии
8. Особенности реализации насыщенных пользовательских интерфейсов Веб-приложений (MVC в DHTML)
9. Ещё много полезных ссылок из Яндекса по правильному запросу