Ładowanie
Spis treści |
|---|
Wprowadzenie
Do 2005 roku JavaScript, choć był dostępny w przeglądarkach internetowych, służył najczęściej jedynie do tworzenia bardzo prostych animacji, walidacji formularzy lub projektowania rozwijanego menu. Te nieskomplikowane zadania nie wymagały użycia specjalnych bibliotek, bo najczęściej konieczna ilość kodu mieściła się w kilkunastu wierszach.
Wraz z popularyzacją technologii AJAX, a także bogatych, interaktywnych interfejsów aplikacji internetowych, objętość kodu drastycznie wzrosła. Posługiwanie się nim dodatkowo utrudnił fakt, że przeglądarki internetowe (w szczególności Internet Explorer) w różny sposób implementowały szczegóły dostępu do dokumentu HTML (model DOM), deklaracje zdarzeń lub tworzenie obiektu XMLHttpRequest.
Mimo to apetyt deweloperów rósł – a JavaScript nie zawsze potrafił za nim nadążyć. Zapaleńcom dawał się we znaki brak kilku podstawowych funkcji znanych z innych języków, choćby wyszukiwania, czy dany obiekt znajduję się w tablicy oraz usuwania z tekstu spacji.
Dynamiczny rozwój sieciowych aplikacji, brak niektórych funkcji i problemy
z interoperacyjnością były głównymi przyczynami rozwoju bibliotek JavaScriptu.
Wymienione utrudnienia stały się powodem powstania kilkunastu bibliotek przeznaczonych dla popularnego języka skryptowego. Jedne starały się rozwiązać palące problemy, rozszerzając wbudowane obiekty, inne udostępniały coś na kształt dodatkowych klas i modułów. Większość jako swój podstawowy cel stawiała ułatwienie obsługi drzewa DOM i ukrycie różnic w interpretacji kodu przez przeglądarki.
Obecnie biblioteki JavaScript można podzielić na dwa rodzaje: ułatwiające dynamizację istniejącego kodu HTML poprzez uproszczenie dostępu do DOM, CSS i AJAX oraz definiujące widgety i budujące cały interfejs użytkownika bezpośrednio w JavaScript. jQuery należy do pierwszej z wymienionych kategorii – udostępnia interfejs doskonale współpracujący z „klasycznymi” dokumentami HTML. Jeśli chcemy tworzyć aplikacje internetowe generujące interfejs użytkownika w JavaScript (jak np. Gmail), prawdopodobnie wygodniej będzie skorzystać z innych bibliotek, np. Dijit lub Ext-JS.
Jeśli chcemy tworzyć aplikacje internetowe generujące interfejs użytkownika w JavaScript (jak np. Gmail), prawdopodobnie wygodniej będzie skorzystać jQuery UI.
Browser: Mozilla/5.0 (X11; U; Linux i686; pl; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.1
Browser: Opera/9.80 (Windows NT 5.1; U; en) Presto/2.2.15 Version/10.00
Troll?
Browser: Opera/9.64 (Windows NT 5.1; U; en) Presto/2.1.1
jQuery UI nie nadaje się najlepiej do tego, do czego stworzone jest np. Ext-JS, co nie znaczy, że nie można w nim tego wykonać. Ext-Js (podobnie jak GWT z Gmaila) potrafi działać sensownie jako narzędzie dla aplikacji offline zapewniając model programistyczy jak w aplikacjach desktopowych. Osobiście przy tworzeniu takiej aplikacji nie wybrałym jQuery UI - nie ze względu na zawartość, ale model programistyczny.
Browser: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.1) Gecko/20090716 Ubuntu/9.04 (jaunty) Shiretoko/3.5.1
Generalnie mam inne zdanie na ten temat. Uważam, że specyfika środowiska webowego oparta o maksymalną strukturę HTML-ową w przeciwieństwie do Ext JS, który generuje drzewo DOM ad hoc. Dla mnie najważniejsze jest przetwarzanie danych a z tego punktu widzenia aplikacje webowe z Ext JS mało się różnią od aplikacji we Flashu (Flexie, w AIR z Flashem, czy w czystym Flashu). Dlatego używam z powodzeniem jQuery i jQuery UI (zresztą jak się długo pisze jQuery to jQuery UI, praktycznie nie trzeba się uczyć, ponieważ nauka jest "przy okazji" wykorzystania danych widgetów).
Browser: Mozilla/5.0 (X11; U; Linux i686; pl; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.1
Browser: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.1
Browser: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/531.3 (KHTML, like Gecko) Chrome/3.0.193.2 Safari/531.3
Ludzie weźcie to pokolorujcie i dodajcie wcięcia. Masakra dla kogoś, kto nic z tego nie kuma jest pełna gwarancja, że nie wiele więcej zrozumie.
Browser: Mozilla/5.0 (X11; U; Linux x86_64; pl-PL; rv:1.9.0.13) Gecko/2009080315 Ubuntu/9.04 (jaunty) Firefox/3.0.13
Ludzie weźcie to pokolorujcie i dodajcie wcięcia. Masakra dla kogoś, kto nic z tego nie kuma jest pełna gwarancja, że nie wiele więcej zrozumie.
Browser: Mozilla/5.0 (X11; U; Linux x86_64; pl-PL; rv:1.9.0.13) Gecko/2009080315 Ubuntu/9.04 (jaunty) Firefox/3.0.13
Browser: Opera/9.64 (Windows NT 5.1; U; pl) Presto/2.1.1
Browser: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5 (.NET CLR 3.5.30729)
Ja z takim pytaniem, może nieco lamerskim ale co tam dopiero zaczynam z jquery
Zauważyłem, że używa zapisów przykładowo:
$("#div a") oraz $("a#div") - w teorii chyba powinno działać tak samo jednak robiąc mały przykład (chowanie i odkrywanie div'a) natrafiłem na problem a mianowicie:
$('#podglad a').click(function(event) { $('#podglad').hide('fast');
return false;
});
Powyższe działa bez zarzutu (ukrywa div'a oraz zwraca false), natomiast
$('a#podglad').click(function(event) { $('#podglad').hide('fast');
return false;
});
przenosi pod link ukryty w danym linku (href="....somthing")
Pytanie czy ten drugi zapis a#div jest niewłaściwy? jeśli nie o to co w tym chodzi? czy te dwa zapisy są różne?
możliwe, że nie doczytałem w manulau jeśli tak to nie obraże sie jak mi powiecie RTFM ;)
Browser: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/532.0 (KHTML, like Gecko) Chrome/3.0.195.33 Safari/532.0