UpdatePanel, a callback
Peri
Jak się ma stosowanie UpdatePanel do callbacków AJAX? Czy jedno i drugie
to to samo? Wydaje mi się, że nie.
Korzystam z kontrolek DevExpress i są tam CallBack panele i kontrolki
Callback. Stosująć UpdatePanel i ich callback zauważyłem, że callback jest
znacznie szybszy.
--
Peri
wzy...@gmail.com
> Jako, że jestem nowy w ASP.NET (do tej pory tylko WinForms) mam pytanie.
>
> Jak się ma stosowanie UpdatePanel do callbacków AJAX? Czy jedno i drugie
> to to samo? Wydaje mi się, że nie.
UpdatePanel to formant, który sam potrafi generować callbacki AJAX, a
potem konsumować efekty tych callbacków w odniesieniu do formantów
bibliotecznych. "AJAX callback" to ogólna nazwa mechanizmu postowania
do serwera aplikacji za pomocą XmlHttpRequest.
> Korzystam z kontrolek DevExpress i są tam CallBack panele i kontrolki
> Callback. Stosująć UpdatePanel i ich callback zauważyłem, że callback jest
> znacznie szybszy.
różnice w prędkości działania czy ilości przesyłanych w tę i z
powrotem danych pomiędzy różnymi implementacjami AJAX są olbrzymie. z
rok temu robiłem taki mały test 6 frameworków AJAX pod kątem liczby
przesyłanych danych, pooglądaj sobie jak bardzo się rózniły.
jeśli chodzi o czas działania, to najwęższym gardłem i tak jest rura,
po której gada protokół komunikacyjny. narzut po stronie klienckiej/
serwerowej może być zauważalny tylko przy niezbyt udanej
implementacji, przynajmniej takie jest moje zdanie. na przykład VWG ma
całkiem skomplikowane skrypty java po stronie przeglądarki, które
rzeczywiście dają wrażenie "mułowatości" aplikacji. sęk w tym, ze w
tej architekturze to nie jest najważniejsze kryterium jej oceny i
dlatego trudno dyskwalifikować framework tylko dlatego, ze wydaje CI
się, że coś jest "znacznie szybsze". a może dzięki temu na przykład
przesyła dwa razy mniej danych? musisz bardzo uważnie sprawdzić jeden
i drugi mechanizm pod różnymi kątami żeby móc je właściwie ocenić.
Wiktor Zychla
Peri
troche inaczej działa.
Tutaj podłączają się pod przycisk bez AutoPostbacku. W przypadku
UpdatePanelu stosuje zwyczajne przyciski z AutoPostaback. W przypadku
innych kontrolek również trzeba ustawiać AutoPostback = true.
W przypadku UpdatePanel po stronie serwera kod wykonuje się jak w
przypadku normalnego PostaBacka (OnLoad itd.). Czy w przypadku Callbacków
nie wywołuje mi się tylko jedna konkretna metoda? Bez całego cyklu życia
strony?
--
Peri
wzy...@gmail.com
> troche inaczej działa.
to zależy CO inaczej działa. nie ma czegoś takiego jak "callbacki
AJAX", bo w każdym z 15 frameworków jakie znam, to pojęcie oznacza coś
innego. jeśli ZASÓB, do którego odnosi się żądanie przewiduje jakiś
specjalny tryb obsługi, to niewykluczone, że omija on standardowy
potok zdarzeń. ja też potrafiłbym napisać framework, w którym
"callback AJAX" omija nawet Page_Load.
zerknąłem natomiast w ten artykuł i widzę tam odniesienie do dwóch
mechanizmów:
- stareńkiego Scripting Callbacks, który jest trochę już starocią,
dostępną w asp.net 2.0
- callbacków, obsługiwanych ekskluzywnie przez GridView/TreeView,
które są absolutnym "kowalstwem" i przy wykorzystaniu UpdatePanel
praktycznie nie ma sensu z nich korzystać (sądzę, że nawet mogą być z
UpdatePanel niezgodne)
czy mówiąc "callbacki AJAX" masz na myśli któryś z tych dwóch, czy
może jakiś mechanizm specyficzny dla ASP.NET AJAX?
skądinąd jeśli szukasz fajnych frameworków do obsługi samych
callbacków (bo logikę konsumpcji wyniku po stronie przeglądarki umiesz
sobie napisać sam), to zainteresuj się frameworkami:
- ajax.net
- jayrock
- script#
nie testowałem ich pod względem wydajności, ale mogą być rozsądną
alternatywą, jeszcze raz podkreślam - przy założeniu, że w
"callbackach AJAX" upatrujesz miejsca, które należy jakoś usprawnić.
Wiktor Zychla
Peri
>> Z tego co tutajhttp://steveorr.net/articles/Ajax.aspxrozumiem to jednak
>>
>> troche inaczej działa.
>
> to zależy CO inaczej działa. nie ma czegoś takiego jak "callbacki
> AJAX", bo w każdym z 15 frameworków jakie znam, to pojęcie oznacza coś
> innego. jeśli ZASÓB, do którego odnosi się żądanie przewiduje jakiś
> specjalny tryb obsługi, to niewykluczone, że omija on standardowy
> potok zdarzeń. ja też potrafiłbym napisać framework, w którym
> "callback AJAX" omija nawet Page_Load.
>
> zerknąłem natomiast w ten artykuł i widzę tam odniesienie do dwóch
> mechanizmów:
> - stareńkiego Scripting Callbacks, który jest trochę już starocią,
> dostępną w asp.net 2.0
Akurat z 2.0 korzystam. Może i to jest coś starego, ale chyba równie
starego jak UpdatePanel?
Jeżeli dobrze rozumiem cały ten mechanizm callbacków to tutaj wywołuje się
konkretna metoda
po stronie serwera (i żadna inna) i wynik zwracany jest do przeglądarki,
która przy pomocy
Javascript modyfikuje HTML-a. Przy użyciu UpdatePanela "żyje" cała strona
tak jak przy normalnym
PostBacku i wtedy mogę tego HTML-a (kontrolki asp.net) modyfikować po
stronie serwera.
Zrobiłem mały test przy użyciu UpdatePanel i callbacków (devexpress). Mam
4 comba połączone kaskadowo.
Z mechanizmem callbacków to działa, bez żadnej przesady, conajnmiej 2 razy
szybciej. Niestety
przy zastosowaniu callbacków mam problem z obsługą kontrolek devexpress
przez Javascript, ale
zainteresowało mnie dlaczego tak dużo szybciej to działa.
No i czy napewno to Scripting Callbacks (chyba również nazywane Remote
Scripting) to taka starość?
W jednym z filmików na www.componentart.com mówią, że dzięki ich kontrolką
można wyeliminować postabacki,
a nawet callbacki. Zresztą sami zobaczcie jaka jest różnica w wydajności
pomiędzy UpdatePanel, a callbackami.
http://www.componentart.com/webui/demos/ajax/technique1/
(u góry zakładki do przełączania się pomiedzy rozwiązaniami)
> skądinąd jeśli szukasz fajnych frameworków do obsługi samych
> callbacków (bo logikę konsumpcji wyniku po stronie przeglądarki umiesz
> sobie napisać sam), to zainteresuj się frameworkami:
> - ajax.net
> - jayrock
> - script#
Mogę skorzystać tylko z Devexpressowych.
--
Peri
Peri
PS. W poprzednim poście napisałem "dzięki ich kontrolką". Oczywiście
chodziło mi o kontrolkom :)
--
Peri
Peri
wzy...@gmail.com
> Scripting) to taka starość?
staroć o tyle, ze w 3.5 promuje się model, w którym callbacki kieruje
się do WebServices.
> Akurat z 2.0 korzystam. Może i to jest coś starego, ale chyba równie
> starego jak UpdatePanel?
nie. scripting callbacks było jedyną sensowną technologią w 2.0,
natomiast w 3.5 ajax ma nie tylko wsparcie ze strony updatepanel, ale
również całych flaków pozwalających na jego rozszerzanie (np. o
własnie extendery).
> Ta stronka odpowiada na moje wszystkie pytania.
ładne, choć to oczywiście nie wszystkie możliwości. najważniejsze, że
coś Ci się wyjaśniło.
> a nawet callbacki. Zresztą sami zobaczcie jaka jest różnica w wydajności
> pomiędzy UpdatePanel, a callbackami.
nie daj się zwodzić materiałom marketingowym, przygotowanym właśnie po
to żeby zwodzić. uczciwy test porównujący technologie musisz zawsze
przeprowadzić sam, a nie polegać na teście przeprowadzonym przez
producenta technologii.
musisz poznać obie technologie w stopniu pozwalającym na wykonanie TEJ
samej aplikacji w obu, ale to musi być TWOJA aplikacja, a nie czyjaś.
Wiktor Zychla
Peri
However, ComponentArt CallBack is driven entirely by its client-side API.
Developers specify exactly when a callback will be triggered and exactly
which parameters will be sent to the server (CallBack doesn't post the
page by default). This triggers a server-side event, where the developer
has full control over what will be rendered back to the client.
Zwróćmy uwagę na "(CallBack doesn't post the page by default)".
A potem jest napisane:
Performance: Requests made through the CallBack control are extremely
lightweight in terms of network traffic. However, each request has to go
through the full page life cycle and the response typically generates HTML
and sends it back to the browser.
I zwróćmy uwagę na "However, each request has to go through the full page
life cycle". Nie rozumiem tego. Czy jedno nie wyklucza drugiego?
--
Peri
wzy...@gmail.com
> Jeszcze jedno pytanko. Na stronie napisano:
>
> However, ComponentArt CallBack is driven entirely by its client-side API.
> Developers specify exactly when a callback will be triggered and exactly
> which parameters will be sent to the server (CallBack doesn't post the
> page by default). This triggers a server-side event, where the developer
> has full control over what will be rendered back to the client.
>
bo w normalnym trybie pracy aplikacji ASP.NET przeglarka POSTuje CAŁY
formularz, a ich callback, jak sami piszą, generuje jakiegoś
króciutkiego GETa. różnica jest w liczbie danych przesyłanych z
klienta na serwer.
> Performance: Requests made through the CallBack control are extremely
> lightweight in terms of network traffic. However, each request has to go
> through the full page life cycle and the response typically generates HTML
> and sends it back to the browser.
>
> I zwróæmy uwagê na "However, each request has to go through the full page
> life cycle". Nie rozumiem tego. Czy jedno nie wyklucza drugiego?
nie. z tego po prostu wynika, że nic się nie zmienia w sensie
odpowiedzi serwera do klienta. jak widać ten "extremely lightweight"
to "chłyt matetingody".
nie znam szczegółów, ale to brzmi średnio atrakcyjnie. żądania
callback powinny w wyniku produkować XMLe albo JSONy a nie HTMLe. zysk
z AJAX ma również polegać na tym że serwer nie produkuje w wyniku
żądania całej strony, tylko jakiś fragment zmodyfikowanego modelu,
który następnie kolejny javascript przetwarza po stronie klienta.
z ciekawości: czemu drążysz ten componentart? wcześniej zrozumiałem,
że jesteś zbindowany do devexpresa.
Wiktor Zychla
Peri
> ... ale to brzmi średnio atrakcyjnie. żądania
> callback powinny w wyniku produkować XMLe albo JSONy a nie HTMLe. zysk
> z AJAX ma również polegać na tym że serwer nie produkuje w wyniku
> żądania całej strony, tylko jakiś fragment zmodyfikowanego modelu,
> który następnie kolejny javascript przetwarza po stronie klienta.
>
> z ciekawości: czemu drążysz ten componentart? wcześniej zrozumiałem,
> że jesteś zbindowany do devexpresa.
Brzmi to standardowo, bo wszyscy tak pewnie robią te "callbacki".
Zacytowałem z
Componentart, bo mieli to fajnie opisane. Devexpress pewnie robie
identycznie.
Rozwiązanie, o którym piszez Componentart również ma zaimplementowane.
Jestem związany z Devexpress. Przy okazji. Strony, które powstają z
wykorzystaniem
DevEx są ogromne! Ok 400kB na standardową stronę. Tniemy je teraz gdzie
sie da i
korzystamy z kontrolek asp.netowych.
--
Peri
Wiktor Zychla
ok. oczywiście serwer może wyprodukować HTMLa i jest oczywiście fragment
strony, a nie cała strona.
dlatego napisałem, że "callback powinien produkować XMLe albo JSONy" (w
rozumieniu "nie całą stronę tylko jakiś jej zmodyfikowany fragment").
mi gdzieś tam się przywidziało, że "wynikiem callback jest CAŁA strona", ale
sprawdziłem i oczywiście tam jest napisane poprawnie ("sends HTML", nigdzie
nie piszą o "całej stronie").
Wiktor Zychla