Шаблоны AJAX в ASP.NET - Недостатки модели одностраничного интерфейса
ОГЛАВЛЕНИЕ
Недостатки модели одностраничного интерфейса
Хотя модель SPI и предоставляет более интерактивное обслуживание пользователя, она и воплощенная в ней парадигма AJAX сопряжены с рядом проблем, включая возможность поиска, управление журналом, доступ и поддержка автономного режима. Веб-страницы отслеживались с использованием постоянных ссылок не один год. Поисковые механизмы выстроили свой бизнес путем простого сопоставления набора ключевых слов с одним или несколькими URL-адресами. Эта модель работала, основываясь на предположении, что каждое состояние в веб-приложении соответствует странице и определенному URL-адресу.
С появлением модели SPI в AJAX это предположение более не верно. Если всё (или хотя бы основная работа) происходит внутри одной страницы, то смены URL-адреса, отмечающего новое состояние и новое содержимое веб-узла, не происходит. Как следствие, не существует простого способа связать содержимое (и ключевые слова) с уникальными URL-адресами. Этот аспект модели SPI влияет на возможность поиска, а также на управление журналом (скажем, на возможность использовать кнопки «Назад» и «Вперед»).
Журнал обозревателя может со временем стать устаревшей концепцией, тесно привязанной к классической, статической модели Интернета. Тем не менее, следует помнить, что пользователи настолько привыкли к этим кнопкам, что их нельзя просто отключить.
Доступность – еще одна большая проблема приложений AJAX. Для большинства популярных программ озвучивания текста любое содержимое, созданное сценариями модели DOM, создает огромные сложности. По своему замыслу все формы AJAX, включая частичную визуализацию, в большой степени основаны на сценариях модели DOM. Следовательно, доступности необходимо добиваться другими средствами.
Раздел 508 руководства по доступности содержимого Интернета (Web Content Accessibility Guidelines – WCAG) рекомендует, чтобы страницы предоставляли альтернативный функциональный текст, который может быть прочтен вспомогательной технологией, каждый раз, когда они используют языки сценариев для отображения содержания или создания визуальных элементов. Тег <noscript> существует для обеспечения выполнения этой рекомендации. В настоящий момент большинство инфраструктур AJAX производят свои динамические обновления внутри страницы, не обновляя статическую информацию, содержащуюся в тегах <noscript>.
Функционально насыщенные приложения Интернета со специальными возможностями
Проблема кажется состоящей из двух частей, которыми являются как приложения AJAX, так и технология в основе озвучивателей текста. С одной стороны, существуют озвучиватели текста, которые понимают некоторые из клиентских событий, таких как onclick, keypress и readystatechange. Способность озвучивателя текста замечать эти события может оказаться достаточной, чтобы добавить, по крайней мере, первый уровень специальных возможностей для большого числа приложений на основе AJAX.
С другой стороны, озвучиватели текста обычно не говорят никакой новой информации, если они зашли далее события первоначальной загрузки страницы в DOM. Но существуют некоторые фокусы, которыми можно воспользоваться, чтобы сообщить озвучивателю текста об изменении в чем-либо. Один из наиболее эффективных включает установку tabindex на -1 в корне обновленного древа DOM. Однако это простой фокус, и специальные возможности заслуживают более широкого решения на основе AJAX.
Возможным решением является новый стандарт, разрабатываемый в W3C и именуемый стандартом функционально насыщенных приложений Интернета со специальными возможностями (ARIA), который в основном состоит из относящихся к озвучивателям тегов HTML. Несколько популярных клиентских библиотек AJAX уже поддерживают некоторые компоненты ARIA. Но если смотреть более широко, проблема состоит не только в наличии совместимого с AJAX стандарта специальных возможностей. Проблема лежит также, если не в особенности, в содержимом (разметке и сценарии), реально создаваемом серверными элементами управления.
И как насчет автономных приложений? Многие разработчики считают, что автономные приложения AJAX невозможны, поскольку приложения AJAX строго привязаны к Интернету. С моей точки зрения, это мнение чересчур упрощено, но не ложно в целом. В наше время, почти все веб-приложения – AJAX или не AJAX – основаны на Интернете или интрасетях.
Но приложения, не использующие AJAX, определенно могут работать в автономном режиме. Например, в случае управления журналом всю функциональность, делающую возможными переходы в автономном режиме, содержит обозреватель. В классических веб-приложениях каждый запрос HTTP управляется обозревателем. Если подключение недоступно (и перед созданием ошибки HTTP 404), обозреватель просматривает локальный кэш страниц.
Приложение AJAX отличается от классического веб-приложения тем, что оно использует объект XMLHttpRequest вместо механизма обозревателя для отправки запросов HTTP. Чтобы приложения AJAX поддерживали автономные сценарии, нужно просто дать объекту XMLHttpRequest либо доступ к кэшу обозревателя, либо способность создавать собственный кэш посещенных страниц и управлять им. Эта возможность начинает появляться в составе некоторых платформ AJAX. Однако это нетривиальное изменение, поскольку оно требует доступа к диску изнутри кода JavaScript.