З огляду на широке розмаїття засобів, підтримуваних різними браузерами, іноді непросто створити додаток, яке працює з усіма браузерами, забезпечуючи найкращий з можливих призначений для користувача інтерфейс. Платформа ASP.NET пропонує кілька засобів, які можуть допомогти в написанні коректної розмітки, що працює на різноманітних пристроях.
клас HtmlTextWriter
Платформа ASP.NET пропонує дуже різну розмітку, яку бачить клієнт, так що один клієнт отримує HTML 3.2. інший - HTML 4.0. а третій - XHTML 1.1. Можна навіть не підозрювати про настільки суттєві відмінності.
Все це працює через клас HtmlTextWriter, який має кілька похідних класів. Сам HtmlTextWriter спроектований з урахуванням висновку розмітки HTML 4.0. Але його похідні класи відрізняються: так, Html32TextWriter записує розмітку HTML 3.2 для клієнтів нижнього рівня, a XhtmlTextWriter - розмітку XHTML 1.1. Оскільки всі ці класи успадковані від HtmlTextWriter, ви вільні використовувати в коді візуалізації той же самий базовий набір методів HtmlTextWriter. Однак реалізація багатьох цих методів відрізняється, так що в залежності від того, який об'єкт був отриманий, висновок може відрізнятися.
Наприклад, припустимо, що використовується наступний код візуалізації:
У цьому випадку очікується така розмітка:
Але нижче показаний результат, який буде отриманий від Html32TextWriter (виходячи з припущення, що Html32TextWriter.ShouldPerformDivTableSubstitution одно true):
З іншого боку, якщо використовується наступний код, то візуалізований висновок буде абсолютно негнучким і ніколи не зміниться в залежності від можливостей цільового пристрою:
Аналогічно, якщо проводиться спадкування від WebControl для отримання автоматичного підтримки для властивостей стилю, ця підтримка реалізується по-різному, в залежності від визуализатора.
З цього випливає, що необхідно уникати написання низкоуровневой HTML-розмітки (з використанням методу Write ()), а замість цього, де тільки можливо, використовувати високорівневі методи (такі як RenderBeginTag (), RenderEndTag () і т.д.). В результаті елементи управління стануть більш гнучкими. ASP.NET створює і передає коректний HtmlTextWriter, який заснований на функціональності браузера, що запросив сторінку, і з'явиться можливість адаптації HTML-розмітки.
Ця проблема тепер не настільки критична, як раніше, тому що більшість поширених браузерів підтримують XHTML. Проте, це правило хорошого проектного рішення, яке гарантує надійну працездатність коду в разі, коли ASP.NET буде оновлено для підтримки нових типів візуалізації, які не володіють поки широко поширеною підтримкою.
визначення браузера
Отже, яким же чином з-поміж ASP.NET визначає тип класу записи тексту, який підходить для конкретного клієнта? Тут все залежить від рядка користувацького агента, яка передається клієнтом, коли він здійснює запит. ASP.NET намагається зіставити цей рядок з величезним каталогом відомих браузерів. Ви можете знайти цей каталог в C: \ [Каталог Windows] \ Microsoft.NET \ Framework \ [Версія] \ Config \ Browsers. Там можна знайти безліч файлів .browser. Кожен є HTML-файл, який відображає рядок користувацького агента для установки можливостей і класу записи тексту.
Кожен файл .browser має наступну базову структуру:
Ця система може здатися досить крихкою. На жаль, так воно і є. Немає ніяких гарантій, що не зустрінеться браузер з рядком, яка не відповідає жодному з відомих шаблонів. Однак це неминучий компроміс в слабо пов'язаному світі Інтернету, і творці ASP.NET досить непогано попрацювали над тим, щоб інформація про браузерах, що поставляється з ASP.NET 4.0, була надійною і більш повної, ніж в попередніх версіях. Налаштування браузерів можна також підлаштовувати і навіть додавати нові визначення різних рядків користувацьких агентів.
властивості браузерів
Визначити конфігурацію поточного браузера можна за допомогою властивості Browser об'єкта HttpRequest, яке повертає посилання на об'єкт HttpBrowserCapabilities. (Отримати рядок user-agent можна також через властивість UserAgent.)
Коли клієнт виконує HTTP-запит, створюється об'єкт HttpBrowserCapabilities, який заповнюється інформацією про можливості браузера на основі відповідного файлу .browser. Інформація, представлена в класі HttpBrowserCapabilities, включає вид браузера і його версію, чи підтримує він виконання сценаріїв на стороні клієнта і т.д. Визначивши можливості браузера, можете скорегувати свій висновок для забезпечення такої різниці у поведінці в різних браузерах. Таким чином, можна повністю розкрити потенційні можливості клієнтів верхнього рівня, не порушуючи роботу низькорівневих клієнтів.
У таблиці нижче перераховані властивості класу HttpBrowserCapabilities:
Властивості класу HttpBrowserCapabilities
Надає старший номер версії виконуючого середовища .NET CLR, встановленої на клієнтському комп'ютері. Можна також використовувати метод GetClrVersions () для отримання інформації про всі версіях встановлених CLR-середовищ. Ця настройка важлива, тільки якщо на веб-сторінці є вбудовані елементи керування .NET Windows Forms. Клієнтські браузери не потребують CLR для запуску звичайних сторінок ASP.NET
Повертає true, якщо клієнтський браузер підтримує елементи керування ActiveX
Клас HttpBrowserCapabilities має одне кидається в очі обмеження - він може визначити тільки очікувану вбудовану функціональність браузера. Він не може визначити поточний стан цієї функціональності.
Фактично все, що насправді робить ASP.NET - це читає інформацію для користувача агента, передану від браузера на сервер під час запиту, і порівнює цей рядок з визначеною інформацією в файлах .browser. У файлах .browser перераховані можливості браузера, такі як функціональність підтримки сценаріїв, стилів, фреймів і т.д. На жаль, клієнт не присилає відомостей про те, як налаштований браузер.
Ця ситуація залишає два вибори. Можна покластися на клас HttpBrowserCapabilities в отриманні інформації про доступність певних коштів браузера і засновувати програмну логіку на цій інформації. В цьому випадку ви повинні бути готові до випадкових помилок. Якщо ж ви віддаєте перевагу більш стійкий підхід, доведеться писати власний код так, щоб він самостійно перевіряв підтримку потрібного засобу.
Ці кроки досить незграбні і заплутані, але це єдиний спосіб отримати повну впевненість в доступності певних коштів браузера. На жаль, при створенні спеціальних елементів управління зазвичай ви позбавлені можливості виконання подібних перевірок.
Зміна визначення типу браузера
Платформа ASP.NET надає можливість явно задати, як візуалізуватиметься сторінка, замість того, щоб покладатися на автоматичне визначення браузера. Трюк полягає в установці властивості Page.ClientTarget. або програмно (на стадії Page.PreInit>, або декларативно (з використанням директиви Page). У випадку установки властивості ClientTarget автоматичне визначення браузера відключається і для іншої частини запиту ASP.NET використовує установки браузера, зазначені вами.
Єдиний нюанс, пов'язаний з використанням властивості ClientTarget, полягає в можливості використовувати тільки певні псевдоніми. Кожен псевдонім відображається на специфічну рядок користувацького агента (і установка браузера для цього призначеного для користувача агента оголошена у відповідному файлі .browser).
Наприклад, припустимо, що необхідно перевірити, як сторінка буде візуалізувати в застарілому браузері на кшталт Internet Explorer 6. Для початку потрібно створити псевдонім в розділі
Тепер можна змусити сторінку використовувати цей псевдонім і візуалізувати себе, як ніби-то запит надійшов від Internet Explorer 6, встановивши в ie6 атрибут ClientTarget директиви Page. Ось як це робиться:
адаптивна візуалізація
В ідеалі вдається згенерувати розмітку, яка буде працювати у всіх основних браузерах. Але в деяких випадках доведеться писати специфічну для конкретного браузера логіку візуалізації. У гіршому випадку це виглядає приблизно так:
Кращий підхід передбачає використання елемента управління для виведення стандартної візуалізації і створення адаптера елемента управління, який реалізує спеціалізовану візуалізацію для певного браузера. Модель адаптера елемента дозволяє створити єдиний елемент управління, який може бути адаптований для різних типів пристроїв. Найкраще те, що завдяки такому відділенню елементів управління від адаптерів незалежні розробники можуть писати адаптери для існуючих елементів, даючи їм можливість працювати з будь-якою платформою.
Будь-який елемент управління пов'язується з адаптером в файлі .browser. Наприклад, можна створити адаптер FirefoxSlideMenuAdapter, який змінює код візуалізації елемента управління SlideMenu так, що він краще працює з браузерами Firefox. Потім знадобиться відредагувати файл mozilla.browser, спеціально вказавши, що даний адаптер повинен використовуватися з браузерами Firefox.
Адаптер елемента управління працює за рахунок включення в процес візуалізації. Платформа ASP.NET викликає адаптер на кожній стадії життєвого циклу веб-елемента управління, що дозволяє адаптера втручатися в процес візуалізації і обробляти інші деталі, такі як логіку стану уявлення, специфічну для пристрою.
Щоб створити адаптер, успадкує новий клас від System.Web.UI.Adapters.ControlAdapter (якщо спеціальний елемент керування успадкований від Control) або від System.Web.UI.WebControls.Adapters.WebControlAdapter (якщо спеціальний елемент керування успадкований від WebControl). Потім реалізуйте необхідну функціональність, перевизначаючи потрібні методи. Кожен метод відповідає методу класу спеціального елемента управління, і якщо метод в адаптері елемента управління перевизначений, метод адаптера буде використовуватися замість методу елемента управління.
Як і в випадку серверних елементів управління, адаптери повинні бути поміщені в окрему DLL-збірку. Якщо адаптери відносно прості, їх можна помістити в ту ж саму збірку, яка містить елементи управління. Однак якщо адаптери складні і спроектовані для підтримки індивідуальних сценаріїв використання, краще помістити їх в окрему збірку.
Наприклад, в ControlAdapter можуть бути перевизначені такі методи, як OnInit (), Render () і RenderChildren (). У WebControlAdapter можна також перевизначити RenderBeginTag (), RenderEndTag () і RenderContents ().