Отказ от ответственности: это было сказано ранее по-разному — например, поиск для отделения навигации от структуры или отделения поведения от структуры — просто добавив мой спин.
Идея отделения контента от стиля, в значительной степени, становится общепринятой нормой веб-дизайна, преимущества хорошо известны
Недавно я подумал о том, чтобы отделить браузер от ресурса . Под «браузером» в данном контексте я подразумеваю элементы пользовательского интерфейса в веб-приложении, которые позволяют пользователям перемещаться (перемещаться), изменять контент (формы) и т. Д., В то время как «ресурс» означает документы / контент, опубликованные на веб-сайте.
Есть несколько подсказок для этой линии мышления;
— Личная жалоба: я ненавижу писать интерфейсы администратора для веб-приложений. «Интерфейс» — то, что видят посетители сайта — не проблема, но интерфейс администратора, который, как правило, и более сложный, и в то же время видимый только для группы ограниченного использования, сводит меня с ума — много работы для людей, которые склонны иметь очень развитые мнения.
— Еще одна личная жалоба: я (вообще) ненавижу использовать интерфейсы администратора. Например, просмотр / управление списком пользователей может быть болезненным. Одни и те же инструменты администратора перезагружаются при каждом запросе страницы (замедление работы). Переключение между списком пользователей и видом отдельного пользователя приводит к чрезмерным запросам к БД (если только я не умный с просмотром вкладок — т.е. нарушая предполагаемое использование интерфейса). И такие вещи, как функциональность поиска, никогда не бывают достаточно мощными, по сравнению, скажем, с работой в командной строке с помощью grep или попыткой поиска и замены (примечание: название инструмента года: http://fart-it.sourceforge.net/ ) ,
— Понятие REST (передача представительского состояния), как оно было поднято в диссертации Роя Филдинга и аккуратно изложено здесь . Некоторое время назад Джефф начал дискуссию на Sitepointforums о REST , задав вопрос: «Есть ли что-то, что мы можем применить к веб-приложениям, ориентированным на пользовательский интерфейс?». Моя интерпретация REST с точки зрения веб-приложения звучит так: «REST, похоже, предлагает вам документы, представленные URL-адресами, и инструменты для их редактирования (и, возможно, навигации)». Мервин делает ряд проницательных комментариев в дискуссии, такой как эта . Суть; «В чем преимущество архитектуры на основе REST?», По-видимому, заключается в том, что «ресурсы» (контент / данные) ваших сайтов становятся доступными не только для веб-браузеров — их могут «потреблять» различные типы приложений (веб-сервисы, специализированные десктопы) инструменты управления контентом, агрегаторы блогов и т. д.).
— Последние версии IE и Mozilla имеют приличную поддержку XSLT (как продемонстрировано в RSS-канале Sitepoints). Это открывает возможность публикации «браузера» отдельно от «ресурса» — для веб-браузеров они могут загружать навигацию / инструменты для «просмотра» сайта отдельно от просматриваемых документов, в то время как другие приложения, использующие эту функцию, могут просто игнорировать таблицы стилей. Данная таблица стилей может применяться ко многим документам на сайте (возможно, даже ко всему сайту), поэтому ее нужно загрузить только один раз. XSLT не для всех, но думаю, иллюстрирует смысл «липких» определений пользовательского интерфейса, которые остаются в браузере, в то время как документы / ресурсы загружаются отдельно.
— Последние версии IE / Mozilla также имеют «работоспособные» реализации Javascript. Под этим я подразумеваю, что его соответствие стандартам составляет 95%, и в наши дни меньше усилий для написания кода, который прекрасно работает в обоих браузерах. Постепенно веб-разработчики начинают понимать, что JavaScript намного больше, чем кажется на первый взгляд . Если вы посмотрите на этот пример, вы получите картину. Мощные пользовательские интерфейсы могут быть построены таким образом.
— Имея XMLHttpRequest, доступный в Mozilla, IE и Safari, используя Javascript, можно создавать «липкие страницы», которые предоставляют все элементы пользовательского интерфейса, необходимые для сайта. Другими словами, вы начинаете с загрузки страницы, которая содержит все необходимое для меню , вкладок и даже окон . С «липкой страницы» можно загружать ресурсы через XMLHttpRequest.
— Богатые веб-клиенты, возглавляемые XUL , находятся на горизонте. Я экспериментировал с «улучшением» (на самом деле ухудшением в этом случае) пользователей, просматривающих опыт, прежде чем использовать XUL. Предоставляя «липкое меню», для поиска отдельных документов больше не требуется многократная перезагрузка страницы для перемещения по навигации, которая обычно отображается как «встроенная» как статический HTML. На практике DHTML по-прежнему является более безопасной ставкой, чем XUL сегодня, но думаю, что XUL преуспевает в том, чтобы заставить людей переосмыслить сеть, какой мы ее знаем.
На мой взгляд, основными преимуществами отделения браузера от ресурса являются гибкость и повторное использование.
Документы / данные, которые вы публикуете на своем сайте, становятся (потенциально) доступными для использования другими приложениями, кроме веб-браузеров, и, надеюсь, сохраняют свою актуальность по мере развития технологий. Делая это разделение целью, становится возможным разрабатывать / собирать стандартные инструменты / виджеты (DHTML или другие), которые можно применять ко многим сайтам; возможно предтечей здесь является настольный агрегатор блогов. Возможность «grep» или поиска и замены в качестве администратора сайта с использованием той же утилиты командной строки имеет более высокую вероятность.
Как побочный эффект, полоса пропускания также сохраняется, и воспринимаемая производительность, с точки зрения конечного пользователя, должна быть улучшена, поскольку пользовательский интерфейс загружается только один раз.
В любом случае — это звучит правдоподобно с кем-либо?