Загрузка файла без AJAX.
 

Передо мной стоит задача загрузить JS файл на клиета без AJAX. Главное условие - в сценариях я должен иметь доступ к исходному тексту скрипта. Так как код не попадает в DOM при использовании тега script, я пробовал разные варианты:

1. Iframe
В нормальных браузерах код отображается во фрейме и я могу получить исходный код. Но ишак вместо этого предлагает скачать файл, т.к. расширение его - js, а он ждет html. Не хотелось бы накладывать лишние ограничения по именам и заголовкам запроса.

2. Object & Embed
Через тег object можно указывать тип подключаемого объекта. Пробовал разные типы: plain/text, text/html, text/javascript - код не выводится и через DOM не доступен. С такими типами - text/xml, application/xml и application/text-xml уже есть какое-то движение: появляется ошибка парсера xml и через контекстное меню, "Исходный код HTML" я всё-таки вижу код файла, но через DOM получить не смог. Хотя можно получить первую строку из ошибки парсера и если файл будет сжат в 1 строку - можно получить весь код. Но это опять же лишние ограничения. С тегом embed вообще ничего интересного не смог добиться.

3. ActiveX DOM XML
Пробовал и таким способом, конкретно через метод load. Но опять же парсер XML падает с той же ошибкой.

Не устраивает аякс по нескольким причинам: нужен лишний кроссбраузерный код, хоть и не большой, а так же его ограничение на количество открытых соединений. Лучше когда браузер сам качает.

Какие ещё варианты могут быть? Я уже незнаю...

Да там две строчки.

Это не его ограничение, а браузера, независимо от типа соединения.

Ну да, ты меня понял. При том ограничения у всех свои.

2 строчки добавляют 10 багов блин:-E
Если дать браузеру качать файлы, он в любом случае сделает это лучше и все ограничения разрулит сам. Ну если не удаться по-другому, то конечно придётся аяксом.

Поясню для чего мне нужен исходный код. Дело в том, что для нормального API, его необходимо запускать в контексте определённого объекта и в специальном scope.

Также как и любые другие две строчки. Почему с iframe'ом не будет багов?

XHR-запросы он тоже сам разруливает.

На код, как я понимаю, накладываются какие-то ограничения? Почему бы не наложить тогда, что код должен лежать внутри функции с определённым именем, а уж её и вызывать в нужном контексте.

Если нужен точный исходник файла, то только два варианта: 1. XHR, 2. Посредник на сервере, который будет оборачивать ответ в jsonp, например.

Вот в том то и дело, что хочу избавиться от этого. Контекст выполнения нужен для этого скрипта и по-сути его больше ничего не должно интересовать. Scope нужен для того, чтобы в него не попали переменные из scope либы. Так что в глобальную область видимости ничего не попадает. В принципе это уже всё реализовано и такое API меня больше чем устраивает.
Т.е. если, например, создать 5 тегов script и 5 аякс-запросов поведение будет одинаковым?
Да какие там могут быть баги. Он ещё плох тем, что не смогу получить текст, если грузиться он будет с другого домена.
Ну второй точно отпадает. Тогда уж можно было бы завернуть это в xml.

Причем если открывать файл локально, то он показывается, если через http - качается:blink:
Тупой ишак.

на зеркало неча пенять...
попробуй отдавать скрипт без content-type,или отличным от умолчательного для JS

Норм у меня руки. Всё из-за того, что в ишаке расширение js не известно. Стоит только переименовать на txt или html и всё ок. Но скрипт должен быть js.
Ну всё сходится к выбору между сменой заголовка или XHR. В первом варианте не хотелось бы ещё и на сервер добавлять обязательства, а во втором... Второй вариант это уже совсем отдельная тема и к либе никакого отношения не имеет. Т.е. придётся это всё оформлять в виде плагина к либе. В принципе тоже вариант. Что бы выбрали вы?

не вижу причин, чтобы не использовать XHR

А я вижу.
В общем есть некий контроллер низкого уровня. Под ним работают классы, которые реализуют какую-то функциональность (каждый свою). Контроллер же должен быть независимым и отказоустойчивым. Доступен он только для тех классов, которые под ним работают, т.к. между ними есть своё API. Так же могут быть какие-то общие компоненты, которые могут использоваться этими классами, например работа с AJAX или событиями. Пока точно не решено выносить такие компоненты в отдельный тип или же приравнять к классам. В первом варианте создаётся зависимость контроллера от компонента, что не приемлемо. Если тот же код внести в сам контроллер, то получается дублирование (поддержка AJAX в любом случае должны быть извне). В общем лишний он тут совсем. Не знаю, поймёте, нет...

С другой стороны ссылка на js-файл может представлять из себя что угодно, поэтому заголовки всё равно должны быть настроены.

Пока поняли, что всё слишком сложно. Проще надо быть, проще.

Согласен.

Ну раз предложений больше никаких нет, то вот ещё одна задачка.
Мониторинг DOM. Существуют 2 подхода:
1. setTimeout. Тут 2 проблемы: пока я не знаю как можно замерять производительность таймеров (т.е. насколько сильно они будут грузить проц) и придётся перебирать весь DOM в поисках изменений.

2. Обработка событий изменения элементов. Для ишака придётся поменять стандартные appendChild и т.п., чтобы мониторинг срабатывал, что мне оооочень не нравится. Но за то есть плюсы: не грузит проц в холостую и массив изменений приходит без лишнего мусора.

Сейчас я склоняюсь к второму варианту. Что думаете?

Чо вообще никаких мыслей нет?

А если onpropertychange, DOMTreeModified и иже с ними?

Не всплывает. Не на каждый же элемент вешать.

В том то и дело что нужно на каждый...
Это и есть второй вариант.

Да, не всплывает. А что еще делать? 30 раз в секунду проверять всё дерево на предмет обнаружения изменений? Лучше уж сразу

alert("Ваша программа для просмотра интернетов не является браузером");
return;

…заодно учитывая, что прототипное наследование методов нод не работает в IE6. Да и про .innerHTML надо не забыть, а это вообще сеттер, которых в вышеупомянутом старичке нет в помине.

Я недавно пытался подлатать DOM (с маджонгом и гейшами, конечно же) для IE6, но пришлось бросить. Это клиника, господа, полная клиника.

subzey,
вот поэтому и не надо выпендриваться, пытаясь сделать невозможное.

Насчет innerHTML. Он смотрится на каждой ноде через onpropertychange.
Т.е. получается что нужно на все ноды навешивать обработчик и менять кучу методов. По-моему говнокод...

Либо нужно придумать хитрый алгоритм, чтобы не перебирать весь DOM в таймерах. Что-то я не уверен в успехе...

Кстати, товарищи, у IE же есть замечательная технология HTC. И мне даже удалось выяснять при его помощи, какой элемент вызвал событие. Дальше MSDN просветления не вызвал.

html:

<style type="text/css">* {behavior:url("behavior.htc");}</style>

behavior.htc:

<public:component>
	<public:event id="onpropertychange" />
	<script type="text/javascript">
		alert(element.tagName);
	</script>
</public:component>

Спасибо, попробую что-нибудь с этим сделать.

Да интересная вещь, но она требует отдельного файла, а как подключить сгенерированный текст, как будто это *.htc, я не нашел:(

ты делаешь менеджер виджетов, который их автоматически подгружает/создает/удаляет, мониторя DOM?

я бы скорее всего подгружал контроллер с нужными ему компонентами отдельного типа (с помощью тэга script), а остальные компоненты отдельного типа подгружал по мере надобности

это как? O.o

p.s. я бы эту фразу вынес в эпиграф... или даже дальше...

Ну в пределах синтаксиса естественно. Я имел ввиду расширение может быть любым, ну и другие варианты.
Ну во первых, виджетом я бы не назвал, скорее контроллер. Самостоятельное приложение.
А во вторых это не менеджер, который ими ("Виджетами") управляет, а API/Среда/Платформа для этих приложений. В общем основная идея - MVC. Одного DOM мало.

Не подходит такой вариант. Такие скрипты уже "вне" платформы будут.

Кароче, было решено грузить xml через iframe. Вместе с ним можно грузить шаблоны HTML и, как показывает практика, это очень удобно.

Удалось ли разобраться с ишаком, предлагающим сохранить файл? У меня похожая ситуация, но сервер возвращает файл с расширением PHP (!) содержащий нужные данные в формате JSON. Есть возможность вывести данные передаваемые в файле, без предложения сохранить?

Если ты имеешь ввиду загрузку через iframe, то проблема решается выставлением заголовка Content-Type: text/html. Соответственно не забываем о политике безопасности. Для меня такой вариант не подходит и я остановился на AJAX.

Content-Type: text/html - в запросе клиента на сервер? С безопасностью все норм вроде...

Нет, в ответе сервера клиенту.

Да, разобрался, проблема была в нестандартном Content-type... Запрос кроссдоменный, сервак не мой соответственно,теперь ищу способы замены элементов header-а в ответе сервена "на-лету". Делаю почти дубовую аутентификацию пользователей на своем сайте =).
Спасибо!

Прокси на стороне сервера.

еслиб я мог ответ перенаправить не в браузер клиента, а на свой сервак =))

Ещё раз повторяю:

Значит неправильно тебя понял. Можно по подробнее про реализацию с прокси?

Я программист JavaScript. Хоть я и знаю PHP, прокси ещё не приходилось писать. На сколько я помню, там используются сокеты.
На форуме есть много людей, которые понимают в этом намного больше. Можешь создать отдельную тему в соответствующем разделе.
Ну и google ни кто не отменял :)