my.life.logging.Blog

Wicket: Установка режима совместимости Internet Explorer

В 8-й версии всеми нами “любимого” ослобраузера Internet Explorer (далее просто IE) появилась одна очень интересная фишечка. Назвали ее режимом совместимости. Смысл ее состоял в том, чтобы позволить пользователю просматривать web-страницы таким образом, как будто они отображаются в одной из предыдущих версий IE (так, в IE8 предполагался режим совместимости только с IE7).

Как это закономерно случается со всеми хорошими начинаниями в IE, фича со временем стала предметом еще одного геморроя для web-разработчиков.

Поясню. Во-первых, количество режимов совместимости с выходом каждой новой версии браузера увеличивается (радует, пока что еще только в арифметической прогрессии). В 10-й версии браузера этих режимов будет уже туева хуча штук:

Режимы совместимости IE10

Во-вторых, если специально не говорить IE, в каком из режимов нужно отображать страницу, то он отображает страницу, как попало. Точнее, выбор режима отображения страницы зависит от большого числа не вполне контролируемых факторов, но выглядит это действительно так: как попало. :)

Для того, чтобы сообщить IE режим отображения страницы, используется заголовок ответа “X-UA-Compatible”. Детально все возможные его значения я рассматривать не буду. Об этом можно почитать, например, здесь.

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

Как оказалось, все три перечисленных далее способа будут работать только для версий 1.3.x и 1.4.x фреймворка. Вообще самым надежным способом решения задачи установки HTTP-заголовка “X-UA-Compatible” в более старших (для и вообще во всех) версиях Wicket будет написание фильтра в web.xml. Но это нельзя считать средством, которое предоставляет именно Wicket, поэтому, подумав, статью я решил не менять.

Вариант первый

На самом деле, установить режим отображения web-страницы в IE можно, всего лишь задав специальный заголовок META на странице. То есть, если мы хотим, например, чтобы IE показывал web-страницу всегда в режиме номера своей текущей версии, то нам достаточно вставить строку

1
<meta http-equiv="X-UA-Compatible" content="IE=Edge" />

в разметку (html-файл), соответствующую классу страницы Wicket.

Проблем тут две и они следующие:

  • Данная строка всегда должна идти сразу после открывающего тега <head> (пробелы тоже нежелательны! :)), иначе IE ее тупо проигнорирует. Это с некоторой долей вероятности может привести к проблемам при добавлении в коде страницы различных header contributor’ов и т.д.
  • Данный заголовок нужно будет указывать отдельно для каждой из страниц проекта, если, например, в вашем приложении используется несколько шаблонных страниц (или шаблонные страницы не используются вообще).

Вариант второй

Добавить заголовок META для всех страниц приложения можно с помощью следующей строчки кода в методе init класса приложения (потомка WebApplication):

1
2
3
4
5
6
7
8
9
10
public class MyApp extends WebApplication {
  ...
  @Override
  protected void init() {
    ...
    addRenderHeadListener(new StringHeaderContributor(
        "<meta http-equiv=\"X-UA-Compatible\" content=\"IE=Edge\" />\n"));
  }
  ...
}

Если эта строчка будет последним вызовом метода addRenderHeadListener в методе init, то необходимый нам заголовок с большой долей вероятности будет первой строкой в разделе <head /> на страницах приложения.

Но опять же не всегда.

Вариант третий

Чтобы указать необходимые нам параметры совместимости непосредственно в заголовке ответа для всех web-страниц, переопределим метод newRequestCycle класса приложения:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public class MyApp extends WebApplication {
  ...
  @Override
  public RequestCycle newRequestCycle(Request request, Response response) {
    return new WebRequestCycle(this, (WebRequest)request, (WebResponse)response) {

      @Override
      public WebResponse getWebResponse() {
          WebResponse response = super.getWebResponse();
          response.setHeader("X-UA-Compatible", "IE=Edge");
          return response;
      }
    }
  }
  ...
}

При этом нужно помнить о том, что указанный на странице заголовок META имеет приоритет над  HTTP-заголовком, который передается в response.

Такие дела. Наверняка, имеются и другие способы управлять режимом совместимости в IE средствами Wicket, но тратить слишком много времени на борьбу с вIEтренными мельницами не очень хочется.

Пойду я лучше готовиться к Хэллоуину. :) Начать никогда не рано, я считаю.

Лучший костюм для Хэллоуина

О книгах и копирайтах

Признаюсь вам честно, меня, как человека, не питающего особой любви к разного рода копирайтам (да и вообще к любым ограничениям), всегда смущал вопрос о книгах. С музыкой и фильмами в этом плане все более-менее понятно: музыку нужно слушать на концертах, а фильмы смотреть в кинотеатрах. К тому же есть исследования, показывающие, что чаще всего покупают музыку именно пользователи файлообменных сетей. С книгами, напротив, все далеко не так однозначно. Каждый раз, когда меня спрашивали, а на что собственно будут жить и творить авторы скачиваемых мною в Сети электронных книг, я отшучивался малоубедительными оправданиями о том, что типа это их личный выбор — писать или не писать. И если бы они не хотели, они бы, наверно, могли этого не делать. :)

Помощь в приобретении достойных аргументов против копирастии в издательском бизнесе пришла с неожиданной стороны…

Основатель издательской компании «O'Reilly Media» Tim O'Reilly опубликовал в заметке на Google+ свое мнение по поводу законопроекта SOPA, вызывающего в данный момент множество жарких дискуссий в США. В ней он в числе всего прочего пишет:

«Из моего опыта в O'Reilly, я могу сказать, что потери из-за пиратства далеко не так высоки по сравнению с преимуществами, которые дает свободное распространение информации, делающее мир богаче и создающее новые рынки для продажи легитимного контента. Большинство людей, которые скачивают незаконные копии книг O'Reilly, в любом случае никогда не стали бы платить за них; между тем, сотни тысяч других покупают контент у нас, и многие из них в странах, с которыми мы никогда не смогли бы иметь дело, если бы наши товары не были доступны в электронной форме.

История показывает нам, что фронтиры — это места, где законы не действуют, но в процессе того, как они становятся богаче и оседлее, они все больше попадают под верховенство закона. Американское издательское дело, сейчас крупнейшая издательская индустрия в мире, началась с пиратства… Британские издатели могли прийти в Америку в XIX веке; но они решили этого не делать, и в результате мы создали собственную местную издательскую индустрию, которая первоначально основывалась, не в последнюю очередь, на пиратском перепечатывании британских и европейских изданий.»

Legal downloads are killing piracy

Вот так-то! Свободный поток информации = PROFIT! и для издателей, и для читателей и для пиратов. И этот профит становится еще больше после того, как пираты, воспользовавшись полученными знаниями, становятся богаче и могут позволить себе покупать книги. :) Ведь зачем тратить время на поиск книги на развалах файлообменника, если есть простой и необременительный способ получить актуальную версию электронной книги в магазине издательства?

Подкастинг

Неожиданно для себя увлекся подкастами, посвященными IT-тематике.

Podcasting

Раньше думал: подкасты по программированию – как такое вообще может быть? Как в подкасте можно передать все технические подробности, связанные с реализацией какой-нибудь фичи на каком-нибудь ЯП?

И хотя некоторые из прослушанных мною подкастеров и пытались изредка начитывать в микрофон программный код (достаточно забавно, скажу я вам, слушать такое), оказалось, что прелесть подкастов совсем не в этом, а в представлении целостной картины по предмету. Технические подробности можно вполне загуглить впоследствии, а вот получению какой-то новой обобщенной информации – этому подкасты очень даже помогают.

При этом получить эту новую информацию можно вполне ненавязчиво: слушая подкасты на прогулке или в транспорте, или даже набирая код. :) В итоге узнаешь полезные штуки, о которых сложно было бы узнать, просто читая, например, блоги. И даже не потому, что информации в блогах сейчас очень много, и руки бы не дошли, а просто потому, что никогда не подумал бы смотреть в эту сторону.

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

И еще… Если подкаст англоязычный, то он, скорее всего, помогает совершенствовать знание английского языка. Ведь, как говорится, не знаешь английского - нечего делать в IT! ;)

I want you to speak English or get out!

Почему GWT захавает ваш мозг? :)

Интересный пост о недостатках Google Web Toolkit: “Why Google Web Toolkit Rots Your Brain”. Автор на полном серьезе заявляет, что готов написать магистерскую диссертацию на тему того, почему GWT - это из рук вон плохо. :)

Итоговый вывод поста следующий: “GWT полностью игнорирует природу Веба и воспринимает его в качестве неудобного интерфейса, использование которого нужно избежать любой ценой. И это удается, однако результат – отвратителен. В итоге разработчики не понимают основных парадигм и принципов Веба. Удивительно, какой объем работы затрачивается на создание инструментария, основанного на Java, в то время как, возможно, гораздо меньшее время можно было бы потратить на развитие хорошей JavaScript/HTML/CSS-библиотеки (YUI, jQuery, Ext, Scriptaculous), что только способствовало бы продвижению веб-стандартов”.

И, в общем-то, согласен с выводом на 90%, на основании собственного опыта работы с GWT. Действительно, отдельные desktop-ориентированные разработчики запросто умудряются клепать на GWT “поражающие воображение” страницы, которые в итоге поразительно сложны в оформлении, долго грузятся, тормозят в большинстве веб-браузеров и вызывают огромные утечки памяти в незаслуженно популярном Internet Explorer! :) Так стоит ли оно того?

Да, и хорошая новость здесь состоит в том, что веб-разработчики пока еще нужны. ;)

Java: использование оператора Instanceof с интерфейсом

a.k.a. Особенности использования оператора instanceof для проверки реализации объектом интерфейса в языке Java. Ведь, наверняка, кому-то длинные заголовки нравятся больше. :)

Обнаружил один интересный момент, касающийся реализации оператора instanceof в Java, о котором редко где упоминают.