Ранее я писал о декораторах для веб-страниц и о том, работают ли они по принципу «тянуть» или «толкать». Эта статья была ограничена декораторами, которые работали над разметкой HTML в ее текстовой форме. Это были неявно серверные технологии. Напомним, что одной из технологий, о которых говорилось, был легендарный Sitemesh («site-mesh» — Сири произносит этот компонент «sit-e-mesh», вздох) Джо Уолнеса.
Я также недавно написал о том, как Google обеспечивает последовательную топ-навигацию по нескольким приложениям . Это в той же области, которая вызывает озабоченность, хотя не совсем украшения Оказывается, Google также прошивал сайт на стороне сервера.
Классический способ Sitemesh сшил опыт сайта
Фильтр 
ermeslet для Sitemesh берет любую страницу приложения и оформляет ее перед отправкой в браузер одним куском. Это также хорошо работает для статического контента. Сами приложения часто находились на одном веб-сервере, но я показываю разные веб-серверы, которые поддерживает Sitemesh. Поддерживаются разные технологии, такие как Perl или PHP.
Как Google сделал для сайта опыт для нескольких приложений?
Каждое приложение было своим собственным сервером, но фрагменты сайта были вставлены в определенные части страницы. Раньше я исследовал только верхнюю навигацию, но дизайн одинаков для нескольких вставляемых частей страницы. Выше я показываю, что «опыт сайта» передается через HTTP-запрос на боковой веб-сервер, но я действительно не знаю. Это могла бы быть функция библиотеки так же легко , что означает, что технология была эффективно связана при сборке. Интеллектуальное кэширование прямоугольников для каждого пользователя на стороне сервера делает его быстрым в любом случае.
Отделка в ДОМ
Возможно, однако, вы не привыкли обслуживать главное охватывающее окно слишком много раз в день (на пользователя). В наши дни мы должны рассмотреть возможность использования таких декораторов на стороне клиента:
Главная страница приложения загружается, а затем вытягивает столько дополнительных прямоугольников сайта, сколько необходимо. Браузер обрабатывает кеширование для прямоугольников, поэтому следует тщательно выбирать время ожидания. Это может быть внедрение в пустые DIVs со страницей. Это также может быть дизайн, который использует iframes.
Чтобы декоратор работал в браузере, он должен быть подкован в DOM. Вот гипотеза о том, как это будет работать:
- Страница извлекается браузером как обычно (GET)
- Определяется, что сайт «украшения» необходимо, а затем применяется.
- Повторите # 2, пока не будет больше декораторов для применения
- Подарите страницу конечному пользователю — фу!
Невозможно заблокировать первый показ страницы до ее оформления. Или, может быть, вы можете заблокировать это, но это не будет легко или гладко. Конечно, W3C не может участвовать в цикле загрузки страниц. Тем не менее, по крайней мере. Вместо этого фреймворки, такие как AngularJS, используют для этого технику маскировки .
А как насчет Sitemesh.js?
В 2001 году Джо Уолнес (он много фигурирует в этой записи в блоге) работал в компании, использующей старую технологию ASP ASP от Microsoft, и хотел провести несколько разделений в стиле Sitemesh. Технологии того времени не поддерживали его, поэтому Джо попытался сделать это на JavaScript. Вот что он вспоминает (и я копирую / вставляю из его письма мне, и это не совсем рабочий код):
Samplepage · HTML:
<html>
<body>
<script src="sitemesh.js"></script>
some vanilla html here
</body>
</html>декоратор · HTML:
<html>
<body>
... all your common stuff ...
<div id="sitemesh-body"></div>
... more stuff
</body>
</html>SiteMesh · ЯШ:
onload = function() {
// grab the content of the current (undecorated page)
var content = document.body.innerHTML;
// create hidden <iframe src='decorator.html'>
var iframe = doucment.createElement('iframe')
iframe.style.display = 'none' // hide
iframe.src = 'decorator.html'; // load decorator in iframe
document.body.appendChild(iframe);
// copy vanilla contents from current page into sitemesh decorator placeholder
var sitemeshPlaceholder = iframe.content.document.getElementById('sitemesh-body');
sitemeshPlaceholder.innerHTML = content;
// finally, replace all the contents of this page, with
// the contents of the merged content in the iframe
// (this also ends up deleting the iframe)
document.outerHTML = iframe.content.document.outerHTML;
}Утомленный путешествием вниз по переулку памяти, Джо заканчивает тем: «Я уверен, что было много маленьких причуд, чтобы выработать, но это основная суть»
Это не идеально, и опыт разработчиков DOM мог бы указать на вековые отношения любовь / ненависть с iframes в центре этого несовершенства. Это не будет чувствовать себя совершенно правильным в использовании, из-за проблем фокуса. Также внутренний iframe и внешний non-iframe не имеют одинаковые URL. Подробнее об этом позже.
Что бы сделал Джо сегодня?
Возможно, это все еще клиентское решение iframes, говорит он. Один с жестким набором стандартов пользовательского интерфейса. Я процитирую из другого письма Джо, где он описывает использование iframe для этого, которое находится в производстве и полностью аналогично приведенному выше:
За и против
Плюсы:
- Простота составления страниц: точка интеграции — это URL (каждый из них может быть запущен с другого сервера)
- Сильное разделение: функции CSS, JS и т. Д. Не могут вытекать
- Легко разрабатывать содержимое iframe изолированно (без страницы контейнера)
- Может использовать window.postMessage () для создания связи между кадрами на основе сообщений
- Позволяет полный выбор технологий стека в кадре
Минусы:
- Подобная сборка страницы может выглядеть как путаница: вам нужны строгие рекомендации по пользовательскому интерфейсу, и во многих случаях вы можете поделиться css с виджетами, зависящими от стека технологий.
- Некоторые вещи могут быть неловкими. Например, если фрейм имеет фокус, он будет воспринимать события клавиатуры с главной страницы. И глобальный обработчик загрузки сложен. Я рекомендую разделить общую библиотеку js на все кадры, чтобы помочь координировать
Его мысли о других решениях:
В заключение
(Я снова — не цитирую Джо)
Оформление на стороне клиента этого сайта не понравится поисковому роботу Google или их боту для предварительного просмотра.
Вы должны действительно беспокоиться о задержке и хрупкости, если вы идете в этом направлении. Необходимо реализовать блокировку / маскировку, по крайней мере, до тех пор, пока она не станет стандартом W3C, если все ваши производственные настройки не будут такими быстрыми, что никто не заметит. Если в вашем сообществе зарегистрированы пользователи, а не пользователи, которые щелкают по Reddit, то, возможно, они более щедры к опыту и с большей вероятностью воспользуются кэшированными элементами.
Кроме того, существуют проблемы с фокусом и URL-адресами, которые больше или меньше в зависимости от того, какое из клиентских решений вы выберете.