Главная > AJAX, ExtJS Framework, Open Source, web2.0, Разное > ExtJS.UpdateManager — удобное средство обновление частей страницы — I.

ExtJS.UpdateManager — удобное средство обновление частей страницы — I.

21 октября 2007

Приветствую всех наших читателей. Исследуя статистику запросов к нашему сайту со дня его открытия, я заметил, что, в основном, у нас самой популярной темой является библиотека ExtJS. Ну а раз так, то мы теперь будем регулярно публиковать не только новости о развитии этого инструмента веб-разработчика, но и начинаем серию статей об особенностях использования библиотеки в своих проектах. Я потратил на изучение ExtJS уже около полугода, хотя, признаюсь честно, там есть еще много неизвестных мне моментов, но я не претендую на глубокие познания - все, что мы опишем, это следствие только нашего скромного опыта и познаний, подкреплённые доступной в интернете информацией и обсуждениями с коллегами.

Сегодня мы поговорим об использовании компонента библиотеки, а именно классе EXT.UpdateManager и его расширениях. Он позволяет очень и очень просто внедрить базовый AJAX-функционал в любую веб-страницу (к которой подключена библиотека ExtJS конечно), и получить возможность обновлять любой элемент страницы без необходимости ее полной перегрузки. Как он это делает? Сейчас мы это узнаем.

И так, имеется на самом деле три класса:

  • UpdateManager - это базовый класс, который и выполняет всю необходимую нам работу. С ним вы и будете иметь дело.
  • UpdateManager.BasicRenderer - это класс, который отвечает за обновление элементов, в терминах библиотеки - Render.
  • UpdateManager.defaults - объект, содержащий основные настройки "по-умолчанию", используемые в UpdateManager-е.

Свое знакомство мы начнём с последнего объекта - UpdateManager.defaults. Он вам понадобится, если нужно переопределить какие-то стандартные настройки, причём глобально, для всех менеджеров на странице. Из интересных нам параметров следует выделить:

  • disableCaching - указывает на необходимость отключения кёширования. Если установить его в значение true, то UpdateManager будет каждый раз наново запрашивать обновлённое содержимое и обрабатывать его. Для реализации этого менеджер будет каждый раз добавлять уникальное значение к строке запроса, поэтому серверу все запросы будут казаться новыми. Кстати, тут может быть сложность, так как в практике я заметил, что этот уникальный параметр именно добавляется каждый раз, то есть с каждым разом количество параметров в запросе вырастает, как и общая длина запроса. Это может быть неприемлемым (как я помню, ведь существует ограничение на длину GET HTTP запроса). Служебные параметры имеют имя "_dc" и на стороне сервера их можно, при необходимости, стразу удалить из $_REQUEST (здесь и далее подразумевается, что серверным языком реализации является РНР 5.2+).
  • indicatorText - HTML-код, который видит пользователь, когда содержимое какого-либо элемента обновляется. К примеру, это текст "Идет загрузка данных...". При старте обновления менеджер временно заменяет содержимое обновляемого элемента страница на указанный код.
  • loadScripts - разрешает UpdateManager-у проверять полученный HTML-код на наличие скриптов (в тегах <script></script>) и автоматически выполнять его. К примеру, если у вас там будут определены функции или переменные, то они будут добавлены в текущую область видимости (в глобальную). На практике экспериментов я ещё не ставил, но в данном случае советую писать полную версию тега <script> - с атрибутами language и type. Конечно, при использовании сложного кода в такому случае могут возникнуть разные сложности, потому вариант включения важного кода в обновляемую страницу нужно использовать осторожно, лучше вынести в отдельный подключаемый файл. Кстати, если вы используете отладчик, к примеру, Firebug, то такой код нельзя будет отлаживать при помощи точек останова и т.п., придётся только использовать API, к примеру вывод в консоль через console.log().
  • showLoadIndicator - позволяет скрыть или наоборот, показать индикатор загрузки/обновления содержимого (то есть, показывать или нет текст, установленный в indicatorText). По умолчанию установлен в true.
  • sslBlankUrl - применяется при работе с сервером по протоколу SSL. Значение этой опции и ее работа мне пока, к сожалению, неизвестна, потому если кто из читателей опишет детальнее в комментариях, буду благодарен.
  • timeout - время ожидания ответа сервера, по умолчанию это 30 секунд, после чего запрос отклоняется и считается неудачным. Параметр указывается в секундах. Насколько я разобрался, в случае превышения этого времени и отсутствия ответа сервера у UpdateManager-а происходит событие failure.

Вот, с основными настройками мы ознакомились, теперь перейдём на уровень выше. Именно обновлением заведует класс BasicRenderer, который в стандартном варианте умеет обновлять только элементы DOM. Но ведь можно точно таким же образом обновлять и другие объекты, к примеру - JSON или XML, или просто определённые переменные JavaScript. Это придется делать самостоятельно - сначала создав обьект с методом render, который принимает два обязательных параметра: первый, строковый или экземпляр Ext.Element, который указывает на тот объект или переменную, которую обновляем, а также responce - объект, содержащий сами данные, которые получены от сервера. При необходимости вы можете обрабатывать как угодно полученные данные, обновляя любой тип переменных или объектов. Заметьте, что responce в данном случае - объект типа YUI Connect, поэтому для получения данных используйте его свойства.

А теперь и главный объект - UpdateManager, который скрывая от нас все эти ньюансы, берет на себя всю черновую работу, в то же время позволяя управлять основными параметрами обновления. У него достаточно много свойств и методов, поэтому мы рассмотрим лишь самые важные и те, которые используются в типичных ситуациях.

Но для начала еще раз об архитектуре обновления при помощи UpdateManager. Глобальные параметры устанавливаются при помощи свойств UpdateManager.defaults, далее, при необходимости, отдельные из них могут переопределятся в каждом конкретном вызове менеджера. В общем же случае, он принимает два параметра - имя узла, который нужно обновить, и URL, откуда брать новые данные. Далее к указанному адресу добавляется (при необходимости) служебные переменные, выполняется HTTP запрос с использованием компонента XMLHTTPRequest (на самом деле используется другой компонент библиотеки, инкапсулирующий кроссбраузерный вариант - Ext.Ajax), а после получения данных (или сброса запроса по таймауту или в случае ошибки) - вызивается UpdateManager.BasicRenderer, точнее его единственный метод render, которому передаются все необходимые данные. Он заменяет содержимым свойство innerHTML указанного узла и, при необходимости, выделяет из полученных данных код JavaScript (используя RegExp) и выполняет их через eval.

Какие же свойства и методы UpdateManager могут вам пригодится?

  • defaultUrl - это URL, который вызывается каждый раз при вызове метода update() и заменяется на последний использованный. Его можно установить как через UpdateManager.defaults, так и вручную вызвав метод setDefaultUrl(URL), который в дальнейшем и будет сохранен как URL по умолчанию. Но тут есть нюанс - если установить параметр discardUrl в false, то свойство defaultUrl не будет заменено на новый URL. Например, необходимо на один вызов использовать другой URL, то можно не бояться за сохранность дефолтного адреса, в дальнейшем при очередном вызове update() будет снова использоваться именно он.

Продолжение следует...

  1. 23 декабря 2008 в 19:05 | #1

    sslBlankUrl — это URL пустой страницы, которую Ext использует в качестве исходной для iframe. Эти iframe используются для Ajax-овой загрузки файлов. Ну и чтобы избежать IE-шных предупреждений о загрузке ресурса из несекьюрной зоны, вы можете задать URL пустой страницы, которая лежит за SSL.

    • 24 декабря 2008 в 12:42 | #2

      спасибо! теперь разобрались со всем в Updater-е. В 2.2 вроде немного поменялось но несущественно, так что материал все еще актуальный

  2. Petrovich
    30 апреля 2009 в 14:19 | #3

    «…с каждым разом количество параметров в запросе вырастает, как и общая длина запроса. Это может быть неприемлемым (как я помню, ведь существует ограничение на длину GET HTTP запроса)…»

    HTTP/1.1
    Протокол HTTP не накладывает a priori никаких ограничений на длины URI. Серверы ДОЛЖНЫ быть способны обработать URI любого ресурса, который они обслуживают, и им СЛЕДУЕТ быть в состоянии обрабатывать URI неограниченной длины, если они обслуживают формы, основанные на методе GET, которые могут генерировать такой URI. Серверу СЛЕДУЕТ возвращать код состояния 414 (URI запроса слишком длинный, Request-URI Too Long), если URI больше, чем сервер может обработать

  3. 22 мая 2011 в 20:45 | #4

    Excellent post I wish I lived there so I could go and see her.
    yurtdışı eğitim

Комментирование отключено.