Какие-либо большие сайты с помощью Стороны клиента XSLT?
Мне удалось решить эту проблему, используя интерполяцию для каждого класса отдельно
mean_fpr = np.linspace(0, 1, 100)
tprs.append(interp(mean_fpr, fpr, tps))
, а затем вычислить средние значения
mean_tpr = np.mean(tprs, axis=0)
plt.plot(mean_fpr, mean_tpr, color='k',
label='Mean ROC (AUC = {0:0.2f})'.format(mean_auc))
, и результат выглядит следующим образом
[117 ] 
7 ответов
Как уже упоминалось другими людьми, у Blizzard есть много сайтов, которые являются клиентскими xsl. Я бы рекомендовал избегать xsl на стороне клиента. Это действительно крутая идея, но есть много необычных ошибок, которые нужно исправить.
В Firefox любой javascript, использующий document.write, уничтожит DOM. Кроме того, плагин noscript для firefox останавливает xsl на стороне клиента. В обоих случаях пользователь ничего не увидит. Похоже, что нет способа обнаружить эту ошибку, поэтому откат не будет работать.
В IE, если у вас есть что-то, что выполняет 30-кратное перенаправление на что-то другого происхождения (переход от http к https или пересечение субдоменов), вы получите сообщение об ошибке за нарушение той же политики происхождения . На самом деле вы не нарушили ту же политику происхождения, но IE действует так же, как и вы. Например, если вы перейдете на http: //foo.example.com/login, и это выполняет перенаправление 302 на https://bar.example.com/login.xml , IE будет обрабатывать xsl, как если бы он пришел из бара .example.com, и он будет обрабатывать xml так, как если бы он пришел с foo.example.com. Поэтому вам нужно будет вернуться к чему-то вроде мета-обновления для ваших редиректов.
Это то, что я придумал совершенно неожиданно. Это отличная идея, но помните об этих проблемах.
Я не знаю больших общедоступных Веб-сайтов, которые клиентские XSLT использования преобразовывают (хорошо, кроме World of Warcraft, упомянутой Joel:-). Таким образом, я не могу ответить на Ваш вопрос непосредственно.
Однако время от времени я обдумывал тот же вопрос сам, и у меня есть гипотеза, что количество таких сайтов в Интернете должно быть очень близко к нулю.:-)
короткая версия моей теории позади этой гипотезы - это: за исключением некоторых довольно экзотических случаев, условие клиентской опции XSLT просто не стоит проблемы.:-)
Компания, в которой я работал назад в 2001 выпущенный серверный продукт, который реализовал точно архитектуру, которую Вы описываете. Мы имели очень хороший успех, разгружающий обработку на клиенты. Кроме того, делая клиентское обнаружение с помощью агента Пользователя HTTP мы смогли использовать сторону сервера XSL, обрабатывающий для угождения очень определенным клиентам как японские сотовые телефоны. Я думаю сайты/сервисы/продукты, которые используют эту технику, делают это вполне прозрачно клиентам. Однако я думаю, что тенденция в последнее время состоит в том, чтобы сделать серверную сторону обработки так, чтобы Вы не полагались, ни протестировать на конкретных реализациях XSL для множества клиентов, и Вы получаете поддержку некоторых расширений XSL, которые Вы не смогли бы использовать при поддержке подавляющего большинства браузеров.
я знаю, что непосредственно не отвечаю на Ваш вопрос именования некоторых известных сайтов, но я надеюсь, что предлагаю что-то вроде значения проблеме. Так, в основном моя точка - то, что, если сохранение производительности выполнения Вашей шаблонной обработки не более ценно, чем необходимость к QA, поддержке и разработке для трех или четырех браузеров без расширений, затем необходимо придерживаться обработки серверной стороны.
Я соглашаюсь с ответом Elijah. Я думаю, что использование стороны клиента XSLT является трудным заданием. Необходимо сделать много QA для него. Но тогда как со стороной сервера, Вы не делаете того QA. Необходимо заботиться обо всем типе клиентов и возможностей при использовании стороны клиента. Может быть возможность, что Ваш код может повредиться при использовании стороны клиента XSLT.
Я не мог сказать Вам подробно, как это реализовано, но , World of Warcraft является довольно большим и интенсивным трафиком, и их веб-сайт реализован, как Вы описываете.
I may be biased when I say this, but working on a web based app that does this, I hate it. The only reason it is even viable is because the clients are only IE6+. Even then, there are issues with it. I find XSLT to be very difficult and would suggest if you are going to do this to get a good tool for debugging and editing XSLT. Why not use JSON and jquery? Must more standard and less client side variability.
В настоящее время я запускаю несколько второстепенных страниц с клиентским XSLT, но все на шведском языке (проекты lillemanfestivalen.se, resihop.nu и бета-версии). Больше всего меня беспокоило то, что Google не индексировал содержимое моих страниц, а только XML без преобразования. Однако, поскольку я запустил resihop.nu неделю назад, он появляется в google с преобразованием ! : D
Теперь меня беспокоит еще одна проблема - facebook и другие социальные сети, которые не понимают, как с этим справиться. Однако я все еще считаю, что положительные стороны больше, чем отрицательные. Я получаю потрясающую невероятную скорость и разделение. А с resihop.nu я даже не разрабатываю отдельный API, я просто указываю разработчикам на сам сайт. (Хотя там потребуется дополнительная работа, чтобы все было хорошо)