CTAPbIu_MABP's BLOG » Opera

Console2

CTAPbIu_MABP — Mon, 05 Jan 2009 17:54:46 +0000

Все меньше и меньше остается времени у шестого IE, все больше и больше сайтов объявляют, что они перестают поддерживать дизайн и скрипты для него. Напомню что шестой IE был выпущен в 1999 году то есть 10 лет назад, а до сих пор "популярен". Уже даже сам мелкософт заявил о том что будет распространять седьмой IE как стандартное обновление. Но эта тема все еще может быть актуально потому что даже в седьмом IE нет консоли, и потому что в Opera и у Safari она находиться в зачаточном состоянии по сравнению с firebug'ом. Так вот я и решил то пока еще не поздно написать вторую версию консоли. Заодно углубил свои знания и отточил практику. Теперь она работает еще быстрее и надежнее, хотя все еще не лишена кое каких глюков, например типа-массив arguments так и не покорился. И еще я не хочу чтоб вы думали что дальше я начну накладывать какие-то визуальные эффекты типа плавающих дивов вместо аллертов, я не хочу создавать второй furebug lite.

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

И собственно мои тест-кейсы:


window.onload = function(){
	console.log("string: %d %s %d", 10, "text", 10);
	console.info({});
	console.info([]);
	console.info(null);
	console.info(window);
	console.info(document);
	console.info(document.getElementsByTagName("body"));
	console.info(document.getElementsByTagName("body")[0]);
	console.info(Math);
	(function(z){try {x.y = z;}catch(e){console.info(e);}})(null);
	//(function(x,y,z){console.info(arguments)})(1,2,3); // fail

}

Консоль для всех браузеров

CTAPbIu_MABP — Thu, 25 Dec 2008 19:43:55 +0000

Это попытка заставить работать синтаксис консоли FireBug'a со всеми браузерами. ИМХО кроссбраузерный дебаг звучит не ок, но это именно он! А все получилось как-то само собой когда я сегодня что-то дебажил на тестовой платформе и для того чтобы тестеры не видели ошибок прикрывал вызовы консоли заглушками.


if(window.console)
	console.log("myLog");

В общем это как-то гнило, нашел что по данному поводу пишут разработчики Prototype и jQuery, и даже сами разработчики FireBug'a склоняются к заглушкам

Уж очень мне эти затычки не нравятся. И решил я выяснить что можно с этим сделать. Уточнив с какой версии у браузеров появилась консоль (и текущую версию): IE8b2 (IE7), Opera 9.50 (9.63), Safari 1.3 (3.21), FireFox 2.0.0 (3.0.5), я принялся за работу.

Первое что приходило на ум это что-то вроде


if (!window.console) {
	window.console = {};
	window.console.log = alert;
		
}

Но не все так просто, FireBug славится тем что показывает содержимое любого объекта и может делать форматированный вывод. То есть во-первых можно сделать


console.info({a:null});

и увидеть содержимое объекта в закладке DOM, а во-вторых можно сделать форматированный вывод


console.info("string: %d %s %d", 10, "text", 10);

и увидеть строку "string: 10 text 10". В остальных же браузерах можно наблюдать только строку [object Object] и "string: %d %s %d" соответственно, кроме IE8b2, он поддерживает форматный вывод, выпендрился, блин!

Я решил начать с написания форматного вывода, но функция sprintf оказалась настолько громоздкой и избыточной что я решил обойтись небольшим регулярным выражением, для своих нужд, тем более что FireBug тоже не различает %d и %s ;) в отличие от IE8b2 который корректно выводит 0 вместо %d которому соответствует строка. Из этого вывод что достаточно использовать только %s.

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

Уже неплохо. Последним штрихом к портрету было прикручивание уровня дебага "log", "debug", "info", "warn", "error". Тут для меня было несколько откровений. Первое это то что массив arguments не такой уже и массив потому что содержит в себе еще и метод callee. Второе - что объект arguments прекрасно превращается в массив с помощью волшебной строки


var args = Array.prototype.slice.call(arguments);

Третье - что этот метод не работает (правильно!) в IE7 и IE8b2, а поэтому не годиться. И наконец четвертое и последние что чертов arguments не возможно обойти циклом через in нужно обязательно это делать через длину


for(var i in arguments) // fail
	alert(arguments[i]);
for(var i=0,j=arguments.length;i



Но это все не помешало мне дописать сегодня этот скрипт и выложит его на ваше растерзание


myConsole = function(){
	var args = (function(a,x){for(var i=0,j=a.length;i2){
		(window.opera?opera.postError:window.alert)(args.shift() +'':\\n''+ args.shift().replace(/(%[ds])/g, function(){
			return args.shift();
			})
		)
	}else{
		// автор функции dump - Дмитрий Котеров
		// http://dklab.ru/chicken/nablas/38.html
		(window.opera?opera.postError:window.alert)(args.shift() +'':\\n''+ (function dump(d,l) {
			if (l == null) l = 1;
			var s = '''';
			if (typeof(d) == "object") {
				s += typeof(d) + " {\\n";				for (var k in d) {
					for (var i=0; i


Кому пригодиться пишите в каменты...



Dragonfly
CTAPbIu_MABP — Tue, 06 May 2008 16:06:40 +0000
Ура!!! Наконец то это свершилось! Сегодня вышел в свет дебагер для Opera под названием «Dragonfly». Он доступен в стандартном дистрибутиве браузера по умолчанию, начиная в версии 9.5 beta 2.
При большом внешнем сходстве с FireBug, Dragonfly имеет клиент-серверную архитектуру, то есть через какое-то время (после публикации протокола Scope) появятся плагины к Eclipse и другим IDE, из которых можно будет отлаживать страницы, отображаемые Opera. Это уже не просто расширение для дебага внутри браузера, а настоящий фреймворк для дебаггинга, где движком для рендеринга страниц и исполнения скриптов будет Opera, а дебаг-средой - выбранный самим разработчиком IDE, т.е. совсем необязательно тулза, встроенная в саму Opera. Это также позволяет работать не только с настольной Opera, а отлаживать, например, Opera для мобильных устройств, на экране которых толком и окно дебаггера не разместишь. И хоть «Dragonfly» еще очень сырой и далёк от заявленных фичасетов но, я думаю это веский аргумент в новом витке браузерных воин.





Простой comet
CTAPbIu_MABP — Sat, 26 Apr 2008 15:01:38 +0000
Всю неделю готовил эту статью, и вот наконец публикую.
Что же первое приходит в голову, когда видишь слово "comet", правильно - чистящее средство, потом комета, а оно почему-то означает технологию (хотя это, наверное, громко сказано, скорее паттерн) постоянного соединения с сервером. Все же в толстых книжках читали, что после того как сервер получил запрос и отдал ответ браузеру, он забывает, что к нему вообще кто-то обращался. А тут поседели умные люди и стали седыми. Нет, посидели и придумали идею, как заставить передавать браузеру информацию, изменившуюся на сервере.







Вот собственно об этом мы с вами сегодня и поговорим, а собственно я как обычно буду высказывать свои ламерские мысли, а вы, как обычно, будете комментировать...

И так с чего же начать, начать надо с того что выберем серверным языком php а клиентским как это не странно — javascript. Для того чтобы соединение не разрывалось, php скрипт должен все время работать, но тут мы встречаем два ограничения. Первое вполне логичное у нас нет бесконечного скрипта который бы все время что-то делал, да это и не надо, достаточно включить в код бесконечный цикл. А вот собственно второе ограничение уже куда более неприятное: по умолчанию php скрипт может выполняться только 30 секунд, после чего сервер выдает ошибку о зависании скрипта. С этим мы будем бороться, но об этом потом.
Теперь когда мы имеем серверную часть нужно придумать как она будет контактировать с клиентской. Для этого нужно написать еще какую-то функцию на javascript, которую бы мог вызвать сервер, причем это должно работать параллельным потоком относительно основной страницы. Для реализации параллельного запроса идеально подходит AJAX, но, к сожалению IE и Opera, не умеют корректно обрабатывать событие onreadystatechange==3 , поэтому для реализации параллельного потока в них используют iframe, а я буду использовать его и для остальных браузеров.

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


// устанавливаем неограниченное время выполнения скрипта
ini_set('max_execution_time', 0);

// начинаем буферизацию
ob_start();
// ставим флаг отдавать буфер каждый раз как он больше не нужен
ob_implicit_flush(true);

// отдаем заголовки, чтобы избежать кэширования
header('Expires: Sut, 01 Jan 2000 00:00:00 GMT');
header('Last-Modified: '.gmdate('D, d M Y H:i:s').' GMT');
header('Cache-Control: no-store, no-cache, must-revalidate');
header('Cache-Control: post-check=0, pre-check=0', false);
header('Pragma: no-cache');

// выбрасываем в поток килобайт пробелов, 
// это нужно из-за того, что php первый раз меньше отдавать не хочет
echo str_repeat(chr(32), 1024);
ob_get_clean();   

// в бесконечном цикле описываем то передачу информации в браузер
while(true){
	echo ""
		."\n";
	ob_get_clean();
	// ждем 1 секунду до следующего обновления
	sleep(1);
}


А вот и пример работы этого скрипта находиться сразу под кодом.

Hello from comet!

Теперь давайте разберем, клиентскую часть, она тоже весьма не большая. Как я уже говорил, ее задача в основном создать iframe и приаттачить нужные события. Событий может быть всего два: обновление с новыми данными и разрыв соединения с сервером. Оба события необязательные, потому что сервер и сам вполне может отдавать готовый javascript код, а разорванное соединение можно восстанавливать, а можно предположить, что все обновления с сервера уже пришли и новых больше не будет.


(function($) {

	// конструктор объекта
	var comets = function(options){
		this.init(options);
	}
	
	// собственно сам объект
	comets.prototype = {
		comets : [], // итератор соединений
		options : { // массив функций по умолчанию
			connect:function(sid){
				// функция, выполняющаяся при разрыве соединения с сервером
			},
			update:function(data){
				// функция, вызываемая сервером с новыми данными
			},
			url:"", // адрес бэкэнда
		},
		init : function(options){
			var self = this, 
				comet = {},
				sid = self.comets.push([]); // i++

			// создаем реальный массив параметров
			$.extend(comet,self.options,options)
			
			// создаем iframe и соединение
			$("")
				.appendTo("body")
				.attr({src:comet.url+sid})
				.bind("load", function(){comet.connect.apply(this,[sid]);})
				
			// аттачим события, к ифрейму аттачить нельзя, так как он еще не загрузился
			$(document).bind("comet"+sid, function(event,data){comet.update.apply(this,[data])})
		}
	}

	$.fn.comets = function(options){
		// создаем новый comet
		new comets(options);
		
		// не нарушаем цепочку
		return this;
	}
})(jQuery);


Теперь надо передать в этот плагин (да я как всегда все делаю плагином под jQuery) наши функции.


$().comets({
	// функция которая обновит такст часов
	update:function(data){
		$("#clock").text(data);
	},
	// функция которая востановит соединение с сервером
	connect:function(sid){
		$(this).attr({src:"clock.php?sid="+sid});
	},
	// адресс бэкэнда
	url:"clock.php?sid="
});


Как я говорил в начале я расскажу как бороться с временем выполнения скрипта если вам недоступна функция ini_set(); Для этого надо узнать сколько времени может выполняться скрипт и прерывать его работу незадолго до этого времени. Если передать браузеру команду восстановить соединение, то этого можно не указывать в параметрах  в javascript. Вносим правки в алгоритм работы скрипта:



// узнаем время рабы и отнимаем 5 секунд запаса
$metime = ini_get('max_execution_time') - 5;

// узнаем время начала и конца работы скрипта
$start = $stop = array_sum(explode(" ",microtime()));

ob_start();
ob_implicit_flush(true);
header('Expires: Sut, 01 Jan 2000 00:00:00 GMT');
header('Last-Modified: '.gmdate('D, d M Y H:i:s').' GMT');
header('Cache-Control: no-store, no-cache, must-revalidate');
header('Cache-Control: post-check=0, pre-check=0', false);
header('Pragma: no-cache');

echo str_repeat(chr(32), 1024);
ob_get_clean();   

// по условию, что время начала больше чем время конца минус время исполнения прерываем процедуру
while($start > $stop-$metime){
	echo ""
		."\n";
	ob_get_clean();
	$stop = array_sum(explode(" ",microtime()));
	sleep(1);
}

// echo "n";


Вот пример работы этого кода, только для наглядности я поставил обрыв соединения каждые 10 секунд.

Hello from comet!

Вот такие вот у меня получились простые комёты ;) , возможно, я их немного доделаю и опубликую, свежую версию, но это не сейчас.



Локальная  глобальная область видимости
CTAPbIu_MABP — Fri, 25 Apr 2008 15:00:04 +0000
Всю неделю готовлю сразу две статьи, первая о comet (постоянное соединение с сервером) и вторая о ранжированном поиске который наконец таки заработал на сайте но на этот раз будет махонькая заметка о корректной работе браузеров.

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

alert(this === window);

var func = function(){
	alert("hello from onload!");
};

Как и следовало ожидать мы находимся в глобальной области видимости и this у нас равен (и того же типа что и) window, то есть объявляя какую-либо переменную мы можем не указывать ключевое слово var.

onload = function (){
	func();
}

В результате работы этого скрипта мы получим наш алерт, потому что событие window.onload срабатывает когда страница полностью загружена.
Вам еще не надоело перечитывать материалы учебника для ламеров? Ну ладно начинается вкусненькое!
Создадим переменную в локальной области видимости, поскольку локальная у нас глобальна (во загнул!), то мы собственно еще раз попытаемся присвоить значение событию window.onload.

var onload = function (){
	func();
}

Вот тут и начинаются косяки, работает это только в FireFox, а Opera и IE начисто игнорируют нашу писанину! Листаем учебник дальше и видим что определение функции с именем эквивалентно определению переменной с тем же именем в локальной области видимости.

function onload (){
	func();
}

И что бы вы думали?! Действительно абсолютно эквивалентно, потому что оно также не работает, как и прошлый пример. Вы можете сказать, что я где-то что-то мухлюю и во втором и третьем примере переменные не попадают в объект window, но для всех трех примеров и всех трех браузеров алерт выдает один и тот же результат.

alert(window.onload);


Из всего вышесказанного можно сделать два вывода, даже три: Первый и самый главный - FireFox снова на высоте! Второй заключается в том, что для Opera и IE локальная область видимости скрипта не такая уже и глобальная, как хотелось бы. Ну и третий маловероятный, что все учебники врут.