jQuery при XSLT преобразованиях на клиенте
 

Всем привет!
Я делаю следующее:
Клиенту передаю XML, в шапке указан XSLT шаблон
В шаблоне указан ряд javascript'ов, которые в общем случае работают. Но когда указывается jQuery ломается и всё перестаёт работать.

Помогите решить проблему.
В FireBug следующие ошибки:

выясни, что именно вызывает ошибку. Подключения JQuery достаточно, чтобы возникла ошибка? Поставь временно несжатый jquery и выясни, в какой именно строке возникает ошибка

Добавлю вопросов: в опере и гуглохроме тот же код работает?

Вообще пытался проблему решить на форуме jQuery
http://www.linkexchanger.su/forum/vi...&t=302&start=0
Но мне там не помогли.
В не сжатом состоянии получается такая ошибка
Что касается браузеров, то в Опере работает нормально, а вот в Хроме возникают те же ошибки.

У Firefox раньше была проблема с XSLT — скрипты запускались в исходном дереве, а не в сгенерированном. Как сейчас — не знаю, увы, но, возможно, она и осталась. Но, по крайней мере, очень похоже.
Попробуйте подключение скрипта завернуть в <![CDATA[:

<![CDATA[<script type="text/javascript" src="/js/lib/jquery.js"></script>]]>

Завернул, ошибок jQuery больше не стало, по моему его вообще не стало ...
Код по прежнему не работает

:haha:

похоже ошибка возникает при инициализации jQuery. Kolyaj что-то говорил про урезанный DOM в XML, посмотри, есть ли у div свойство style. Думаю надо будет либо фиксить jQuery, либо отказываться от нее

Или это я из статьи взял:
http://mojura.110mb.com/?article:kill.html

Походу дело тогда совсем тухлое, плохо

а зачем xml передавать? Что там вообще происходит?

Я хотел сократить трафик и для генерации страниц использовать XSLT на стороне клиента
Геморой вообще дело не излечимое, если уж гемороишься, то приходится разбираться до конца
Был бы неплохой вариант, если он конечно существует, пофиксить это на уровне правильного использования технологий. Мне кажется что я где-то ошибаюсь и что-то неправильно делаю

ну, первое, что ты неправильно сделал, это попытался сократить траффик с помощью xml. Причем причин для этого не было, так? Теоретически он может это сделать. И мне даже интересно было бы узнать о реальном примере экономии трафика, но увы, пока что не приходилось. Да и не для того он создавался. Мы где-то тут спорили уже с B~Vladi, но не было реального примера, на котором можно было бы увидеть результат... И чего это мы на скорости там зациклились так? Другие плюсы оказались не плюсами что ли? :haha:

в статье выше вон автор тоже пытается коснуться будущего, (шутя) правда забывает упомянуть, что нужно не забыть убрать руку в скором времени, ибо рано

offtop: наткнулся тут на интересную статью в википедии
p.s. Преждевременная оптимизация - корень всех зол

Я тоже с этим баловался. Результат получился не такой уж и потрясающий — если загружается документ (x)html, то его можно показывать, пока он еще не догружен до конца, в случае xhtml/xml + xslt необходимо ждать, пока подгрузится и тот и другой. Так что в итоге я только проиграл.

ЗЫЖ а для SEO (которое именно Search Engine Optimization, а не грязные трюки, вытворяемые постсоветскими «сеошниками») xhtml + xslt просто чудесно. :)

а в чем чудесность?

Исключаем шаблон из разметки и повышается плотность ключевых слов (она считается, по крайней мере, яндексом к размеру документа, а не текстовой части документа),
уменьшается вложенность тегов (это для гугля),
можно передвинуть контент в начало страницы (опять-таки, для гугля).
Легальный клоакинг: нафигацию можно сделать под «быстроссылки» забудьте о том, что я тут написал. ^.^

x-yuri, в своё время мне xslt помог сэкономить пару килобайтов (копейки, в курсе). Но у меня есть идея, ещё бредовее xslt, так что ждите постов:)

PS: инструментом нужно пользоваться грамотно... это инструмент... какой бы он нибыл...

:)

:)
x-yuri, вот например ты...
Ты за профессиональный код? Говнокод есть зло?!
Мне мало jQuery... Под него не создать ни одного теста... Да и вообще... Пора начинать писать грамотно епт... Много раз видел конструкции типа:

$(this).eq(0).attr({'checked':'false'});

Нет ни одного мануала о "правилах этикета" кодинга... Такое говно приходиться разгребать...

странный вопрос. Хочу ли я писать лучше? Естественно. Хочу ли я, чтобы говнокода не было? Нет, все с него начинают, но кто-то идет дальше, а кто-то... становиться менеджером, может :)

а что в этом плохого?

вот только недавно читал Стиль есть содержание (Джоел Х. Спольски, Лучшие примеры разработки ПО (djvu))
я бы сказал, что их слишком много. Да и что именно ты вкладываешь в "правила этикета кодинга"?

Да не, всё отлично.
Статей или книг?
Лень расписывать:)

вот и поговорили

я имел в виду скорее "правил этикета" или мнений на тему. И это скорее про правила оформления кода. Но раз ты не уточняешь, что такое правила этикета...

в прошлый раз, когда тебе было лень расписывать, это закончилось так:
;)

Нет я про API и все дела.
Ну что ж поделать...

Ну если ты тоже так считаешь, то нам действительно неочем говорить.

я не знаю, как считаешь ты. А именно, что там плохого. Может я не заметил

и какое же должно быть API? Хотя бы в том куске кода?

p.s. но если ты такой ленивый, то говорить действительно не о чем

То, что можно сделать:

this.checked = false;

Оно вообще должно быть. И желательно чтоб всё было логично и расширяемо. К этому относиться и использование inline скриптов и засирание window.

Ну уж не прям в конец. Мне проще в скайпе рассказать.

вне контекста, не вижу в том коде ничего плохого. Если уж мы подключили jQuery и еще, возможно, кучу плагинов, вряд ли пользователь заметит однократное выполнение "$(this).eq(0).attr({'checked':'false'});". Я считаю, нужно не все подряд оптимизировать, а то, что действительно влияет на производительность. Да и они ж себя не как дополнение к js позиционируют, а фактически как обертку над DOM

API там есть. Но только оно ориентировано скорее на "быстро сделать что-нибудь с DOM". Для более сложных задач не подходит. Я уже где-то оставлял ссылку на jQuery vs MooTools, правда там на англ

ну сначала они так делают, но потом, надеюсь, учаться на ошибках