200 elementów to nie jest duża liczba dla nowych przeglądarek. Jeżeli te 200 elementów jest jakoś ze sobą powiązanych, tzn. jest to jakaś lista czy coś takiego, to spróbuj koniecznie użyć delegate, ustawisz wtedy jeden event dla wszystkich elementów, co znacząco potrafi poprawić wydajność.
Co do wydajności jeszcze - funkcje wrzucone w onclick są szybsze niż eventy. Pytanie tylko czy ma to aż tak duże znaczenie?[/quote]
Po pierwsze - myślę, że tę dyskusję dobrze byłoby wyodrębnić do osobnego wątku.
A co do samego kodu:
[code=javascript]jQuery(function($) {
// create a convenient toggleLoading function
var showLoading = function() { $("#spinner").show(); };
var hideLoading = function() { $("#spinner").hide();};
$(“a[data-remote],form[data-remote]”).live(“ajax:loading”, showLoading);
$(“a[data-remote],form[data-remote]”).live(“ajax:complete”, hideLoading);
$(“a[data-remote],form[data-remote]”).live(“ajax:failure”, function(data, status, xhr) {
$("#spinner").hide();
$("#error_box").show();
$("#error_box").fadeOut(3000);
});
$(“a[data-update],form[data-update]”).live(“ajax:success”, function(data,status,xhr){
$("#"+$(this).attr(“data-update”)).html(status);
});
$(“img.close_button”).live(“click”, function(){
$(this).parents(".relations").first().parent().html("");
});
});[/code]
Na każdy element przypada ok 10 linków ajaxowych, co daje razem 2000 aktywnych elementów (tzn. lub dla których podpinane są te handlery).
Jeśli da się to jakoś prosto zoptymalizować to będę wdzięczny za wskazówki.
aphollo: To wina brzydkiego jQuery, a dokładniej metody ‘live’ która jest @#$@$ po prostu wolna, ze wzgledu na to że wpina się nie w konkretny element tylko wysoko w łańcuch zdażeń na body. Co powoduje że KAŻDY event jest sprawdzany pod kątem danej akcji. Czyli jak masz w cholerę elementów + w cholere zdażeń na live to niestety czas obsługi rośnie.
Generalnie o ile jQuery twierdzi że to nie jest problem, to z mojego doświadczenia jest odrobinę odwrotnie, rzuć okiem na tematy o event delegation. Z tego co pamiętam mozna ‘live’ podmienić na delegate żeby troszkę przyśpieszyć.
No wiem wiem, nawet w artykule pisze, że już poprawione. Ale coś mi sie wydaje, że mała która aplikacja zostanie uaktualniona, a szczególnie te stare, napisane w rails 1 czy 2
Imho koleś trochę przesadza Zgadzam się z tym, że security release nie powinno być wypuszczone razem z innymi poprawkami obecnymi w 2-3-stable i 3-0-stable, ale żądanie utrzymywania wszystkich wersji 2.3.x (np. 2.3.5) jest niemożliwe, chyba, że rails core team zajmie się tylko utrzymywaniem starych wersji zamiast tworzeniem nowych.
Teraz to ty troche przesadzasz, przy tych wszystkich cudach wiankach, gitach, githubach, naprawde tak ciężko zrobić gałąź 2-3-stable i wrzucać security fixy ? Uprzedzam że nie czytałem tematu na rails-core Ale to co robi się w Rails i w Ruby z releasami 2.3.x i 1.8.x to badziewiarstwo i tyle, nie ma na to wymówki.
Ale czy to tylko ja zauważam że błąd dotyczy CSRF, nie ma na razie prostej (albo w cale) opracowanej metody go wykorzystania w praktyce, i wcale nie wszystkie serwisy są w ogóle podatne? Burza w szklance wody – błędny błąd, nic się (jeszcze) nie stało.
Edit: ale b. dobrze że został naprawiony, tylko nawoływania do aktualizacji wszystkich aplikacji albo utrzymywania poprawek do wszystkich wersji Railsów są moim zdaniem przesadzone.
To prawda. Jak dla mnie powinny wziąć ostatnie wersje gałęzi stable jakie są utrzymywane, czyli aktualnie ostatnie 3.0.* i 2.3.*, nałożyć patche i wydać z ostatnim numerkiem podbitym +1.
Niby w stable starają się zachować stable i teoretycznie nie powinno być problemu a w praktyce zawsze się jakiś problem znajdzie i przez to ludzie nie mogą błyskawicznie upgradeować.
Jeśli jest np 3.0.3 i w stable jest 3.0.4rc przykładowo i trzeba nałożyć łatkę bezpieczeństwa to ja bym wydał 3.0.3 + łatka jako 3.0.4 i zamienił 3.0.4rc na 3.0.5rc. To moim zdaniem dużo mniej osób zaboli (jakiś ludzi co tylko korzystali z wersji rozwojowych i w jakimś momencie przyjeli że 3.0.4 ma ficzery z 3.0.4.rc) a wielu osobom ułatwi.
Mogliby też używać numeracji czterocyferkowej ? 3.0.3.1 ?
Akurat te poprawki ciężko jest wrzucić do wersji poniżej 2.3.6, jeżeli masz czas i chęci to zapraszam, na pewno się wszyscy ucieszą jak wrzucisz patcha Każdy ma ograniczone zasoby czasowe i jeżeli ktoś dalej nie przerzucił aplikacji z wersji 2.3.5, to jest jego sprawa - zmiany były minimalne, a czasu było bardzo dużo.
No akurat fix i rozpowszechnienie go to najmniejszy problem. Ale postawienie sobie testowej aplikacji na starszych wersjach, rozkminienie wszystkich skomplikowanych zależności fix’a typu co się stanie jeśli i wyobrażenie sobie wpływu na tysiąć różnych nieco obsolete aplikacji już łatwe i szybkie nie jest. Wymaga czasu, rozwagi, dokładności, zastanowienia się i dobrej wiedzy nt security.
Akurat te poprawki ciężko jest wrzucić do wersji poniżej 2.3.6, jeżeli masz czas i chęci to zapraszam, na pewno się wszyscy ucieszą jak wrzucisz patcha Każdy ma ograniczone zasoby czasowe i jeżeli ktoś dalej nie przerzucił aplikacji z wersji 2.3.5, to jest jego sprawa - zmiany były minimalne, a czasu było bardzo dużo.[/quote]
No i tu mnie masz to w końcu community driven project.
Aj waj, za wcześnie, jeszcze nie przeredagowaliśmy tekstów (jest trochę baboli ortograficznych i gramatycznych) i ogólnie trochę poprawek czeka tę stronę
Zgadzam się z tym, że security release nie powinno być wypuszczone razem z innymi poprawkami obecnymi w 2-3-stable i 3-0-stable, ale żądanie utrzymywania wszystkich wersji 2.3.x (np. 2.3.5) jest niemożliwe, chyba, że rails core team zajmie się tylko utrzymywaniem starych wersji zamiast tworzeniem nowych.