PHP: библиотека xAJAX - [9] :: Web-программирование

Привет. Народ. Возник вопрос - возможно немного не в тему.
Как сделать обратную совместимость с уже встречающимися javascript ами в коде, возвращаемом ajax из backenda в frontend, есть ли что-то универсальное?

(Допустим имею сайт построенный на цмс, кучу внутренних скриптов (часть дописана, доделана или взята слева - и в них уже присутствует "внутренний" яваскрипт который по подгрузке аджакс контента нужно выполнить, и не всегда его можно "достать" и выкинуть в head секцию руками там где нужно или подключить файлы со скриптами).

Никто не сталкивался с такой либой которая позволила бы хоть частично решить данную проблему. Никто не хочет присоединиться в написании чего либо подобного? Поделиться возникшими идеями?

Вопрос не привязан конкретно к библиотеке xajax.

т. е. если подробнее вопрос начал подниматься здесь:

далее привожу комментарии @ Alex_b

http://joomlaforum.ru/index.php/topic,16631.120.html

Для запуска скриптов в полученном тексте, я поступал вот таким образом:
____________________________
.......... = function(str){



var script, scripts = '', regexp = /<script[^>]*>([sS]*?)</script>/gi;



while ((script = regexp.exec(str))) scripts += script[1] + '\n';



if (scripts) (window.execScript) ? window.execScript(scripts) : window.setTimeout(scripts, 0);
}
____________________________
Т.е. весь полученный текст прогоняется через регулярное выражение.
Выхватывается то что между <script> и </script>, а потом запускается.
(Вот этот код я подглядел у moo tools).
В принципе это не слишком хорошо (о вреде eval достаточно кругом понаписано).

Ваше решение, кажется мне, лучше.
(с помощью DHTML строить script)
Притом, отлавливать JS скрипты с помощью php и передавать в отдельной переменной это тоже лучше, чем отсеивать их на клиенте.

Только компоненты не обязательно выводят JS скрипты в BODY,
а правильные компоненты выводят скрипты в HEAD.

Вот эти скрипты тоже нужно отлавливать.

Еще есть скрипты которые подключаются к странице
<script type="text/javascript" src="sript.js"></script>
Их тоже нужно вылавливать и подгружать.

Допустим с этим разобрались.

Все JS программисты, старающиеся написать хороший код, помимо того, что выводят скрипты в HEAD очень часто используют событие window.onload.

А, как известно, это событие наступает единожды – когда станица загружена полностью.
Т.е. значит среди полученного JS кода нужно будет отыскать это событие, вытащить обработчик этого события и опять eval.
(Есть еще событие body.onload – это тоже нужно учесть)

Допустим и с этим разобрались.

Но каждый уважающий себя JS программист не станет просто вешать обработчик на window.onload, он будет использовать что вроде
____________________________
finction handler(){



//code here
}
window.addEventListener("load", handler, false);
____________________________

Допустим и с этим покончено. Мы научили наш скрипт отыскивать теперь и window.addEventListener.
(кстати в замен window можно использовать self : self.addEventListener, так что и это придется учесть)

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

И у него в коде появляется вот такое:
____________________________
var attachevent = function(element, event, handler){



try {element.addEventListener(event, handler, false);}



catch (e){element.attachEvent("on"+event, handler);}
};

attachevent(self, "load", function(){



//code here
});
____________________________
А ну догадайтесь, где тут window.onload? А потом напишите реглярку, которая сможет отыскать это событие.

Даже если вам это удалось – вы зря потратили время. Другой программист будет использовать другую функцию.

И так с каждым событием – нажатие на кнопке, потеря фокуса и т.п. я уж не говорю про эксклюзивные события которые нам предлагают библиотеки, например domready.

Если и это для вас не проблема, то вспомните на чем все держится.
На innerHTML !!!
innerHTML не в ходит ни в один стандарт, т.е. если вы пишите супер грамотное приложение и придерживаетесь стандартов, скажем w3c, вы не станете использовать innerHTML.
Браузеры очень по разному относятся к innerHTML, вот почему у вас и не хочет «отображаться в DOM инспекторе» все что вы таким путем вставили.

И что в итоге у вас получилось – работающая таким образом система (если она будет работать) будет профессиональной?

Если нам нужно хорошее приложение Ajax – его нужно и строить как хорошее приложение. Без eval, без всего этого сумасшествия.

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

Модерирует : Cheery
Версия для печати • Подписаться • Добавить в закладки
Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15