mam pytanie, czy wysylajac formularz poprzez wywolanie go w oknie iframe nie wystapia jakies bledy, lub czy nie jest to zle rozwiazanie? nie chce zeby strona sie przeladowywala, ale czy to nie awaryjne rozwiazanie ze wzgledu na np. przegladarki nie obslugujace iframe? (chociaz chyba juz wszystkie obsluguja??)

mam taki oto formularz: http://tkwir.pl/frame.php - mozna potestowac - krytyka wskazana i wskazowki!

Poprawcie mnie jeżeli się mylę, ale:

przez iframe i tak 'przeładowujesz stronę', strona ładuje się prawie niezauważalnie
bo ma bardzo mało elementów i zero grafiki - tak mi się przynajmniej wydaje.

Co do wykorzystania iframe - zależy od przeznaczenia twojej strony
bo niektóre przeglądarki mogą tego nie obsługiwać jak zauważyłeś,
(zakładam, że jeżeli robisz to dla kogoś to powinieneś brać pod uwagę, że
jego klienci mogą używać takich przeglądarek),
a i tak pewnie w form action masz 'frame.php' więc można to pominąć.

Co do błędów wynikających z użycia samego iframe - nie sądzę by takowe powstawały.

edit: zły czy dobry pomysł : uważam raczej zły
(osobiście nie używam już tabel i ramek - nawet dynamicznych)
poczytaj na wortalach związanych z xhtml niektóre również odradzają ich stosowania

Pozdrawiam

jak chcesz bez przeładowania to AJAX. wszystko po stronie serwera i śluz. ramki IMO to zuo.

Safari, Opera, IE, Chrome, Firefox obsługują ramki. To 98 % populacji internetowe wg statystyk stron, które prowadzę.

Primo: Nie czegoś takiego jak złe rozwiązanie jeżeli działa poprawnie. Opinie, że ramki to 'zło, staroć czy Sodoma i Gomora' są kompletnie nieuzasadnione. Jedyne co może być złe to sposób ich użycia. Każdy tutorial dla początkujących programistów webowych nawołuje do rezygnacji z ihc stosowania. Ma to oczywiście swój cel (np. ratuje przed pomysłem tworzenia menu opartego na ramkach), ale wprowadza dziwny trend i niepotrzebnie nastawia wszystkich 'na nie', uzasadniając to zwykle twierdzeniem 'bo tak'. Ramki stosuje się do tej pory dosyć często, głównie w aplikacjach intranetowych ze względów bezpieczeństwa.

Secundo: Jestem przeciwnikiem stosowania skomplikowanych rozwiązań takich jak AJAX do prostych stron/funkcji. Ilość opensourcowych (fakt, że często rewelacyjnych) rozwiązań wprowadza ostatnio manię stosowania framework'ów do obsługi dosłownie wszystkiego. Ostatnio wszedłem na stronę firmy zajmującej się sprzedażą glazury. Zdziwiło mnie, że strona ładowała się za pierwszym razem około 6-8 sekund. Co zawiniło ? 1.4 MB kodu JS. Było tam wszystko. Od frameworka obsługującego Js, poprzez panele, zakładki, guziczki i inne świecidła aż po wspomniany wyżej AJAX (którego zastosowanie było dla mnie bezsensowne)... Wszystko fajnie - tylko po co? Boję się myśleć co było po stronie serwera i ile if'ów, for'ów i while'ów serwer musiał przemielić, żeby wyświetlić mi dane adresowe tej firmy. Dodam, że strona zawiera kilka podstron i prosty katalog produktów...

Sam Ajax'a stosuję tylko przy skomplikowanych stronach/aplikacjach - takich, przy których odświeżenie całej strony jest bolesne np. serwera baz danych. Oczywiście zachęcam do nauki tej techniki (dokładniej specyficznego zastosowania już istniejących technologii) jednak namawiam przy tym do umiaru. Sprawdź czy Twoje rozwiązanie działa poprawnie w większości przeglądarek. Jeżeli tak - nie kieruj się globalną opinią na temat iframe'ów. Moim zdaniem używasz ramki w sposób, do którego jest przeznaczona. Formularz kontaktowy można potraktować jako niezależny dokument/subcontent. Co do przeładowania: przeładowuje się tylko iframe a nie główny dokument. Ma to swoje wady i zalety. O tych drugich rzadko się wspomina. Iframe zawiera osobny dokument z własnym header'em a co za tym idzie z własnymi danymi meta itd. Jest kupa przypadków, w których taka sytuacja jest bardzo pożądana... Główną wadą iframe są problemy w indeksowaniu treści przez roboty (wyszukiwarek, ale niestety nie tylko), jednak formularz kontaktowy chyba nie kwalifikuje się do tej kategorii problemów? Jeżeli masz czas i ochotę: możesz oczywiście napisać samemu relatywnie prosty skrypt bazujący na technice ajax, ale wątpię, że będzie to prostsze/szybsze rozwiązanie.

pi_wo dzieki za wyczerpujaca wypowiedz! rozjasnila mi ona nieco sytuacje, w sumie to chodziło mi jedynie i głownie o to czy nie wystapia jakies problemy techniczne, a co do indeksowania to nie bedzie takiej potrzeby gdyz jest to po
1) formularz zgloszeniowy w promocji jakiejs (ograniczony czasowo)
2) nie bedzie potrzeby pozycjonowania tej strony
a sam efekt mi sie tez podoba bo po wyslaniu wyskakuja ewentualnie komunikaty w tym samym miejscu w ktorym sie kliknelo -np o bledach czy tez sukcesie wyslania

@pi_wo
widze jeden minus, czas ladowania i budowania DOM w przegladarkach
Steve Souders z googla opublikowal artykul na ten temat (zniknal po wydaniu ksiazki) gdzie twierdzil ze przegladarki czekaja na output z ramek zanim wyswietla dokument z wygenerowanym DOM, pokazywal jak w zakladce NET firebuga czas do onLoadedContent zwiekszyl sie przez umieszczenie iframe w tresci i jak ta zwloka jest duza w porownani z innymi elementami typu div, table itp

odnosnie ajaxa zgadzam sie ale pozornie niepotrzebny ajax dla prostych serwisow to np ostatnia deska ratunku gdy zaladowanie statycznego htmla pociaga za soba 90 http request (ikonki produktow), wtedy przeladowanie jednego elementu strony np bocznej miniwyszukiwarki nie pociaga za soba 90 wywolan kodu 304 czy tez 200. z pozoru niewiele bo i tak cache ale same zapytania i 304 plus ograniczenie do np 3-4 jednoczesnych odwolan dla jednej domenyto 90 x 0.10ms i daje juz pokazna sumke

Nie wiem jak było... ale wydaje mi się, że w chwili obecnej każda z ramek ładuje się jak osobne okno przeglądarki (niezależnie od innych). Nodelist jest tworzony osobno dla każdej z ramek i dynamicznie dołączany do drzewa DOM jako kolejna gałązka do parent. Zrobiłem test w FF 3.0.5, flush dokumentów z 5-sekundowym opóźnieniem i ramki otwierają się niezależnie od siebie. Co więcej JS działa już po załadowaniu się pierwszej ramki.



Zwłoka jest na pewno - pytanie czy jest odczuwalna dla użytkownika - w przypadku małego formularza opóźnienia mają znaczenie tylko symboliczne.



Oczywiście masz rację, są sytuacje, w których ajax to:

1) wygodniejsze
2) efektywniejsze
3) jedyne sensowne

rozwiązanie. Jednak co raz częściej spotykam się z sytuacjami, w których ludzie zamiast napisać 5 linii prostego kodu stosują gotowca, który wykorzystują w 0.1 %.

Inn - dałeś mi okazję pomarudzić na innych, więc przyjemność po mojej stronie ;]