Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Optymalnoś Ajaxa poprzez zapis do pliku XML
Forum PHP.pl > Forum > XML, AJAX
Rid
Zastanawiałem nad zapisem wyników końcowych z JS do pliku XML za pomocą Ajaxa.
Taka komunikacja klient-serwer ,serwer-klient gdzie warstwą pośredniczącą byłby plik xml, które przechowywałyby dane .Czy taka komunikacja ,byłaby optymalna??Wszakże nie ,byłoby requestów dotyczących jednej strony i generowania sztucznego ruchu.
O co mi chodzi:
1.Wpisujemy do pola input zmienną
2. Za pomocą onclick w jakimś przycisku, zasysamy ją do JS ,i jak tam kto chce(przerabiamy dodajemy klasy itp.).
3.Wynik końcowy za pomocą Ajaxa przesyłamy do pliku xml zamiast np.z powrotem na stronę poprzez url.
4.Zamiast $_GET, odczytujemy dane za pomocą $xml = new SimpleXMLElement($xmlstr);

Co sądzicie o takim rozwiązaniu???Może bredzę,ale zastanawia mnie, bo nie byłoby wtedy callbacka na serwer co
zmniejszyłoby sztuczny ruch na serwerze,nie trzeba by było używać requesta $_GET do odebrania danych zwrotnych.
Nie wiem o ile jest to możliwe,to byłoby to chyba bardziej optymalne rozwiązanie jeśli chodzi o o komunikację klient-serwer.

Nie wiem,jeśli ten post jest od rzeczy to prosiłbym administratorów o jego usunięcie.Naprawdę interesuje mnie taki sposób komunikacji klient-serwer o ile jest możliwy.
everth
Jeśli dobrze cię zrozumiałem to bredzisz smile.gif Tak ja to widzę:
  • Formularz -> submit -> (PHP?) plik XML
  • XML -> PHP -> Strona

Chyba że myślałeś bardziej o czymś takim:
  • Formularz -> submit -> PHP -> plik XML (tymczasowy)
  • XML -> transformacja po stronie klienta -> strona

W tym drugim przypadku teoretycznie mógłbyś uniknąć przejścia przez PHP i serwować po prostu statycznie zapisany XML. Tylko to strasznie przekombinowane i w zasadzie bezsensowne. Jeśli chcesz naprawdę zaoszczędzić żądań to rozbuduj walidację formularzy po stronie klienta - jeśli już pójdzie żądanie to będzie znacznie większa szansa że zostanie zaakceptowane przy pierwszym podejściu.
Rid
Ja myślałem bardziej o takim schemacie:
Formularz ->button(onclick) -> Ajax -> plik XML (tymczasowy)
XML -> PHP -> Strona

Chociaż,nawet doczytałem,że nie trzeba do tego mieszać ajaxa-chociaż poszerza on możliwości.

W JS można utworzyć dokument xml poprzez.
var XML = new XMLWriter();
sposób tutaj opisany:
http://www.codeproject.com/KB/ajax/XMLWriter.aspx

Czyli bez przeładowania strony(po stronie klirnta) tworzymy, plik xml z jakimiś danymi,a potem pobieramy z tego dokumentu po stronie PHP interesujące nas dane.A więc możliwa jest komunikacja klient-serwer,bez użycia Ajaxa i bez przeładowania strony?questionmark.gif
everth
Schemat raczej bezsensowny. Po stronie serwera coś musi żądanie przyjąć i przetworzyć. Albo serwer, albo PHP albo jeszcze coś innego. W takim wypadku przypomina to trochę mechanizm sesji zaprojektowany dla XMLa. Ale ogólnie to większej użyteczności nie ma, XML słabo sprawdza się jako wydajny magazyn danych tymczasowych.
Rid
Pisał PAn na mój post jak go edytowałem.
Cytat
Po stronie serwera coś musi żądanie przyjąć i przetworzyć.

Właśnie o to chodzi ,że żadne żądanie nie musi być wykonywane,dokument xml można stworzyć w JS link jest w moim poprzednim poście.
everth
Teraz mi się wyjaśniło smile.gif Chodzi o przygotowanie XMLa po stronie klienta? Da się. Ale nie łapię jak miałoby to zminimalizować liczbę żądań. Wszystko rozbija się pewnie o to:
Cytat
3.Wynik końcowy za pomocą Ajaxa przesyłamy do pliku xml zamiast np.z powrotem na stronę poprzez url.

w nawiązaniu do tego:
Cytat
Czyli bez przeładowania strony(po stronie klirnta) tworzymy, plik xml z jakimiś danymi,a potem pobieramy z tego dokumentu po stronie PHP interesujące nas dane

Nie ma możliwości bezpośredniego operowania na systemie plików (przynajmniej żaden zdrowy na umyśle admin na to nie zezwoli). Wszystkie żądania dla danego adresu przechodzą przez serwer (zazwyczaj Apache) który albo kieruje je do dalszego przetwarzania (CGI) albo serwuje je bezpośrednio. W tym wypadku prawdopodobnie treść XMLa przeszłaby przez PHP który gdzieś by ją zapisał. Oszczędza się na czasie potrzebnym na sformatowanie XMLa (ale można to podciągnąć pod moje zdanie o potrzebie intensywnej walidacji przed wysłaniem żądania, w tym wypadku jest podobnie) i tyle. Ja tu nie widzę żadnej oszczędności jeśli chodzi o liczbę żądań.

Cytat
A więc możliwa jest komunikacja klient-serwer,bez użycia Ajaxa i bez przeładowania strony?

Jeśli mówimy o czystych przeglądarkach (bez użycia wtyczek) to prawdopodobnie nie. Pozostają jeszcze WebSockety ale nigdy tego nie używałem więc się nie wypowiadam.
Rid
Mówi Pan że bez Ajaxa nie da rady,a jednak bez ajaxa usunąłem plik za pomocą JS-dam link z tego forum
Temat: Czy funkcja jest poprawna

A jakby za pomocą podobnej funkcji zamiast plik kasować to plik(przygotowany plik xml) tworzyćquestionmark.gif?Wtedy Ajax całkowicie odpada.

Jednak tak czy siak ,jak Pan mówił oszczędności niem bo request idzie,ale na 100% da rady to zrobić bez ajaxa i tylko za pomocą JS.

Ja ten sposób z code guru będę musiał wypróbować bo sam się zastanawiam i to grubo,czy warto.
zegarek84
Cytat(Rid @ 11.06.2011, 02:20:34 ) *
Mówi Pan że bez Ajaxa nie da rady,a jednak bez ajaxa usunąłem plik za pomocą JS-dam link z tego forum
Temat: Czy funkcja jest poprawna

może zacznę trochu z innej strony - nie musisz używać setTimeout - możesz spokojnie wykryć kiedy żądanie zostało spełnione w przypadku dynamicznego ładowania skryptów:
[JavaScript]Załączanie prototype poprzez js

następna kwestia to podobną technikę można zastosować przy pomocy innych elementów DOM np. arkusze styli, obrazki, iframe...

i dalej może co to AJAX - AJAX (ang. Asynchronous JavaScript and XML, asynchroniczny JavaScript i XML) - samo to pojęcie jest ogólne i raczej chodzi tylko o sposób komunikacji - podobne do Twojego sposobu i do AJAX'a jest JSONP

jak dla mnie nie ważne jak się komunikujesz z serwerem - ale jeśli to robisz asynchronicznie to łatwiej myśleć i mówić AJAX - i tego się będę trzymał ;p

To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.