Posts tagged HTML

Atrybut Title w Internet Explorer – jak usunąć?

1
1 year 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

0
4 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