« 1 2
Autor Zpráva
joe
Profil
_es:
Na tom som ti predsa odpovedal už v [#8]

Nemyslím... Jinak bysme si tu tak dlouho nepsali.

Tak prečo máš teda metódu GET v tom formulári?
Ve formuláři je proto, protože když bude JS vypnutý a formulář se odešle, URL BUDE vidět s odeslanými parametry. To ale v případě zapnutého JS přece není vůbec potřeba, protože URL se nemění. Nevidím důvod teda používat GET při XHR.

Mj. POST není nijak bezpečnější jak GET. Jen skrývá parametry z URL, nic víc.

Mně přijde, že se ti to snažím pořád vysvětlit a ty odpovídáš na úplně něco jiného. Tou poslední otázkou (#29) jsi to zazdil, protože z toho je patrné, že vůbec nevíš na co se ptám, jinak by tě to vůbec nenapadlo.

Já tu totiž píšu o nastavení metody (get/post) u objektu XHR, ne u tagu FORM v HTML, který se bude odesílat. Když je odešlu AJAXem, tak jejich odeslání zastavim, a odešlu je právě díky XHR, kam vždycky nastavim stejnou metodu, která je u toho tagu FORM. Ale právě to mi přijde zbytečný - zjiš'tovat tu metodu a nastavovat ji, když na všechno můžu použít při AJAXu POST.

BEZ AJAXu to už ale je třeba rozlišovat, záleží na tom, co chci nechávat v URL a co ne.


Mimochodom, keď už používaš formuláre, u ktorých aj návštevník bez JS očakáva funkčnosť, máš ošetrené, aby to bolo nejako rozumne funkčné aj bez JS?
Tohle není třeba řešit, dobrý framework to dělá bez mého velkého zásahu.

Tori:
Ač netázána přidám subjektivní názor
Odpovídat může přece každý, to že jsme tu propsali skoro celou noc je věc jiná :-)

1. Klasické odesílání - bez JavaScriptu

Potřebuji rozlišit a zvolit správnou metodu - POST / GET. V případě POST se parametry po odeslání neobjeví v URL (což je vhodné například při vkládání do DB nebo u nějakých složitých formulářů). V případě GET se parametry objeví (tzn. například vyhledávací políčko je dobré přes GET, abysme případně mohli někomu URL poslat a on se dostal na stejný výsledek)

2. Využití JavaScriptu - AJAX

Výhoda GET (viz 1. bod) je ta, že se zobrazí parametry v URL. Ale při odesílání AJAXem, tedy stornování defaultní akce odešlu XHR. Tzn. adresu nikdy v adresním řádku neuvidím. Takže nevidím důvod GET používat.

To logování jak uvádíte by mohl být jeden důvod... možná... proto se ptám, kdo tomu rozumí (a nezajímají mě nijaké další metody jak dělat AJAX)
_es
Profil
joe:
V případě GET se parametry objeví (tzn. například vyhledávací políčko je dobré přes GET, abysme případně mohli někomu URL poslat a on se dostal na stejný výsledek)
No ale ako sa ten niekto dostane k tej adrese, ak ten formulár s metódou GET aj tak neodošleš do celého okna, ale ho odošleš AJAXom a to metódou POST? Ak chceš tú adresu nejako sprístupniť aj bez normálneho odoslania, tak to je cez GET jednoduchšie, lebo treba aj tak reťazec adresy vytvárať a dá sa tá adresa jednoducho sprístupniť a to aj po odoslaní a prijatí výsledku - z objektu XHR a server má k dispozícii tú istú adresu.

Tohle není třeba řešit, dobrý framework to dělá bez mého velkého zásahu.
Aký a ako?

Ale při odesílání AJAXem, tedy stornování defaultní akce odešlu XHR. Tzn. adresu nikdy v adresním řádku neuvidím.
Že ju nevidíš v adresnom riadku, neznamená, že ju nemôžeš využiť inak, napríklad na strane servera, ako spomínala Tori, alebo aj na strane klienta pred alebo aj po odoslaní dát. Adresa pri normálnom odoslaní tiež nemusí byť vždy viditeľná.
DoubleThink
Profil *
TomášK:
Kdysi jsem zaslechl, že roboti vyyhledávačů zpravidla odesílají jen GET požadavky
Roboti zpravidla nezkoušejí odesílat jakékoliv formuláře.

_es:
Radíš používat iframe jako jakýsi remote objekt, ze kterého pak případně bude javascript získávat data? Za to bych ti u svého projektu urazil obě ruce.
Pokud je potřeba se serverem komunikovat asynchronně, používá se XMLHttpRequest - ideálně ve svém nativním formátu, tedy XML. Nevím, co se ti na tom pořád nelíbí. Kromě (mnohem) větší rychlosti je tu také lepší kontrola událostí, které při komunikaci vznikají.

joe:
GET nebo POST? Není to jedno? Nebo k čemu to vlastně je?
GET je součástí URI, jako url-encoded string. A URI má pochopitelně své limity. U standardně nastaveného Apache jsou to 4 kilobajty. Prohlížeče budou mít limity ještě menší - Explorer tuším 2 kilobajty.
POST má limit taky, ovšem poněkud velkorysejší - u Apache zpravidla omezený jen velikostí paměti, PHP pak standardně 8 megabajtů.
_es
Profil
DoubleThink:
používá se XMLHttpRequest - ideálně ve svém nativním formátu, tedy XML.
XML sa práve používa spolu s XHR veľmi málo, lebo je pre zpracovanie pomocou JS zbytočne zložitý a hrozia komplikácie. Používa sa hlavne JSON (získaný z obyčajného textu) alebo len obyčajný text.

Kromě (mnohem) větší rychlosti je tu také lepší kontrola událostí, které při komunikaci vznikají.
Napríklad JSONP, ktorého princíp je skoro rovnaký, je veľmi rýchly, takže z hľadiska rýchlosti to bude úplne opačne - ak sa to spraví správne. Ja som tu nikde neradil nepoužívať XHR, len ho nepoužívať namiesto normálneho odoslania formulárov - na to určený nie je.
Chamurappi
Profil
Reaguji na joa:
Rozdíly mezi GETem a POSTem jsou u XHR totožné jako u formulářů:
1) Fakt, že u GETu můžeš adresu vidět (snadno či nesnadno), jinými slovy znamená, že jde na dotyčný zdroj odkázat. Na výsledek POSTu odkázat nejde.
2) Explorer dovoluje jen 2 kB dlouhou adresu, Mozilla má limit tuším 64 kB, ale vždy tam nějaký limit je. Data zaslaná metodou POST limit nemají (alespoň na straně klienta).
3) Obecně platí, že POST by měl aktivně způsobit nějakou postřehnutelnou změnu, zatímco GET by měl jen pasivně vybírat obsah a uživatel by ho mohl vybrat tisíckrát po sobě, aniž by tím cokoliv změnil.
4) Při POSTu se cílová stránka nikdy nebere z keše. Pokud programátor (správně) vnímá keš jako přítele, ví, kdy zvolit GET.

Mj. POST není nijak bezpečnější jak GET. Jen skrývá parametry z URL, nic víc.
Ty parametry se díky tomu nekešují a neukládají se do logů a do externích statistik a neposílají se v refereru při odchodu na cizí stránku. Takže bezpečnější je. Při posílání skrze XHR část rizik u GETu odpadá, ale ne všechna.

Výhody použití AJAXu například v diskusi při posílání příspěvku
To je všechno v podstatě jen jedna výhoda a je platná pro jakékoliv zpracování formuláře JavaScriptem, nikoliv exkluzivně pro XMLHttpRequest. Nedávno jsem třeba v praxi použil 204 No Content — dojde-li k chybě, uživatel přejde na jinou stránku, v opačném případě zůstává na místě a o uzpůsobení zobrazení se postará JS, aniž by dostal od serveru nějaká data (pěkný český článek o tomto triku napsal DoubleThink, škoda, že už není k nalezení). Tento postup sice nejde použít vždycky, ale v tom mém konkrétním případě vidí návštěvník stejné výhody jako u tebe s AJAXem.

Odeslání AJAXem má jednu dosud nezmíněnou nevýhodu, která je pro některé uživatele docela podstatná: Pokud skriptem stornuješ nativní odeslání formuláře, znemožníš tím uložení vyplněných textových <input>ů do našeptávačové historie prohlížeče.

v tomto to jednodušší je, ale když to jQuery udělá za tebe, neřešíš nic (nebo když na to máš už funkci)
Ještě jsem neviděl žádnou funkci, která by dokázala formulář poslat skutečně za všech okolností stejně, jako kdyby ho odeslal prohlížeč. Pokud se bavíme o formulářích odesílaných na stejnou doménu na stránkách deklarujících výhradně kódování UTF-8, bez formulářových polí nazvaných action, method a podobně, bez formulářového pole __charset__ a bez uploadů souboru, bude metoda z jQuery nejspíš fungovat stejně jako prohlížeč. Netvrdím, že takových situací není většina, jen poukazuji, že občas nestačí neřešit nic.

do rámce musím načítat prakticky znovu celou stránku - HTML, HEAD, všechny skripty, které uvnitř použiju, BODY, samotný obsah, ...
Obalové značky jsou nepovinné a skripty můžou volat top.funkce() místo funkce(). Uznávám, že se skriptováním napříč rámy si občas programátor může užít mnohem víc zábavy, než by chtěl.

Protože kdybys to neudělal, bez JS by se ti asi pořád odesílal do nějakého rámce, nevím jak by to reagovalo, pokud by neexistoval. Může se to v každém prohlížeči chovat třeba jinak.
Nehrozí, ve všech prohlížečích by byly důsledky stejně nepříjemné. Atribut target by v případě použití skrytého rámce měl nastavit až JS, třeba v onsubmitu.

Po odeslání formuláře bys musel přidávat iframe do DOMu, řekl bych, že jeden ti stačit nebude, co když uděláš víc požadavků těsně za sebou - dostaneš jen ten poslední.
Což může být někdy účel. Řekl bych, že tu s _esem rozebíráte několik odlišných řešení, z nichž jsou různá různě vhodná pro různé situace. Osobně se v praxi snažím každý případ posuzovat individuálně. Někdy se hodí <iframe>, někdy XMLHttpRequest, někdy JSONP, někdy new Image(), někdy 204 No Content, někdy Comet, někdy dokonce behavior: url(#default#download). Zvážit všechna pro a proti a rozhodnout se pro optimální postup bývá složitější, než vybrat si mezi GETem a POSTem.


Reaguji na _es:
aký iný objekt, okrem formulárov, sa dá použiť na načítanie dát pomocou HTTP metódy GET?
Třeba <script> :-) (tady jsem se asi trochu ztratil v kontextu)
Škoda, že nejde JSONP použít s POSTem.

> > „Mimochodom, keď už používaš formuláre, u ktorých aj návštevník bez JS očakáva funkčnosť, máš ošetrené, aby to bolo nejako rozumne funkčné aj bez JS?“
„Tohle není třeba řešit, dobrý framework to dělá bez mého velkého zásahu.“
Aký a ako?
Tipnul bych si, že framework na straně serveru kouká na speciální HTTP hlavičku dodanou frameworkem na straně klienta a tomu přizpůsobuje odpověď.


Reaguji na TomášeK:
Kdysi jsem zaslechl, že roboti vyyhledávačů zpravidla odesílají jen GET požadavky, jestli je to pravda, nevím.
Dává to smysl, protože data, na která nejde odkázat z výsledků vyhledávání, nejsou pro provozovatele vyhledávačů zajímavá.
Witiko
Profil
joe:
Dodám, že POST a GET jsou rozdílné metody a v případě většiny serverových scriptů je nelze zaměnit. Vezmi v potaz například php. Proměnné zaslané pomocí POST jsou v poli $_POST[] a proměnné zaslané pomocí metody GET v poli $_GET[]. Při zaslání dat pomocí druhé metody pak bude serverový script pracovat, jako by nedošlo k odeslání dat žádných.

K vhodnosti použití - část konvencí (tzn. předávání parametrů stránky v adrese pomocí GET, aby bylo možné na stránku odkázat a citlivých dat jako heslo pomocí POST, aby na stránku s odeslaným heslem nebylo možné odkázat / heslo z odkazu přečíst apod.) je samozřejmě u AJAXu irelevantní. Zbytek však platí, tedy maximální délka dotazu - GET omezené a pak samozřejmě fakt, že požadavky klienta, které obsahují POST data, nelze cachovat. Na rozdíl od metody GET není při přenosu dat ovlivněno URL vyžádané webové stránky.

EDIT: Chamurappi tasil kolty první. No vzhledem k tomu jak dlouho se tu o tom joe hádá mu neuškodí přečíst si to dvakrát. :-)
joe
Profil
_es:
No ale ako sa ten niekto dostane k tej adrese, ak ten formulár s metódou GET aj tak neodošleš do celého okna, ale ho odošleš AJAXom a to metódou POST?
Po odeslání AJAXem nemůžu změnit adresu, to by mi ten AJAX byl k ničemu. Můžu jen změnit to, co je za #, jak se to zpravidla taky dělá. Tedy pokud odešlu normálně formulář GETem, v URL budu mít:

/uzivatel/?ageFrom=20&ageTo=30

a pokud to odešlu AJAXem (tzn. že na pozadí i klasický GET můžu odesílat POST požadavkem..., protože nevidím žádný dobrý důvod, proč volit GET, když se adresa v okně prohlížeče nemění), tak URL změním na

/uzivatel/#?ageFrom=20&ageTo=30

Aký a ako?
Nette, přes snippety. Pokud jsi to neviděl, tak nevíš o co přicházíš, protože tím ušetříš spoustu času.

Že ju nevidíš v adresnom riadku, neznamená, že ju nemôžeš využiť inak, napríklad na strane servera, ako spomínala Tori, alebo aj na strane klienta pred alebo aj po odoslaní dát. Adresa pri normálnom odoslaní tiež nemusí byť vždy viditeľná.
Jediné PRO vidím v tom logu, nic víc. V některých případech i v cache, jak píše Chamurappi později.

Nevím co bych s tou adresou měl dělat, můžu ji sklidem zahodit, protože mi k ničemu není.

DoubleThink:
To jsou vlastně ty body, na které jsem se neptal :-) a už jsem je tu i někde trochu zmiňoval. Nejde mi o skutečné rozdíly GET/POST, ale JEN při použití XHR, protože mně se k tomu nezdají stejné důvody, jako v případě odesílání bez JS.

Chamurappi:
Rozdíly mezi GETem a POSTem jsou u XHR totožné jako u formulářů:
No to se mi právě moc nezdá, proto jsem o tom napsal.

1)
Adresu vidíš, ale v případě odeslání přes AJAX se přece nemění. Vidíš ji tedy tak maximálně na logu serveru nebo ve FireBugu či něčem podobném.

2)
Ano, ale to přece není důvod, proč ten GET používat (při XHR)

3)
O tomhle se nebavím, nepatří to sem :-)

4)
Pravda, ale myslím, že obecně se novější data zobrazují na prvních pozicích (nejnovější uživatelé -> na první stránce). Takže při filtrování něčeho takového se moc kešovat nedá. A pokud ano, tak serverová keš, které je nejspíš jedno jestli je požadavek posílán přes GET nebo přes POST, protože kouká jen na parametry, které stejně přijdou oběma metodama.

Odeslání AJAXem má jednu dosud nezmíněnou nevýhodu, která je pro některé uživatele docela podstatná: Pokud skriptem stornuješ nativní odeslání formuláře, znemožníš tím uložení vyplněných textových <input>ů do našeptávačové historie prohlížeče.
Ukládám do cookies :-)

Nehrozí, ve všech prohlížečích by byly důsledky stejně nepříjemné.
Ok, nevěděl jsem jak se to zachová... rámce jsem už několik let nepoužil a myslím, že v nejbližší sobě ani nepoužiju.
Witiko
Profil
joe:
Ukládám do cookies :-)
Cookies nejsou určené k ukládání textových polí ani delších textů, už jen protože mají omezenou velikost. Hlavně je však jejich obsah odesílán při všech HTTP požadavcích serveru, což je s narůstajícím počtem "cookies" pak na době načítání stránek s množstvím obsahu poměrně znát.

1)... 2)... 3)... 4)...
Usuzuji, že můj post jsi nečetl. :-)
joe
Profil
Witiko:
Dodám, že
Kdyby každý takhle nedodával, v tomhle vláklně není tolik příspěvků a nemusel bych skoro celou předchozí stranu vysvětlovat, o co mi vlastně jde ;)

Zbytek však platí, tedy maximální délka dotazu - GET omezené a pak samozřejmě fakt, že požadavky klienta, které obsahují POST data, nelze cachovat. Na rozdíl od metody GET není při přenosu dat ovlivněno URL vyžádané webové stránky.
Na serveru lze cachovat obojí a metoda odeslání nehraje roli. Viz to co jsem psa[#7] (druhá strana).

EDIT: Chamurappi tasil kolty první. No vzhledem k tomu jak dlouho se tu o tom joe hádá mu neuškodí přečíst si to dvakrát. :-)
Já se tu o ničem nehádám, jen se tu snažím spíš neustále vysvětlit, o co mi jde.
joe
Profil
Witiko:
Cookies nejsou určené k ukládání textových polí ani delších textů, už jen protože mají omezenou velikost. Hlavně je však jejich obsah odesílán při všech HTTP požadavcích serveru, což je s narůstajícím počtem "cookies" pak na době načítání stránek s množstvím obsahu poměrně znát.
Zase zanášíš do tématu něco, co sem nepatří a z toho důvodu se tu pořád píše mimo téma. Já na to už fakt nemám.

Jistě, že nebudu do cookies ukládat hodnoty formuláře, který se má odeslat postem a obsahuje třeba nějaký dlouhý článek. Řeč je například o filtrovacím formuláři.

Usuzuji, že můj post jsi nečetl. :-)
Četl, ale nic moc jsem z něho nezískal ;-)
Witiko
Profil
protože kouká jen na parametry, které stejně přijdou oběma metodama.
V tom se mýlíš, cache má výslovně zakázáno rozebírat a porovnávat předchozí data odeslaná metodou POST. Data jsou vždy odeslána a přijata znova, jelikož správný programátor využívá metodu POST k provedení změn na straně serveru. Požadavek tedy vždy musí být odeslán. Mluvíme nyní o cache na straně klienta.

Řeč je například o filtrovacím formuláři.
Oprav mě pokud se mýlím, ale Chamurappi mluvil o našeptávačích. Pakliže budeš v cookies skladovat veškeré hodnoty, které input pole kdy mělo, pak nastanou problémy o kterých jsem psal.

Nemyslím, že sem zanáším něco, co sem nepatří. Pleteš se, pokud si myslíš, že jde pouze o tvé téma. Pakliže sem napíšeš, že odrovnávání našeptávačů řešíš pomocí cookies a nějaký nováček, který sem přijde, si to přečte, je problém na světě. :-)
joe
Profil
Witiko:
V tom se mýlíš, cache má výslovně zakázáno rozebírat a porovnávat předchozí data odeslaná metodou POST. Data jsou vždy odeslána a přijata znova, jelikož správný programátor využívá metodu POST k provedení změn na straně serveru. Požadavek tedy vždy musí být odeslán. Mluvíme nyní o cache na straně klienta.
Já ale psal o cachi na serveru.

Oprav mě pokud se mýlím, ale Chamurappi mluvil o našeptávačích. Pakliže budeš v cookies skladovat veškeré hodnoty, které input pole kdy mělo, pak nastanou problémy o kterých jsem psal.

Chamurappi:
do našeptávačové historie prohlížeče.

Máš pravdu, asi myslel přímo našeptávané pole. Já si pod tím v tu dobu představil předvyplnění formuláře. To asi žádný prohlížeč nedělá.
Nicméně hodnoty z takového pole je lepší ukládat na serveru, ať se každému nabídne i to, co hledali ostatní, ne?

Pleteš se, pokud si myslíš, že jde pouze o tvé téma.
Psát sem může kdo chce, co chce. Jen už mě pomalu přestává bavit vysvětlovat hromadou textů o co mi vlastně původně šlo ;-) A proto je tady hromada OT (viz první strana, kde _es už ve svém prvním příspěvku zde posílá něco, na co jsem se neptal)
_es
Profil
Chamurappi:
Reaguji na TomášeK:
„Kdysi jsem zaslechl, že roboti vyyhledávačů zpravidla odesílají jen GET požadavky, jestli je to pravda, nevím.“
Dává to smysl, protože data, na která nejde odkázat z výsledků vyhledávání, nejsou pro provozovatele vyhledávačů zajímavá.
No iná vec je, ako sa k tomu GET požiadavku vyhľadávač dostane. Ak bude závislý od vyplnenia, či kombinácií hodnôt rôznych formulárových polí, tak asi nehrozí, že by taký formulár vyhľadávač vyplňoval a odosielal. Pochybujem, že vyhľadávač vôbec nejaké formuláre odosiela a indexuje výsledok, no možno sa mýlim.

joe:
Nevím co bych s tou adresou měl dělat, můžu ji sklidem zahodit, protože mi k ničemu není.
Môžeš ju ponúknuť návštevníkovi ako odkaz na stránku, ktorý bude funkčný aj bez JS, ak teda tá adresa zodpovedá celej stránke.

joe:
Nejde mi o skutečné rozdíly GET/POST, ale JEN při použití XHR
Ale pri všetkých vysvetlených rozdieloch, kde si si pochvaľoval, že si bol konečne pochopený, ti boli vysvetlené práve tie „skutočné“ rozdiely, nezávislé od toho, ako dotaz GET alebo POST vznikol, teda rozdiely na úrovni HTTP protokolu.
joe
Profil
_es:
Môžeš ju ponúknuť návštevníkovi ako odkaz na stránku, ktorý bude funkčný aj bez JS, ak teda tá adresa zodpovedá celej stránke.

To je ale asi tak jediné dobré, co s ní můžeš udělat. Ale popravdě, už jsi to někde viděl, a že by to někdo používal? Myslím, že kdo si chce uložit stránku, ten zkopíruje to, co má v adresním řádku.

Jediný rozumný důvod, proč to při XHR posílat stejnou metodou jako je uvedena u formuláře, je způsob čtení na serveru. Jinak by se vždy dal použít POST (pokud vynechám ty některé další již zmíněné důvody). Ale to je možné v PHP i přes $_REQUEST.
_es
Profil
joe:
Myslím, že kdo si chce uložit stránku, ten zkopíruje to, co má v adresním řádku.
No ale tak si predsa v tvojom prípade skopíruje len odkaz na úvodnú stránku, nie odkaz na ekvivalent zobrazenej stránky.

už jsi to někde viděl, a že by to někdo používal?
Napríklad Google mapy.
Witiko
Profil
joe:
Nicméně hodnoty z takového pole je lepší ukládat na serveru, ať se každému nabídne i to, co hledali ostatní, ne?
Dozajista. Jak ale v takovém případě zapojit do práce cookies jde mimo mě. :-)

Jediný rozumný důvod, proč to při XHR posílat stejnou metodou jako je uvedena u formuláře, je způsob čtení na serveru.
Bylo už tu mnohokrát řečeno, že prohlížeč vůbec nemusí v případě žádosti GET odesílat žádost serveru ale využít data z catche. Máš naprostou pravdu, že tzv. "GET data" v adrese se dají skrýt do hashe a následné načítání dat ze serveru pomocí XHR může být provedeno jak pomocí GET tak POST, PUT, co je lepší volbou bys tedy měl zvažovat na úrovni protokolu, ne adresy, kterou uživatel vidí v prohlížeči. Viz. http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
joe
Profil
Witiko:
Cookies jsem myslel pro filtrační formulář... Aby při dalším navštívení stránky měl formulář již vyplněný.

O cache jsem psal. Pokud na první straně chceš zobrazit nejnovější data, k čemu ti pak asi bude cache? To je to samé, jako kdybys mi napsal, že děláš jeden chat s AJAXem a ukládáš ho do cache, to by toho lidi moc nenachatovali :-)
joe
Profil
_es:
No ale tak si predsa v tvojom prípade skopíruje len odkaz na úvodnú stránku, nie odkaz na ekvivalent zobrazenej stránky.
Vždyť jsem psal, že v případě AJAXu se to dává za # v URL. Nastavuje se tedy v JS hashString, právě z toho důvodu, aby se adresa dala zkopírovat. ([#7] joe - všimni si té zvýrazněné mřížky)

Napríklad Google mapy.
Koukám, tak to se mi teda vůbec nelíbí co s tím provedli. Pokud se nepletu, bylo to jako na Seznamu, kde se právě hned mění ta adresa a odpadá nutnost hledání "Odkaz"u.
Chamurappi
Profil
Reaguji na joa:
Já si pod tím v tu dobu představil předvyplnění formuláře. To asi žádný prohlížeč nedělá.
No vidíš, to mě nenapadlo, že nativní našeptávače souvisejí i s převyplňováním zapamatovaných políček. Pokud skriptem stornuješ odeslání údajů, jak se prohlížeč dozví, že by se měl zeptat, jestli si je má zapamatovat?

Nicméně hodnoty z takového pole je lepší ukládat na serveru, ať se každému nabídne i to, co hledali ostatní, ne?
My se bavíme jen o hledání? Co když chci, aby si to zapamatovalo telefon, abych ho nemusel na jiné stránce s name="telefon" vypisovat?
To je pořád ta samá zúžená perspektiva, představuješ si vždy pouze jedno své konkrétní použití. Ve stejném duchu se táhne celé vlákno — ptáš se obecně, dostáváš obecné odpovědi a každému pak vynadáš, protože ta ultimátní pravda „AJAX POST je boží!“ není v řadě situací ani ultimátní, ani pravda :-)

Pokud na první straně chceš zobrazit nejnovější data, k čemu ti pak asi bude cache?
My se bavíme jen o první straně s nejnovějšími daty? Jasně, že někdy je kešování nežádoucí (to tu kupodivu všichni dobře víme). Tam, kde nežádoucí není, se rozhodně hodí metoda GET.

„3) Obecně platí, že POST by měl aktivně způsobit nějakou postřehnutelnou změnu…“
O tomhle se nebavím, nepatří to sem :-)
Patří, protože z této zvyklosti mohou vyplývat další drobné nuance. Lze třeba předpokládat, že data zaslaná metodou POST jsou cennější — a myslím, že tento předpoklad je zanesený v hloubi digitální duše serverů. Možná je to jen můj dojem, ale řekl bych, že při přetížení tato diskuse zahazuje GETy mnohem ochotněji než POSTy — pokud v krizovém období jen listuji, dostávám okamžitě hlášku o přetížení, kdežto pokud pošlu příspěvek, server se minutu potí a pak mi vítězně pošle stránku bez stylů i obrázků. Dává to trochu smysl, ne? Kdybys programoval webový server, neuvažoval bys podobně? Nevěnoval bys POSTům větší péči než GETům?

Jakou že máš vlastně motivaci k tomu, abys GET a POST nerozlišoval? Stačí jen dosadit jeden řetězec na jedno místo, ne?
_es
Profil
joe:
v případě AJAXu se to dává za # v URL. Nastavuje se tedy v JS hashString, právě z toho důvodu, aby se adresa dala zkopírovat.
No ale časť v URL za # sa serveru neposiela, takže bez zapnutého JS to bude na nič. Môžeš si sám vyskúšať, že odkaz Seznamu je bez JS nefunkčný a odkaz Google funkčný. Aj pri zapnutom JS je načítanie takého odkazu-neodkazu zložitejšie, musí JS modifikovať už načítanú (načítavanú) stránku.
joe
Profil
_es:
Vím o tom, to mi nemusíš psát :) Ale kdo dnes má vypnutý JavaScript. Asi těžko někdo bude používat aplikaci bez JavaScriptu, protože to ani nebude možné.

Chamurappi:
jak se prohlížeč dozví, že by se měl zeptat, jestli si je má zapamatovat?
Nijak, je to celkem jedno, pokud si to pamatuje prohlížeč nebo cookies. Cookies mají tu (ne)výhodu, že se dají odstranit, kolikrát mě u nějakých formulářů spíš štve, že se ptají na zapamatování...

My se bavíme jen o hledání?
Ne, teď se bavíme mimo téma :-)

Co když chci, aby si to zapamatovalo telefon...
Proč nezvolit cookies?

Vůbec neříkám, že AJAX POST je boží nebo něco takového, ani to nikde jako náhradu za GET nepoužívám. Byla to taková myšlenka, proč to vlastně rozlišovat.

My se bavíme jen o první straně s nejnovějšími daty?
Nejen o první. Když máš na první straně nová data, tak nemůžeš cachovat ani žádnou jinou stranu, protože položky jsou "v pohybu".

Dává to trochu smysl, ne? Kdybys programoval webový server, neuvažoval bys podobně? Nevěnoval bys POSTům větší péči než GETům?
Asi dává, ale jinak bych nikdy žádný takový server neprogramoval :-) od toho jsou tu jiní. Já dávám od programování ruce pryč, je to nezáživná práce :-)

Jakou že máš vlastně motivaci k tomu, abys GET a POST nerozlišoval? Stačí jen dosadit jeden řetězec na jedno místo, ne?
Stačí, nikde to nepoužívám, jenom mě to tak napadlo. Právě z toho důvodu, že při XHR se nemění adresa, tak mi přišlo zbytečné to rozlišovat.
Suta
Profil
joe:
Požadavky POST kladou větší nároky na zpracování než požadavky GET. Co se výkonnosti týče, mohou být požadavky GET až dvakrát rychlejší než požadavky POST odesílající stejné množství dat.

Tím neříkám, že místo požadavků POST používat vždy požadavky GET, samozřejmě záleží na objemu dat, která ještě metoda GET bezpečně zvládne, nebo co už je třeba odeslat prostřednictvím metody POST.
joe
Profil
Suta:
Tak o tom výkonu jsem nevěděl, díky za informaci.


Děkuji všem za odpovědi, a i když některé nebyly takové, jaké jsem přímo chtěl, nevadí, i ty mi byly prospěšné.
« 1 2

Vaše odpověď

Mohlo by se hodit

Neumíte-li správně určit příčinu chyby, vkládejte odkazy na živé ukázky.
Užíváte-li nějakou cizí knihovnu, ukažte odpovídajícím, kde jste ji vzali.

Užitečné odkazy:

Odkud se sem odkazuje


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm: