Comments 17
Было бы ещё не плохо увидеть пару скриншотов того, что получилось, для улучшения восприятия.
Но всё равно достаточно интересно.
Но всё равно достаточно интересно.
А если бы еще была ссылка на демку, то еще лучше :-)
А вообще, полезная статья в плане того, на сколько граблей пришлось наступить, чтобы заставить заработать, казалось бы, несколько простых частей вместе.
А вообще, полезная статья в плане того, на сколько граблей пришлось наступить, чтобы заставить заработать, казалось бы, несколько простых частей вместе.
На счёт грабель — это да. Более того, я попутно нашёл багу в FireFox-е, пока это делал.
На счёт демки — подумаю.
На счёт демки — подумаю.
Очень большое спасибо) Вы очень вовремя, я вчера пол дня просидел!
Добавил исходный код.
Почему то мне кажется что вариант с оригинальным аяксом проще раза в 2,
www.asp.net/AJAX/AjaxControlToolkit/Samples/ModalPopup/ModalPopup.aspx
впрочем это имхо… интересно, какие у автора основания…
www.asp.net/AJAX/AjaxControlToolkit/Samples/ModalPopup/ModalPopup.aspx
впрочем это имхо… интересно, какие у автора основания…
Ну, причины перейти с MS AJAX на jQuery у каждого могут найтись (а могут и не найтись) разные.
У меня лично всё по опыту.
* MS AJAX скрипты крайне тяжёлые (хоть и кэшируются).
* Их неоправданно много и включение script combining поднимает загрузку одного из наших сайтов на 100% на всех 4-х процах (уж не знаю чего там страшного разработчики AjaxControlToolkit наворотили)
* Что самое главное — верстальщики толком не могут «подлезть» в то, что нагенерил AjaxControlToolkit — буквально на каждый «чих» (читай — небольшое изменение функциональости AjaxControlToolkit) нужно править исходники библиотеки, что, конечно, не вариант в свете переодических обновлений самой AjaxControlToolkit (т.е. нужно потом как-то «накатывать» внесённые изменения, а TFS merge с этим не так хорошо справляется).
* Мы всё равно почти всегда используем jQuery для всякого рода эффектов (которых нет и вряд ли будут в AjaxControlToolkit), так что раньше получалось мы грузили две библиотеки
Вот, к примеру, опыт другого разработчика, перешедшего на jQuery ajax (отсюда):
By using jQuery to call the web service directly, we’ve eliminated over 100 KB of JavaScript and three extra HTTP requests. The ASP.NET AJAX client side framework accounted for over half of the original example’s total download size, and those three extra HTTP requests unnecessarily delayed the progress indicator.
That may not sound like much, but it’s significant. When it comes to loading speed and responsiveness, users do not perceive changes linearly. Fractions of a second make the difference between a site that feels sluggish and one that appears responsive.
У меня лично всё по опыту.
* MS AJAX скрипты крайне тяжёлые (хоть и кэшируются).
* Их неоправданно много и включение script combining поднимает загрузку одного из наших сайтов на 100% на всех 4-х процах (уж не знаю чего там страшного разработчики AjaxControlToolkit наворотили)
* Что самое главное — верстальщики толком не могут «подлезть» в то, что нагенерил AjaxControlToolkit — буквально на каждый «чих» (читай — небольшое изменение функциональости AjaxControlToolkit) нужно править исходники библиотеки, что, конечно, не вариант в свете переодических обновлений самой AjaxControlToolkit (т.е. нужно потом как-то «накатывать» внесённые изменения, а TFS merge с этим не так хорошо справляется).
* Мы всё равно почти всегда используем jQuery для всякого рода эффектов (которых нет и вряд ли будут в AjaxControlToolkit), так что раньше получалось мы грузили две библиотеки
Вот, к примеру, опыт другого разработчика, перешедшего на jQuery ajax (отсюда):
By using jQuery to call the web service directly, we’ve eliminated over 100 KB of JavaScript and three extra HTTP requests. The ASP.NET AJAX client side framework accounted for over half of the original example’s total download size, and those three extra HTTP requests unnecessarily delayed the progress indicator.
That may not sound like much, but it’s significant. When it comes to loading speed and responsiveness, users do not perceive changes linearly. Fractions of a second make the difference between a site that feels sluggish and one that appears responsive.
Ну, допустим чистый MS AJAX не такой уж и тяжелый(если конечно AjaxControlToolkit не юзать). Другое дело — это наличие огромного количества плагинов для всяких рюшечек в jQuery. Это очень сильно ускоряет работу, без этого сложно и не так красиво. Что есть то есть. В идеале, конечно сделать свой набор контролов в идеогогии Ajaxtoolkit, но со скриптами jQuery :)
понятненько…
автор, пара вопросов:
1. почему используете Panel, нельзя ли заменить на div? тогда не надо будет делать <%= this.panelMain.ClientID %>
2. Зачем это $(«#<%= this.panelMain.ClientID %>»).css(«display», «block»); панель вроде бы и так рендерится в div, у которого, известно, и так display: block?
разъясните плиз, интересная статья
1. почему используете Panel, нельзя ли заменить на div? тогда не надо будет делать <%= this.panelMain.ClientID %>
2. Зачем это $(«#<%= this.panelMain.ClientID %>»).css(«display», «block»); панель вроде бы и так рендерится в div, у которого, известно, и так display: block?
разъясните плиз, интересная статья
Простите, а в чем соль статьи?
Невкурил.
Невкурил.
Эта статья для тех, кто хочет «прикрутить» всплывающие формы на ASP.NET сайт, но не хочет использовать AjaxControlToolkit.
кстати я юзал вместо jQuery для этого Scriptaculous и ProtoType
prototype-window.xilinus.com/
если мне память не изменяет…
prototype-window.xilinus.com/
если мне память не изменяет…
Sign up to leave a comment.
Всплывающие модальные окна на jQuery в ASP.NET