Javascript

Atrybut Title w Internet Explorer – jak usunąć?

7 years ago
by Quadric in , ,

Ostatnio napotkałem na dość dziwny problem w przeglądarce Internet Explorer (a jakże) z atrybutem title. Miałem za zadanie stworzyć własny system wyświetlający podpowiedzi do danego wiersza w zestawie pól formularza. Naturalnym rozwiązaniem dla mnie było użycie atrybutu “title” Algorytm sprowadził się do tego, że na zdarzeniu :hover pobierałem atrybut title przekazywałem do mojego systemu a z tego usuwałem. Wszystko to wykonane było za pomocą jQuery

$('.row').hover(function() {
    var title = $(this).attr('title');
    $(this).removeAttr('title');
});

Wydawałoby się, że to dosyć proste i banalne, jednakże Internet Explorer zupełnie nie rozumie o co chodzi. Usunięcie atrybutu title zwyczajnie nie przynosi rezultatów. Chmurka od przeglądarki nadal się pojawia. Rozwiązanie jakie udało mi się wynaleźć to ustawienie title na wartość pustą

$('.row').hover(function() {
    var title = $(this).attr('title');
    $(this).attr('title', '');
});

I voila! Teraz Internet Explorer jak i inne przeglądarki nie mają problemu. Chmurka przestaje się pojawiać. Co ciekawe… jeśli jednak dodatkowo potem jeszcze usunę ten atrybut w ten sposób:

$('.row').hover(function() {
    var title = $(this).attr('title');
    $(this).attr('title', '');
    $(this).removeAttr('title');
});

to chmurka znowu się pojawia z oryginalnym tekstem. Wygląda na to, że ustawienie samodzielne title jakoby podmienia zawartość kontenera zatem usunięcie tego co sami zrobimy “odsłania” wartość pierwotną. Dziwne?

Sposób na AJAX’a

10 years ago
by Quadric in , , ,

Podam Wam teraz 3 znane przeze mnie metody obsługi ajaxa i powiem co wg mnie jest dobrym a co złym rozwiązaniem.

Sposób 1

W większości opisów i przykładów używanie ajaxa “kończy się” “osobnym bytem” w postaci pliku *.php znajdującego się gdzieś w katalogu publicznym:

/public
—/images
—/scripts
—/ajax
——/ajax_show_subcategories.php
——/ajax_check_email.php

Jest to najprostsze rozwiązanie ale jednocześnie najmniej efektywne. Po pierwsze każdy ajax to osobny plik który jakby “odcina” się od naszego systemu – czasami jest to pożądane ale w większości przypadków skrypt w ajaxie stanowi pewną funkcjonalność naszego systemu. Każdy z tych plików musi includować ręcznie jakieś pliki związane np z obsługą bazy danych, przetwarzać pliki konfiguracyjne itd itd. Jest to na pewno mało efektywne rozwiązanie ale na początek – zwłaszcza dla osób, które chcą się ajaxa dopiero nauczyć – rozwiązanie całkowicie wystarczające.

Zalety:
– prosty do zrobienia
– łatwy do przyswojenia

Wady
– mało wydajny
– nieefektywny
– nieelegancki
– sztucznie oddziela ajax’y od reszty systemu (tak jakby był w innym języku pisany)
– upublicznia kod (bo musi znajdować się w katalogu public)

Sposób 2

Ciekawszym i bardziej złożonym rozwiązaniem jest użycie tzw “ajax handlera”. Nie ma w tym nic rewolucyjnego. Cała idea polega na stworzeniu małego skryptu o dostępie publicznym który byłby pośrednikiem między odwołaniami do ajaxa a samymi skryptami ajaxowymi. Mówiąc prościej nie odwołujemy się bezpośrednio do skryptów ajaxowych tylko “prosimy” nasz ajax_handler aby dla nas jakis skrypt uruchomił. Przy czym skrypty ajaxowe mamy gdzieś schowane poza katalog publiczny – tak, że tylko ajax handler może je uruchomić. Ponadto do ajax_handlera możemy dodać od razu procedury które potrzebuje nasz program (np obsługa bazy danych) bez potrzeby dodawania ich do każdego skryptu oddzielnie.

/public
—/images
—/scripts
—/ajax_handler.php
/ajax
—/ajax_show_subcategories.php
—/ajax_check_email.php

Przykład: /ajax_handler?odpal_skrypt=ajax_show_subcategories.php

Rozwiązanie jest bardzo fajne ale… nie różni się ono ideowo od sposobu pierwszego. Jest to swego rodzaju “oszukaństwo” – po prostu zautomatyzowanie pewnych czynności i rozwiązanie kilku wyżej wymienionych wad – lecz nadal skrypty te stanowią odrębny byt i wymagają specjalnego traktowania. Podsumujmy.

Zalety
– Całkiem wydajny
– Ukrycie ajaxów z katalogu publicznego
– Dosyć elegancki (mydlenie oczu)

Wady
– Nieefektywny
– Sztucznie oddziela ajaxy od reszty systemu
– Wymaga stworzenia dodatkowego systemu (ajax_handler)
– Wywoływanie skryptów odbywa się w nienaturalny sposób

Sposób 3 – jak to zrobić w GRAD?

W frameworku GRAD proponuje podejść do problemu w zupełnie inny sposób. Metodą tę można zastosować także w innych aplikacjach ale wyjaśnię najpierw o co chodzi.

Odpowiedzmy sobie na pytanie: Czym jest program wywoływany w ajaxie?
Odpowiedź: Zwyczajnym skryptem PHP

Odpowiedzmy sobie na drugie pytanie: Czym jest program wywoływany w request?
Odpowiedź: Zwyczajnym skryptem PHP

Wniosek? Uruchamiajmy ajaxa po prostu jako zwyczajny request.

Jeżeli GRAD dzieli aplikację na kontrolery i akcję to nie ma znaczenia czy uruchomisz akcję wpisując w przeglądarce:

http://localhost/category/show

czy też uruchamiając w ajaxie (np z wykorzystaniem jQuery – albo twojej innej ulubionej metody uruchamiania ajaxów):

$.ajax({
url: “/category/show“,
dataType: “xml”,
success: function(xml) {
}
});

I już! To jaką metodę wybierzesz do uruchamiana ajaxów to juz jest Twoja wola. Różnica w całym podejściu polega na tym, żeby nie rozróżniać ajaxów na osobne pliki a traktować je jako naszą integralną część systemu. W ten sposób możemy wymazać pojecią “skrypty ajaxowe” bo każdy z twoich skryptów może być wywołany metodą ajaxową i każdy normalną metodą request w przeglądarce. Myślę, że na tym polega profesjonalne podejście do programowania dynamicznych, ciekawych i przede wszystkim spójnych stron w prosty i najbardziej naturalny sposób.

Zalety
– kod to kod, po co go rozróżniać?
– wybierasz metodę do skryptu a nie skrypt do metody
– eleganckie
– przejrzyste
– wydajne
– spójne

Wady
– Musisz zmienić sposób myślenia 🙂

To wszystko w tym artykule. Zachęcam gorąco do zabawy z moim frameworkiem – uważam, że naprawdę warto jeśli chcesz szybko i wydajnie skonstruować dynamiczną i wydajną stronę internetową.

Zobacz framework GRAD

Zachęcam gorąco do komentarzy na temat tego artykułu.

Pozdrawiam serdecznie.

Go to Top