Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 64
хабракат(тег — <habracut>) не помешает
Да стоит он!
Google Chrome 1.0 — у вас оочень крутые связи в google или в ноосфере. у всех он максиму 0.3 версии
ээээ извините мое дилетантство.
А зачем в подгружаемом HTML коде javascript?
Как по мне javascript в HTML вообще вставлять не правильно, его нужно выносить в отдельные файлы.
А зачем в подгружаемом HTML коде javascript?
Как по мне javascript в HTML вообще вставлять не правильно, его нужно выносить в отдельные файлы.
Ну что Вам сказать на это? ;)
Случаи, они разные бывают…
А если, JavaScript-код формируется, например, php-кодом в зависимости от ситуации?
Да множество примеров можно привести, когда это бывает нужно.
Случаи, они разные бывают…
А если, JavaScript-код формируется, например, php-кодом в зависимости от ситуации?
Да множество примеров можно привести, когда это бывает нужно.
Когда JS код формируеться из backend-а ( в данном случае php ) это какая то ошибка в проектировании.
Такого быть не должно.
Такого быть не должно.
почему? иногда это очень удобно
Мухи отдельно, котлеты отдельно.
ну вот смотрите.
При нажатии на некоторую ссылку с помощью AJAX загружается окно, которое всплывает поверх страницы и это окно использует свой яваскрипт, который нигде больше не требуется. Каким образом мне этот яваскрипт код загрузить, кроме как не в коде от backend-а?
Я обычно делаю в возвращаемом коде конструкцию:
<sсript type=«text.javascript»>
var param1 = ..;
var param2 = ..;
</sсript>
<sсript src=«code.js» type=«text.javascript»></sсript>
параметры подставляет PHP.
Что я делаю не правильно?
При нажатии на некоторую ссылку с помощью AJAX загружается окно, которое всплывает поверх страницы и это окно использует свой яваскрипт, который нигде больше не требуется. Каким образом мне этот яваскрипт код загрузить, кроме как не в коде от backend-а?
Я обычно делаю в возвращаемом коде конструкцию:
<sсript type=«text.javascript»>
var param1 = ..;
var param2 = ..;
</sсript>
<sсript src=«code.js» type=«text.javascript»></sсript>
параметры подставляет PHP.
Что я делаю не правильно?
А если есть flash вставляемый через SWFObject, которому передается некая ссылка из CMS в flashvars? Как в таком случае разделить?
Согласен.
Это усложняет проект.
Это усложняет проект.
var script = document.createElement(«script»);
script.language = «JavaScript»;
script.type = «text/javascript»;
script.text = ваш код…
document.documentElement.firstChild.appendChild(script);
и усё работает, а баги у вас из-за коментов на русском
script.language = «JavaScript»;
script.type = «text/javascript»;
script.text = ваш код…
document.documentElement.firstChild.appendChild(script);
и усё работает, а баги у вас из-за коментов на русском
Можно и такой способ использовать, в любом случае JavaScript надо сначала подгрузить, а прогонять его через eval или вставлять в нод, уже на Ваше усмотрение. Баги не из-за комментов, а из-за того, что IE, например, при указании defer скрипты выполняет автоматом. Если defer не указать, то не выполняет. Другие браузеры ведут себя тоже по разному в зависимости от версии. Предложенный подход является кросс-браузерным и нормально работает везде.
function $exec(text){
if (!text) return text;
if (window.execScript){
window.execScript(text);
} else {
var script = document.createElement('script');
script.setAttribute('type', 'text/javascript');
script[(Browser.Engine.webkit419) ? 'innerText' : 'text'] = text;
document.head.appendChild(script);
document.head.removeChild(script);
}
return text;
};
* This source code was highlighted with Source Code Highlighter.код из mootools, для safari2 нужен innerText
Как вообще зарегистрироваться можно сейчас на хабре?
Наши программисты хотят поучаствовать в обсуждении.
Наши программисты хотят поучаствовать в обсуждении.
Тоже такой приём использовал для подгружаемого содержимого диалога который рисуется в диве, а не стандартным window.open. Но отлаживать такой JavaScript сложно.
Больше всего я удивлён тем, что топик в плюсе… Ужас.
если у вас не было случаев, когда такое может понадобиться, это не значит, что это не нужно другим
Если хоть один человек после моего коммента, в момент, когда нужно будет выбрать реализацию подобной функциональности, сделает _правильно_, а не так, как посоветовано в этом топике — я уже буду рад.
А если у вас были случаи, когда это понадобилось — выгоните архитектора.
А если у вас были случаи, когда это понадобилось — выгоните архитектора.
значит выгонять прийдется меня самого. а также клиентов, которые не хотят учить несколько языков
опишу ситуацию
одни клиенты веб-приложения хотят нарисовать форму (используя rich html editor) и там же описать правила валидации этой формы
другие клиенты видят эти формы и заполняют их
жду ваших предложений по реализации этой функциональности
опишу ситуацию
одни клиенты веб-приложения хотят нарисовать форму (используя rich html editor) и там же описать правила валидации этой формы
другие клиенты видят эти формы и заполняют их
жду ваших предложений по реализации этой функциональности
Добавьте, пожалуйста, в топик примеры, в которых может быть использовано это решение.
Например, в CMS-ке мы реализовали проверку орфографии в визуальном редакторе. Орфография проверяется с использованием нашего сервиса, который в свою очередь использует ASpell. Т. е. в скрипт приходит текст для проверки, а скрипт формирует JavaScript-массив, который содержит неправильно написанное слово и варианты исправления. Далее JavaScript-ом в тексте подсвечиваются неправильно написанные слова и предлагается замена. Все это строится из возвращенного массива. Код тут приводить не буду, возможно в следующем хабратопике опишу как раз как это реализуется подробно (есть кому интересно?). Но живой пример, и как тут обойтись без описанного способа мы не придумали. Кто пишет, что так не делается или это ошибка в архитектуре, наверное не решали сложных задач взаимодействия пользователя с сервером. Так же можно, например, реализовать какой-нибудь кредитный калькулятор, который считает ставку кредита онлайн, при этом подгружая данные в зависимости от выбора пользователя (автокредит, ипотека и пр.) без перегрузки страницы.
Отвечать JSON'ом или XML. На клиенте разбираться что и как подсвечивать.
не?
не?
Можно использовать JSON, можно и XML. Конечно можно. Но! При использовании JSON нужен все тот же eval и все зависит от задачи. Давайте возьмем описанную выше задачу проверки орфографии. На сервер был отправлен запрос на проверку, сервер должен в ответ вернуть массив слов и их вариантов замены. Как будет выглядеть такая структура на JSON или XML?
В виде массива все выглядит просто и удобочитаемо:
var words = [];
words[“слва”] = [“слова”, “слава”, “слива”];
…
Как такой массив представить на JSON или XML? И стоит ли это делать?
Насчет XML отдельная песня. Зачем формировать XML на сервер, затем на клиенте его парсить? На формирование XML, JSON или описанного выше массива на сервере ресурсов нужно одинаковое количество. Зачем же потом еще тратить ресурсы клиента на дополнительный парсинг? Массив прогнал через eval и все готово. XML парситься будет гораздо дольше. Смысл какой в этом?
Да и вообще мое мнение такое – нет универсальных средств. В одном случае лучше использовать JSON, в другом XML. В нашем примере на мой взгляд JavaScript-массив лучшее решение. Зачем загонять себя в какие-то шаблоны? Если использовать, то только JSON или только XML и еще всем вокруг доказывать что JSON круче. Так же как не стоит везде использовать AJAX.
В виде массива все выглядит просто и удобочитаемо:
var words = [];
words[“слва”] = [“слова”, “слава”, “слива”];
…
Как такой массив представить на JSON или XML? И стоит ли это делать?
Насчет XML отдельная песня. Зачем формировать XML на сервер, затем на клиенте его парсить? На формирование XML, JSON или описанного выше массива на сервере ресурсов нужно одинаковое количество. Зачем же потом еще тратить ресурсы клиента на дополнительный парсинг? Массив прогнал через eval и все готово. XML парситься будет гораздо дольше. Смысл какой в этом?
Да и вообще мое мнение такое – нет универсальных средств. В одном случае лучше использовать JSON, в другом XML. В нашем примере на мой взгляд JavaScript-массив лучшее решение. Зачем загонять себя в какие-то шаблоны? Если использовать, то только JSON или только XML и еще всем вокруг доказывать что JSON круче. Так же как не стоит везде использовать AJAX.
{«слва»: [“слова”, “слава”, “слива”], ...., «blablabla»: [«blabla», «adf»]}, потом этот ответ присваивается words. Приведенный пример не показывает случая содержания JS кода вместе c HTML в одном ответе на запрос, о чем я вас и просил.
JSON самый универсальный, легкий по отношению к xml способ описать данные. Ваш способ имеет большой минус: он требует специализированных encoderов, в то время как JSON — стандарт, с соответствующей широкой поддержкой.
Пока у меня какое-то странное ощущение, что вы сами не знаете, зачем вам это надо. Прошу не обижаться, просто ни одного внятного примера, где данный способ уместен, я не увидел.
JSON самый универсальный, легкий по отношению к xml способ описать данные. Ваш способ имеет большой минус: он требует специализированных encoderов, в то время как JSON — стандарт, с соответствующей широкой поддержкой.
Пока у меня какое-то странное ощущение, что вы сами не знаете, зачем вам это надо. Прошу не обижаться, просто ни одного внятного примера, где данный способ уместен, я не увидел.
Поддержу вас, особенно про широкую поддержку, сразу приходит в голову пример, когда нам влруг понадобилось обращаться из Флеша… или каким-либо удаленным сервисом.
Соглашусь с тем, что привел слишком простой пример, который не дает представления зачем отправлять JavaScript и HTML одновременно. Давайте рассмотрим пример сложнее. Используется диалоговое окно с закладками. На каждой закладке выводится какой-то HTML-код, в котором, к примеру, на одной закладке может использоваться перетаскивание, на другой динамическое формирование списков, на третьей реализованы на JavaScript спины и пр. Если все это дело грузить сразу, то это не очень хорошо. Пользователю может понадобится только одна закладка, на остальных данные меняться не будут. Соотв. тянуть сразу кучу скриптов смысла нет. Для этого AJAX и существует, чтобы реализовывать сложные веб-интерфейсы. Соотв. при щелчке на закладку подгружается ее содержимое и скрипты, реализующие необходимый функционал.
Достаточно внятный пример?
Достаточно внятный пример?
Да пожалуйста:
сервер отдает голый хтмл, далее клиент обрабатывает то, что получил и решает что ему нужно подгрузить (подгрузка скриптов на лету задача тривиальная), теоритически может быть случай когда клиент заранее знает, что ему полсе получения понадобится, тогда он может вытянуть параллельно (но это, имхо, редкий случай).
Общий смысл то в чем: сервер занимается своим делом клиент своим, т. е. сервер отдает данные, клиент думает как их надо отобразить.
сервер отдает голый хтмл, далее клиент обрабатывает то, что получил и решает что ему нужно подгрузить (подгрузка скриптов на лету задача тривиальная), теоритически может быть случай когда клиент заранее знает, что ему полсе получения понадобится, тогда он может вытянуть параллельно (но это, имхо, редкий случай).
Общий смысл то в чем: сервер занимается своим делом клиент своим, т. е. сервер отдает данные, клиент думает как их надо отобразить.
По каким параметрам клиент должен понять, что ему нужно подгрузить?
Вы же сами говорите об универсальности. Вы считаете такой подход универсальным?
Вы же сами говорите об универсальности. Вы считаете такой подход универсальным?
Если ХТМЛ, то по атрибутам (в том числе ид и класс), положении в ДОМ-дереве и т. д.
Клиент устанавливает, что данный элемент (например кнопка), не просто кнопка — она обладает доп свойствами и этой кнопке отвечает некоторый скриптовый класс, напрмиер. Далее если класс еще недоступе мы можем подцепить нужный файл. Все.
Да я считаю что это более универсальный способ, т. к. нет привязки сервера к JS, он о нем не знает и не слышал.
Клиент устанавливает, что данный элемент (например кнопка), не просто кнопка — она обладает доп свойствами и этой кнопке отвечает некоторый скриптовый класс, напрмиер. Далее если класс еще недоступе мы можем подцепить нужный файл. Все.
Да я считаю что это более универсальный способ, т. к. нет привязки сервера к JS, он о нем не знает и не слышал.
Да уж :). Писать кучу кода, для того, чтобы определить, какой скрипт подгрузить это конечно более универсально. «Привязаться к айди или классу» — слова «привязаться» и «универсальность», мне кажется, противоречат друг другу. «Нет привязки сервера к JS» совсем убойная фраза. Не грузите и HTML тогда. Зачем сервер к HTML-у привязывать? Пусть всю работу делает клиент. Совсем универсально получится. Только вот клиенту понравится ли, если прежде чем окошко открыть к нему будет закачиваться куча кода, которая потом в этом окне кнопку выведет?
Тут про архитектуру говорят, так вот, основой при проектировании проекта являются требования к нему, в том числе где и как будет использоваться проект. Зачем делать универсальным то, что никогда эту универсальность использовать не будет? Мы предложили подход, он не совершенен, но поможет тем, кто ищет подобное решение. Они сами выберут, грузить им JavaScript, XML или JSON. Мы никому свою точку зрения не навязываем. В каждом конкретном случае лучше использовать тот или иной подход. А «универсальных» решений к сожалению нет. И всегда разработчик стоит перед выбором, сделать кучу когда и все будет тормозить, или внести ограничения, но будет работать быстро и правильно. Где-то нужна куча кода с тормозами, где-то этого делать не стоит. И мы не являемся сторонниками «модных» технологий. Если появился JSON, это не значит что все теперь должны отказаться от XML-а.
В другом хабратопике нас упрекают в том, что есть библиотеки jQuery и пр. Конечно, легче взять готовую библиотеку, не разобравшись что она делает, и использовать ее. Несмотря, что весит такая библиотека под сотню килобайт. А вызвать надо всего одну функцию из этой библиотеки. Это называется правильное проектирование! Архитектура таких проектов просто на высоте, ведь jQuery – это «модно», ее все используют. А подумать и свое написать, это колесо придумывать! Обсмеют. Так что нехай с ними, ста килобайтами, пусть клиента проблемой они станут! Хорош подход. Хороши архитекторы. Грустно :(. И думаешь, зачем все же рыть ямку экскаватором?
Тут про архитектуру говорят, так вот, основой при проектировании проекта являются требования к нему, в том числе где и как будет использоваться проект. Зачем делать универсальным то, что никогда эту универсальность использовать не будет? Мы предложили подход, он не совершенен, но поможет тем, кто ищет подобное решение. Они сами выберут, грузить им JavaScript, XML или JSON. Мы никому свою точку зрения не навязываем. В каждом конкретном случае лучше использовать тот или иной подход. А «универсальных» решений к сожалению нет. И всегда разработчик стоит перед выбором, сделать кучу когда и все будет тормозить, или внести ограничения, но будет работать быстро и правильно. Где-то нужна куча кода с тормозами, где-то этого делать не стоит. И мы не являемся сторонниками «модных» технологий. Если появился JSON, это не значит что все теперь должны отказаться от XML-а.
В другом хабратопике нас упрекают в том, что есть библиотеки jQuery и пр. Конечно, легче взять готовую библиотеку, не разобравшись что она делает, и использовать ее. Несмотря, что весит такая библиотека под сотню килобайт. А вызвать надо всего одну функцию из этой библиотеки. Это называется правильное проектирование! Архитектура таких проектов просто на высоте, ведь jQuery – это «модно», ее все используют. А подумать и свое написать, это колесо придумывать! Обсмеют. Так что нехай с ними, ста килобайтами, пусть клиента проблемой они станут! Хорош подход. Хороши архитекторы. Грустно :(. И думаешь, зачем все же рыть ямку экскаватором?
getElementById/getElementsBySelector это куча кода?
Что значит «привязаться к айди и классу»? атрибуты и созданы для того, чтобы добавить доп. свойства элементу, конкретизировать его. Мы используем их для описния внешнего вида, так почему не использовать их и для описания функциональности в скриптах…
Про скорость и архитектуру. Вы так и не привили варианта, где использование вашего подхода крайне необходимо, кроме того, совсем не понятно, что будет проще и быстрее. Да и само использование eval вызывает много споров в сообществе.
Ну, а насчет билиотек, это уже тема иного обсуждения.
Что значит «привязаться к айди и классу»? атрибуты и созданы для того, чтобы добавить доп. свойства элементу, конкретизировать его. Мы используем их для описния внешнего вида, так почему не использовать их и для описания функциональности в скриптах…
Про скорость и архитектуру. Вы так и не привили варианта, где использование вашего подхода крайне необходимо, кроме того, совсем не понятно, что будет проще и быстрее. Да и само использование eval вызывает много споров в сообществе.
Ну, а насчет билиотек, это уже тема иного обсуждения.
>ведь jQuery – это «модно», ее все используют. А подумать и свое написать, это колесо придумывать! Обсмеют. Так что нехай с ними, ста килобайтами, пусть клиента проблемой они станут! Хорош подход. Хороши архитекторы. Грустно
Понимаете какое дело, представленный вами слабый код ничем не лучше избыточности jQuery. Дело не в архитектуре или проектировании, дело во владении предметом. Если Петя/Вася/Джон — не архитектор, то ему, что избушку, что небоскрёб из избушек, пректировать противопоказано. В этом смысле нам, клиентам, действительно грустно… ;)
Понимаете какое дело, представленный вами слабый код ничем не лучше избыточности jQuery. Дело не в архитектуре или проектировании, дело во владении предметом. Если Петя/Вася/Джон — не архитектор, то ему, что избушку, что небоскрёб из избушек, пректировать противопоказано. В этом смысле нам, клиентам, действительно грустно… ;)
Если Вы можете оценить слабость или силу кода, значит Вы не просто клиент, а программист. Приведет сами пример своей сильной реализации. Посмотрим тогда, что я смогу про нее сказать.
Почему, если Вы такой умный и у Вас столько опыта Вы не делитесь им? Критиковать может каждый! Напишите свою статью, со своей реализацией. Где они? Почему у Вас под сотню комментов и ни одной статьи?
Данный пример решает поставленную задачу, от него большего не требуется. В чем его слабость заключается?
Критики блин…
Есть реализация, которая работает. Работает на более чем 3500 сайтах! Работает хорошо и без сбоев!
Есть куча людей, которым это дело может пригодиться.
Вам не пригодилось? Да ради Бога!
Можете предложить что-то лучше? Предложите. Отдельной статьей.
Есть такой старый анекдот, когда вороны играли в игру, пытаясь, извиняюсь, накакать людям на головы и у них не получалось. А потом прилетел воробей и «выбил» 10 из 10. После чего оказалось, что в прошлой жизни он был критиком. В этом вся суть… Срать на голову легче, чем придумать и предложить что-то свое. Так было всегда, и к сожалению так всегда будет. :(
За сим откланиваюсь. Разговор все больше походит на спор, что лучше, PHP или Perl и им подобные. Слишком хорошо знаю бесперспективность эти споров. Извините, просто нет времени. Да и не скажу, что мне приятно с Вами общаться…
Особенно улыбнула фраза «Не обосновал? Запороли что ли? ;) ».
Так и слышится «Обосрался что ли???» с ноткой ликования в голосе…
После нее все стало на свои места, и реально стало жалко потраченного времени…
Почему, если Вы такой умный и у Вас столько опыта Вы не делитесь им? Критиковать может каждый! Напишите свою статью, со своей реализацией. Где они? Почему у Вас под сотню комментов и ни одной статьи?
Данный пример решает поставленную задачу, от него большего не требуется. В чем его слабость заключается?
Критики блин…
Есть реализация, которая работает. Работает на более чем 3500 сайтах! Работает хорошо и без сбоев!
Есть куча людей, которым это дело может пригодиться.
Вам не пригодилось? Да ради Бога!
Можете предложить что-то лучше? Предложите. Отдельной статьей.
Есть такой старый анекдот, когда вороны играли в игру, пытаясь, извиняюсь, накакать людям на головы и у них не получалось. А потом прилетел воробей и «выбил» 10 из 10. После чего оказалось, что в прошлой жизни он был критиком. В этом вся суть… Срать на голову легче, чем придумать и предложить что-то свое. Так было всегда, и к сожалению так всегда будет. :(
За сим откланиваюсь. Разговор все больше походит на спор, что лучше, PHP или Perl и им подобные. Слишком хорошо знаю бесперспективность эти споров. Извините, просто нет времени. Да и не скажу, что мне приятно с Вами общаться…
Особенно улыбнула фраза «Не обосновал? Запороли что ли? ;) ».
Так и слышится «Обосрался что ли???» с ноткой ликования в голосе…
После нее все стало на свои места, и реально стало жалко потраченного времени…
В расчёте на ответную реакцию вы представили на наш суд (ага, и на мой суд тоже) некую функцию, написанную на javascript. В ответ я… уж, простите меня, юродивого, нагло среагировал, так как вижу недостатки, а именно:
— indexOf и подсчёт символов вместо использования регулярных;
— 'for-in' для «обхода» массива;
— бессмысленное!!! многократное!!! использование ключевого слова 'var';
— бессмысленное сравнение;
— бессмысленное разбиение строк (открывающийся тег script);
— eval-изация без каких-либо попыток уйти от контекста функции.
От обсуждения вы фактически уклонились, жаль, могли бы меня укатать в асфальт. Остаюсь с надеждой, что желание учить(ся) или приведёт сюда вашего пока безмолвного программиста, или поможет пересмотреть свою позицию и улучшить код. Всегда готов к построчной полемике!
И ещё. Если отважно рекомендуете миру свой код для использования/копирования и считаете его сильным, то будьте готовы обсуждать это по сути, без таких отвлечённых терминов, как «обосрался» и «срать на голову». Некрасиво.
И последнее. Вы, конечно, не поверите, но среди нас есть люди, которые не пишут статьи. Вообще не пишут. Странные бесполезные люди, недостойные приставки хабра-…
— indexOf и подсчёт символов вместо использования регулярных;
— 'for-in' для «обхода» массива;
— бессмысленное!!! многократное!!! использование ключевого слова 'var';
— бессмысленное сравнение;
— бессмысленное разбиение строк (открывающийся тег script);
— eval-изация без каких-либо попыток уйти от контекста функции.
От обсуждения вы фактически уклонились, жаль, могли бы меня укатать в асфальт. Остаюсь с надеждой, что желание учить(ся) или приведёт сюда вашего пока безмолвного программиста, или поможет пересмотреть свою позицию и улучшить код. Всегда готов к построчной полемике!
И ещё. Если отважно рекомендуете миру свой код для использования/копирования и считаете его сильным, то будьте готовы обсуждать это по сути, без таких отвлечённых терминов, как «обосрался» и «срать на голову». Некрасиво.
И последнее. Вы, конечно, не поверите, но среди нас есть люди, которые не пишут статьи. Вообще не пишут. Странные бесполезные люди, недостойные приставки хабра-…
Я как раз тоже занимался eval-ом скриптов, когда только-только появился AJAX под .NET, и многие библиотеки не поддерживали его.
Первый момент — лучше добавлять и сразу удалять элемент script в заголовке документа, потому что eval не выполняется в контексте window, и все " function xyz() {} " в скрипте не будут доступны из других скриптов. как вариант писать " window['xyz'] = function() {} ", но мне кажется что это извращение (хотя данный метод используется в некоторых распространённых библиотеках).
Второй момент — выдирать скрипты можно проще :)
пару ссылок в тему:
forums.asp.net/t/1045405.aspx
forums.asp.net/t/1062799.aspx
Первый момент — лучше добавлять и сразу удалять элемент script в заголовке документа, потому что eval не выполняется в контексте window, и все " function xyz() {} " в скрипте не будут доступны из других скриптов. как вариант писать " window['xyz'] = function() {} ", но мне кажется что это извращение (хотя данный метод используется в некоторых распространённых библиотеках).
Второй момент — выдирать скрипты можно проще :)
var js_ScriptFragment = '(?:<script.*?>)((\n|\r|.)*?)(?:<\/script>)';
var js_ScriptSrcFragment = '<script.+(src[ ]*=[ ]*\'(.*?)\'|src[ ]*=[ ]*"(.*?)").+';
function js_extractScripts(str)
{
var matchAll = new RegExp(js_ScriptFragment, 'img');
var matchOne = new RegExp(js_ScriptFragment, 'im');
var matchSrc = new RegExp(js_ScriptSrcFragment, 'im');
var arr = str.match(matchAll) || [];
var res = [];
for (var i = 0; i < arr.length; i++)
{
var srcMt = arr[i].match(matchSrc);
if (srcMt)
{
if (srcMt.length > 3) res.push(['src', srcMt[3]]);
else res.push(['src', srcMt[2]]);
}
var mtCode = arr[i].match(matchOne) || ['', ''];
if (mtCode[1] != '') res.push(['code', mtCode[1]]);
}
return res;
}
пару ссылок в тему:
forums.asp.net/t/1045405.aspx
forums.asp.net/t/1062799.aspx
Простой вопрос: есть здесь те, кому реально данная статья пригодилась или может пригодиться в будущем? Пару слов плиз в студию. Да или нет. Я хочу определить полезность дальнейшей публикации подобных вещей.
Кстати! Первым буду я! ;)
Да, мне пригодилась, с учетом поста выше о регулярках!
Да, мне пригодилась, с учетом поста выше о регулярках!
Я бы на вашем месте постарался бы сам получить пользу от статьи и как минимум выпорол бы программиста за то, что он:
— понатыкал везде ключевое слово 'var' будто верит, что блокам в javascript это не по-барабану;
— использует 'indexOf' будто не знает регулярки вовсе и верит в то, что считать буковки неизвестного текста безопаснее;
— листает массив через 'for-in' будто не знает про наследуемые свойства и не гарантированный порядок;
— сравнивает с пустой строкой 'if(JSCode[i] != '')' будто не знает, как работает 'if()';
— разбивает открывающийся "<scr" + «ipt» будто не знает, зачем это вообще делается.
Что касается eval-изации, то хозяин — барин, надо только помнить, что scope chain контекста исполнения кода в eval == scope chain того контекста исполнения, где eval вызвана, отсюда аргументы/переменные/объявленные функции 'sbEvalJS' и переменные/объявленные функции в тексте 'eval' взаимно засоряют друг друга, а всё, что в 'eval' подано 'глобально' будет 'локальным' по отношению к функции 'sbEvalJS'.
— понатыкал везде ключевое слово 'var' будто верит, что блокам в javascript это не по-барабану;
— использует 'indexOf' будто не знает регулярки вовсе и верит в то, что считать буковки неизвестного текста безопаснее;
— листает массив через 'for-in' будто не знает про наследуемые свойства и не гарантированный порядок;
— сравнивает с пустой строкой 'if(JSCode[i] != '')' будто не знает, как работает 'if()';
— разбивает открывающийся "<scr" + «ipt» будто не знает, зачем это вообще делается.
Что касается eval-изации, то хозяин — барин, надо только помнить, что scope chain контекста исполнения кода в eval == scope chain того контекста исполнения, где eval вызвана, отсюда аргументы/переменные/объявленные функции 'sbEvalJS' и переменные/объявленные функции в тексте 'eval' взаимно засоряют друг друга, а всё, что в 'eval' подано 'глобально' будет 'локальным' по отношению к функции 'sbEvalJS'.
Вообще-то var ставится для того, чтобы не перекрывать глобальные переменные. Вы про видимость переменных внизу так хорошо написали, а тут как же с этим быть? Насчет indexOf согласен, будем использовать регулярки. Для этого сообщество хабра и существует, чтобы на такие недостатки указывать. Насчет <script и if поясните, как работает if и для чего делается все же разбиение? Нам интересно узнать.
>Вообще-то var ставится для того, чтобы не перекрывать глобальные переменные.
Замечательно, только для этого не нужно при-var-ивать одну и ту же переменную четырежды!!!, не надо дублировать вары в блоках, тот, кто это делает, возможно просто не понимает, как происходит конкретизация переменных в javascript.
>как работает if
Выражение в скобках вычисляется и конвертируется в значение типа Boolean, соответственно, если там пустая строка, то её не нужно сравнивать с пустой строкой, 'if' не пойдёт дальше и так.
>для чего делается все же разбиение
Спросите сделавшего. Для чего он разбил открывающийся тег, пущай обоснует? Предположу, что просто так, до кучи. ;)
Замечательно, только для этого не нужно при-var-ивать одну и ту же переменную четырежды!!!, не надо дублировать вары в блоках, тот, кто это делает, возможно просто не понимает, как происходит конкретизация переменных в javascript.
>как работает if
Выражение в скобках вычисляется и конвертируется в значение типа Boolean, соответственно, если там пустая строка, то её не нужно сравнивать с пустой строкой, 'if' не пойдёт дальше и так.
>для чего делается все же разбиение
Спросите сделавшего. Для чего он разбил открывающийся тег, пущай обоснует? Предположу, что просто так, до кучи. ;)
Не обосновал? Запороли что ли? ;)
Ну, хорошо, спрошу прямиком, без смайлика, раз коробит. Программист согласился с высказанными мною замечаниями и объяснениями или нет? В отсутствии диалога мне трудно об этом судить, но есть нормальное желание быть услышанным…
моя люимая тема поднялась :)
1) подход который вы описали имеет общеприятое название — en.wikipedia.org/wiki/AHAH
2) используя данный подход сможете подгрузить скрипты GoogleMap? как на подобии AHAH GoogleMap
3) что случится если в подгружаемых скриптах используется document.write? window.onload?
1) подход который вы описали имеет общеприятое название — en.wikipedia.org/wiki/AHAH
2) используя данный подход сможете подгрузить скрипты GoogleMap? как на подобии AHAH GoogleMap
3) что случится если в подгружаемых скриптах используется document.write? window.onload?
Насчет названия не знали. Скрипты со сторонних серверов грузиться не будут. Данный пример такую задачу не решает. По поводу различных библиотек и целесообразности их использования писал выше. Насчет document.write. Вызывайте перед ним document.open, после document.close. Насчет window.onload – а что там делаться должно? Вызывайте эту функцию сразу, зачем еще событие. Все уже загружено.
> Скрипты со сторонних серверов грузиться не будут.
ну суть вопроса не в том чтобы грузить скрипты со сторонних серверов, а в том чтобы выполнять скрипты практически любого уровня сложности
> Насчет document.write. Вызывайте перед ним document.open, после document.close.
вы пробывали? и как? получилось? хотелось бы взглянуть на примерчик
>Насчет window.onload – а что там делаться должно? Вызывайте эту функцию сразу…
так если вы загрузите сторонний ранее написанный скрипт, который использует onload, предлагаете переписывать скрипт?
ну суть вопроса не в том чтобы грузить скрипты со сторонних серверов, а в том чтобы выполнять скрипты практически любого уровня сложности
> Насчет document.write. Вызывайте перед ним document.open, после document.close.
вы пробывали? и как? получилось? хотелось бы взглянуть на примерчик
>Насчет window.onload – а что там делаться должно? Вызывайте эту функцию сразу…
так если вы загрузите сторонний ранее написанный скрипт, который использует onload, предлагаете переписывать скрипт?
Мы нигде в данном топике не писали, что библиотека sbAJAX является универсальной, и решает все возможные задачи. Библиотека может загружать и выполнять JavaScript-ы практически любого уровня сложности. Она разрабатывалась для внутренних нужд и используется в нашей CMS. Выложили ее сюда, судя по топикам, она оказалась полезной и другим пользователям. Вы продвигаете свою библиотеку, соотв. пишите свои топики, как подобные задачи решаются у Вас. sbAJAX не претендует на замену jQuery или fullAJAX. Это простая библиотека для решения простых задач (90% из всех задач, решаемых с помощью AJAX). Насчет document.open, попробовал, работает, в чем проблема-то должна быть? И зачем вызывать document.write в скриптах, которые подгружаются через AJAX? Для этого HTML вместе с JavaScript и грузится.
видать некоторые отдельные комментарии сказываются на общее настроение… както нервно реагируете… в данном случае я ничего не придвигаю, а просто указал вам на возможные проблематичные места. я давно занимаюсь AHAH и мне было интересно поразвивать тему в более сложных направлениях. хотел так сказать поделится опытом, а вы както болезненно реагируете. я даже тогда не буду затрагивать более специфические моменты.
P.S.: на счет document.write и document.open — вы заблуждаетесь на счет работоспособности
пример: index.html >>
test.html >>
P.S.: на счет document.write и document.open — вы заблуждаетесь на счет работоспособности
пример: index.html >>
<html>
<head>
<title>test</title>
<head>
<script type='text/javascript' src='sbAJAX.js'></script>
</head>
</head>
<body onload="test()">
<div id="test">Test</div>
<script>
function test(){
sbLoadAsync('test.html', function(text){
try{
document.getElementById('test').innerHTML = text;
} catch(ex){
alert('Error: id=test not found')
}
})
}
</script>
</body>
</html>
* This source code was highlighted with Source Code Highlighter.test.html >>
<div>AHAH loaded</div>
<script>
document.open();
document.write('<div style="background:#aff">document.write - OK</div>');
document.close();
</script>
* This source code was highlighted with Source Code Highlighter.Внимание! Код в статье изменен на новый, в результате замечаний, выявленных в процессе его обсуждения.
Как-то уж слишком быстро вы заменили старый код, который работает хорошо и без сбоев на более чем 3500 сайтах. Местное обсуждение удалённого предмета по его сути выглядит теперь немного странным (неизвестно про что, источник-то исчез), можно было бы дать ссылку без замены. Теперь про новый сверху вниз:
>if (!text) return;
Есть ли необходимость с заведомо «пустым/falsy» аргументом вызывать функцию (входить в её контекст с созданием scope chain, вычислением 'this' и проч.) и тут же выходить? Отсекайте «пустоту» до вызова, в вашем случае (вызов из одной точки) это оптимальнее и логичнее.
>script.setAttribute
Этот метод в IE реализован своеобразно/упрощённо/buggy, будет надежнее и единооборазнее для большинства UAs использовать одноименное свойство 'script.type'.
>script.setAttribute('language', 'JavaScript');
Атрибут 'language' deprecated и давно.
>if (_isIE)
Что это? Алгоритм определения IE вами оставлен за кадром, но в чём вообще смысл такой проверки «на IE» уже после того, как IE выполнит родной ему 'execScript'? Выглядит или как копипаст, или как странный микс двух подходов — «эвализация» плюс «создание элемента».
>var arr = s.match(matchAll) || [];
Зачем создавать бессмысленный пустой массив? Получился квази-отказ от перебора массива вместо нормальной очевидной проверки. Такие вещи обычно вынужденно практикуются в либах, где выражения «нанизывают» друг на друга, как в том же Prototype: 'return (this.match(matchAll) || []).map(function(scriptTag)', откуда судя по коду это и рипнуто.
>if (srcMt.length > 3)
Когда 'match()' не ищет глобально, то в результирующем массиве будет найденная подстрока, а за ней подстроки, соответствующие подвыражениям, заключенным в круглые скобки. Таких подвыражений у вас 3, вместе с подстрокой длина массива — 4. Отсюда глупый вопрос — зачем вам проверка размера массива?
>else srcMt = srcMt[2];
Моментальное следствие предыдущей ошибки, если значение атрибута 'src' по каким-то причинам в одинарных кавычках, то это не определится вообще со всеми вытекающими.
>if (srcMt != '')
Выражение в скобках вычисляется и конвертируется в значение типа Boolean, соответственно, если там пустая строка, то её не нужно специально! сравнивать с пустой строкой, 'if' не пойдёт дальше и так.
>var mtCode = arr[i].match(matchOne);
Зачем и отловленный ранее блок с внешним скриптом проверяется на наличие кода между тегами? Или одно, или другое, есть 'src' — нет кода внутри, нет 'src' — проверяем, а иначе какой-нибудь пьяный '
>if (!text) return;
Есть ли необходимость с заведомо «пустым/falsy» аргументом вызывать функцию (входить в её контекст с созданием scope chain, вычислением 'this' и проч.) и тут же выходить? Отсекайте «пустоту» до вызова, в вашем случае (вызов из одной точки) это оптимальнее и логичнее.
>script.setAttribute
Этот метод в IE реализован своеобразно/упрощённо/buggy, будет надежнее и единооборазнее для большинства UAs использовать одноименное свойство 'script.type'.
>script.setAttribute('language', 'JavaScript');
Атрибут 'language' deprecated и давно.
>if (_isIE)
Что это? Алгоритм определения IE вами оставлен за кадром, но в чём вообще смысл такой проверки «на IE» уже после того, как IE выполнит родной ему 'execScript'? Выглядит или как копипаст, или как странный микс двух подходов — «эвализация» плюс «создание элемента».
>var arr = s.match(matchAll) || [];
Зачем создавать бессмысленный пустой массив? Получился квази-отказ от перебора массива вместо нормальной очевидной проверки. Такие вещи обычно вынужденно практикуются в либах, где выражения «нанизывают» друг на друга, как в том же Prototype: 'return (this.match(matchAll) || []).map(function(scriptTag)', откуда судя по коду это и рипнуто.
>if (srcMt.length > 3)
Когда 'match()' не ищет глобально, то в результирующем массиве будет найденная подстрока, а за ней подстроки, соответствующие подвыражениям, заключенным в круглые скобки. Таких подвыражений у вас 3, вместе с подстрокой длина массива — 4. Отсюда глупый вопрос — зачем вам проверка размера массива?
>else srcMt = srcMt[2];
Моментальное следствие предыдущей ошибки, если значение атрибута 'src' по каким-то причинам в одинарных кавычках, то это не определится вообще со всеми вытекающими.
>if (srcMt != '')
Выражение в скобках вычисляется и конвертируется в значение типа Boolean, соответственно, если там пустая строка, то её не нужно специально! сравнивать с пустой строкой, 'if' не пойдёт дальше и так.
>var mtCode = arr[i].match(matchOne);
Зачем и отловленный ранее блок с внешним скриптом проверяется на наличие кода между тегами? Или одно, или другое, есть 'src' — нет кода внутри, нет 'src' — проверяем, а иначе какой-нибудь пьяный '
Спасибо за столь обширный обзор кода, предела совершенству нет, будем совершенствоваться дальше.
Код изменил потому, что не каждый человек, который захочет воспользоваться статьей, будет читать ее обсуждение! Статью мы выложили для людей! А не для ведения спора о ее оптимальности.
Я сто раз уже говорил, не нужно не пользуйтесь. А кому нужно, пусть уж они получит сразу более оптимальный код, раз уж удалось его улучшить с помощью этой статьи.
А то, что часть обсуждения стало вдруг не нужным, так разве _итог_ не был целью этого обсуждения? Или все-же важен сам процесс?
В любом случае, еще раз спасибо за Ваше участие!
Код изменил потому, что не каждый человек, который захочет воспользоваться статьей, будет читать ее обсуждение! Статью мы выложили для людей! А не для ведения спора о ее оптимальности.
Я сто раз уже говорил, не нужно не пользуйтесь. А кому нужно, пусть уж они получит сразу более оптимальный код, раз уж удалось его улучшить с помощью этой статьи.
А то, что часть обсуждения стало вдруг не нужным, так разве _итог_ не был целью этого обсуждения? Или все-же важен сам процесс?
В любом случае, еще раз спасибо за Ваше участие!
… пьяный скрипт, где есть и 'src', и тело заработает с двух сторон. Или же принципиально проверять код только там, где 'src' пустой.
p.s. Вопросом загрузки скриптовых блоков когда-то очень плотно и кропотливо занимался один из c.l.j regulars — Randy Webb, можете посмотреть на его изыскания или почитать темы с его участием, например эту. Некоторые эксперименты проводил также Peter Michaux. Проблемы там есть. Не самым простым является и подходящее для задачи регулярное, специально не стал на этом останавливаться подробнее, слишком много неизвестных. Наконец, выполнение/не выполнение скриптов в очереди напрямую зависит от их кода, о чём уже пытался сказать sirus с его 'document.write'…
p.s. Вопросом загрузки скриптовых блоков когда-то очень плотно и кропотливо занимался один из c.l.j regulars — Randy Webb, можете посмотреть на его изыскания или почитать темы с его участием, например эту. Некоторые эксперименты проводил также Peter Michaux. Проблемы там есть. Не самым простым является и подходящее для задачи регулярное, специально не стал на этом останавливаться подробнее, слишком много неизвестных. Наконец, выполнение/не выполнение скриптов в очереди напрямую зависит от их кода, о чём уже пытался сказать sirus с его 'document.write'…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Простые вещи: Подгрузка через AJAX HTML-кода, содержащего JavaScript.