HTML: Form Refresh

[Guest future_funk_squad]

nu tipa ir viesigraamata, ierakstam text laukaa niku, spiezham submit

taalaak ar shito kodu notiek viss ko vaig izdariit

 

if (isset($HTTP_POST_VARS[xxx]))

{

[kods]

unset($HTTP_POST_VARS[xxx]);

}

 

peec tam nospiezham browserii refresh, bet tas kods izpildaas veelreiz, un taa liidz bezgaliibai, kamer spaidi refresh

es tachu izdzeesu mainiigo xxx ar unset($HTTP_POST_VARS[xxx]);

kaapeec tas taa notiek?? un kaa to noveerst?

[Vilx-]

Hehe. Veel viens, kursh nesaprot, ko noziimee server-side scripting un client-side scripting!

 

Redzi, PHP kods tiek izpildiits uz servera. PHP koda rezultaatu (peec izpildes beigaam) nosuuta klientam. Tad klients uz sava kompja aizpilda formu, un nospiezj submit. Tad visi dati par formu tiek nosuutiti atpakalj uz serveri. Serveris to apstraadaa (t.i. tiek izpildiits Tavs PHP kods atkal), un rezultaatu atkal aizsuuta klientam. Ja klients nospiezj Refresh, tad dati par formu tiek nosuutiiti veelreiz. Refresh prncipaa ir peedeejaa pieprasiijuma atkaartota nosuutiishana.

 

Tas, ka Tu uz sava servera pateici unset(), neko nenoziimee. Tas tikai noziimee, ka PHP kodaa Tev vairaak shis mainiigais nebuus pieejams.

 

Starp citu - labaak izmanto $_GET[] un $_POST[]. HTTP_xxx_VARS[] ir novecojusi sheema, kas driiz tiks pavisam izskausta.

[Guest future_funk_squad]

Hehe. Veel viens, kursh nesaprot, ko noziimee server-side scripting un client-side scripting!

 

Redzi, PHP kods tiek izpildiits uz servera. PHP koda rezultaatu (peec izpildes beigaam) nosuuta klientam. Tad klients uz sava kompja aizpilda formu, un nospiezj submit. Tad visi dati par formu tiek nosuutiti atpakalj uz serveri. Serveris to apstraadaa (t.i. tiek izpildiits Tavs PHP kods atkal), un rezultaatu atkal aizsuuta klientam. Ja klients nospiezj Refresh, tad dati par formu tiek nosuutiiti veelreiz. Refresh prncipaa ir peedeejaa pieprasiijuma atkaartota nosuutiishana.

 

Tas, ka Tu uz sava servera pateici unset(), neko nenoziimee. Tas tikai noziimee, ka PHP kodaa Tev vairaak shis mainiigais nebuus pieejams.

 

Starp citu - labaak izmanto $_GET[] un $_POST[]. HTTP_xxx_VARS[] ir novecojusi sheema, kas driiz tiks pavisam izskausta.

 

es saprotu, ko noziimee server side un bla bla bla, tikai nebiju pie taa piedomaajis:) nu skaidrs

 

bet tad vai kaut kaa ar javascriptu vareetu izdzeest tos formas datus?

[Vilx-]

Diezvai.

 

Principaa, Tev ir 2 risinaajumi:

 

1. Tuuliiteejs redirekts. Liidziigi kaa shajaa forumaa, peec nopostoshanas Tev uzreiz neparaada rezultaatu, bet liek iet veel 1 lapu taalaak. Ja Tu to refreshosi, tad jau dati otrreiz nepostosies.

 

2. Sleepts unikaals ID, kuru Tu padod liidzi ar postu, un kurhs peecaak uz servera tiek pieregjistreets kaadaa datubaazee. Otrreiz submitojot datus ar ID, kursh jau ir datubaazee, submits tiek ignoreets un lapa tiek vienkaarshi refreshota.

[hmnc]

redirekts tevi glābs.

 

tiklīdz kā tiek pievienots ieraksts un pirms visiem citiem outputiem liec: Header ('Location: viesgraamata.php');

[Guest future_funk_squad]

2. Sleepts unikaals ID, kuru Tu padod liidzi ar postu, un kurhs peecaak uz servera tiek pieregjistreets kaadaa datubaazee. Otrreiz submitojot datus ar ID, kursh jau ir datubaazee, submits tiek ignoreets un lapa tiek vienkaarshi refreshota.

 

man patika shitais variantinsh

[Vilx-]

Es arii parasti dodu priekshroku 2. variantam. Pirmais tomeer var reizeem nogljukot, juuzeris var back saspaidiit utt.. Otrais ir droshs [sex].

[hmnc]

2. Sleepts unikaals ID, kuru Tu padod liidzi ar postu, un kurhs peecaak uz servera tiek pieregjistreets kaadaa datubaazee. Otrreiz submitojot datus ar ID, kursh jau ir datubaazee, submits tiek ignoreets un lapa tiek vienkaarshi refreshota.

 

man patika shitais variantinsh

 

ui ui ui. nu nevajag taisīt no velosipēda atombumbu. šitais variants ir galīgi līks. tas papildus ID ir kā bumbai rokturis.

header reload nekad un nekādos apstākļos nav gļukojis. un tas ir visprimitīvākais variants. iemet tikai vienu rindiņu koda un gotovo! ja spiedīs back tad redzēs aizpildītu formu - kāda h* pēc būtu vēlreiz jāspiež submit? var jau arī uztaisīt "clear form on body load", bet nu cik es header() esmu izmantojis - nekādu problēmu.

 

P.S.

arī šis forums izmanto header() joku.

un nav obligāti likt redirektu uz kaut kādu lapu tjip "paldies par komentāru". var likt vienkārši uz jau galveno. un miers.

[japets]

Tas nav liiks variants, tas nav bumbai rokturis. Tas ir pavisam normaals risinaajums, protams normaalaa realizaacijaa. Tobish uz formu padod tabulas sequences nextid. Taa kaa normaalaa DB struktuuraa id buus unique, tad fiziski divus vienaadus ierakstus nevarees ievietot. Vieniigais truukums ir papildus viens pieprasiijums uz DB, ja grib cilveeciigaa veidaa nevis gaidot exception nochekot, vai ieraksts jau eksistee ieksh DB.

Savkaart ar redirect tik tieshaam var rasties probleemas dazhaados browseros spaidot back.

 

ui ui ui. nu nevajag taisīt no velosipēda atombumbu. šitais variants ir galīgi līks. tas papildus ID ir kā bumbai rokturis.  

header reload nekad un nekādos apstākļos nav gļukojis. un tas ir visprimitīvākais variants. iemet tikai vienu rindiņu koda un gotovo! ja spiedīs back tad redzēs aizpildītu formu - kāda h* pēc būtu vēlreiz jāspiež submit? var jau arī uztaisīt "clear form on body load", bet nu cik es header() esmu izmantojis - nekādu problēmu.

 

P.S.

arī šis forums izmanto header() joku.

un nav obligāti likt redirektu uz kaut kādu lapu tjip "paldies par komentāru". var likt vienkārši uz jau galveno. un miers.

[hmnc]

Tas nav liiks variants, tas nav bumbai rokturis. Tas ir pavisam normaals risinaajums, protams normaalaa realizaacijaa. Tobish uz formu padod tabulas sequences nextid. Taa kaa normaalaa DB struktuuraa id buus unique, tad fiziski divus vienaadus ierakstus nevarees ievietot. Vieniigais truukums ir papildus viens pieprasiijums uz DB, ja grib cilveeciigaa veidaa nevis gaidot exception nochekot, vai ieraksts jau eksistee ieksh DB.

Savkaart ar redirect tik tieshaam var rasties probleemas dazhaados browseros spaidot back.

 

Šis risinājums varētu būt kādos lielmēroga projektos nevis sūda viesugrāmatā. Pie tam - slēptos ID un principā visus mainīgos, kuri padoti caur browseri, lietotajs var feikot. so kāda jēga?

+ lieki pieprasījumi un čakars.

salīdzini realizācijas:

1) ar headeriem - padod redirektu ar vienu rindiņu un tev viss strādā praktiski ideāli

2) ar uniqueid - jāpadod atsevišķs id caur html (papildus html kods), jātaisa pārbaudes uz uID vai tas sakrīt vai nē. aizņem vairāk laika + skripta excekuucijas laiks + jāraksta klāt n-tās rindas koda. un vienalga - ja cilvēks uzspiedīs F5(refresh) viņam izlīdīs tas tizlais paziņojums un viņš kritīs panikā. un vienalga tu nonāksi pie redirekta izmantošanas. un kā jau minēju - jo mazāk datu no lietotāja jo labāk. jo neatkarīgākus var taisīt pielikumus.

 

ok ja nepatīk redirekti paņem kaut vai elementāro salīdzināšanu - ja vārds un teksts jau eksistē datubāzē tad nepievieno (piemēram stundas laikā). nu un vienalga būs problēmas ar back pogu un paziņojumu un kur mēs atkal nonākam pie redirektia.

bet atkal būs problēmas ar back pogu, so

[Vilx-]

Patiesiibaa, ja padod to atseviskjo ID, tad tiek tiek izskaustas visas probleemas ar Back pogu! Veelreiz submitojot viesugraamatas ierakstu ar to pashu ID, lapas iztureeshanaas buus taada pati, it kaa veelreiz nosubmitojot, tikai reaali netiks pievienots ieraksts datubaazee. Nevajag jau arii nekaadus kljuudu pazinojumus.

 

Nu, anyhow - kaa uztaisiisi, taa arii buus. Shis ir visdroshaakais risinaajums, kas peecaak uzliek vismazaak ierobezojumus.

[japets]

Nu ja reiz gribi pastriideeties, tad ok..

1. Neviens nerunaa par to, ka useris var suutiit fake piepariijumus, topic meerkjis nebij uzzinaat, kaa apstraadaat tos..

2. Nevis "lieki pieprasiijumi un chakars", bet viens selekts un paarbaude (if)

3. Nevis "ntaas liekas rindinjas", bet ljaushos mineet - aptuveni 3, lai padotu hidden fieldu, aptuveni 2, lai paarbaudiitu pie submita, vai ieraksts jau submitots (atkariigs no vides, kuraa tas tiek veikts, kaa arii paareejaas koda organizaacijas)

4. Tavs piedaavaatais otrais variants (saliidzinaat nosaukuma un teksta laukus) neatshkjiras no paarbaudes peec padotaa id, tikai nevajadziigi daudzkaart vairaak noslogos datubaazi (tiem, kas tankaa - stringu saliidzinaashana notiek DAUDZ leenaak, nekaa numeric mainiigo

5. Viens selekts pavisam noteikti tiks izpildiits aatraak nekaa redirect (to domaajams nav jaapieraada .

6. Kaa noskaidrojaam, tad back pogas arguments atkriit, jo meedz raadiit pazinjojumus abos gadiijumos atkariibaa no browsera.

 

Kaut kaa taa.

 

Tas nav liiks variants, tas nav bumbai rokturis. Tas ir pavisam normaals risinaajums, protams normaalaa realizaacijaa. Tobish uz formu padod tabulas sequences nextid. Taa kaa normaalaa DB struktuuraa id buus unique, tad fiziski divus vienaadus ierakstus nevarees ievietot. Vieniigais truukums ir papildus viens pieprasiijums uz DB, ja grib cilveeciigaa veidaa nevis gaidot exception nochekot, vai ieraksts jau eksistee ieksh DB.

Savkaart ar redirect tik tieshaam var rasties probleemas dazhaados browseros spaidot back.

 

Šis risinājums varētu būt kādos lielmēroga projektos nevis sūda viesugrāmatā. Pie tam - slēptos ID un principā visus mainīgos, kuri padoti caur browseri, lietotajs var feikot. so kāda jēga?

+ lieki pieprasījumi un čakars.

salīdzini realizācijas:

1) ar headeriem - padod redirektu ar vienu rindiņu un tev viss strādā praktiski ideāli

2) ar uniqueid - jāpadod atsevišķs id caur html (papildus html kods), jātaisa pārbaudes uz uID vai tas sakrīt vai nē. aizņem vairāk laika + skripta excekuucijas laiks + jāraksta klāt n-tās rindas koda. un vienalga - ja cilvēks uzspiedīs F5(refresh) viņam izlīdīs tas tizlais paziņojums un viņš kritīs panikā. un vienalga tu nonāksi pie redirekta izmantošanas. un kā jau minēju - jo mazāk datu no lietotāja jo labāk. jo neatkarīgākus var taisīt pielikumus.

 

ok ja nepatīk redirekti paņem kaut vai elementāro salīdzināšanu - ja vārds un teksts jau eksistē datubāzē tad nepievieno (piemēram stundas laikā). nu un vienalga būs problēmas ar back pogu un paziņojumu un kur mēs atkal nonākam pie redirektia.

bet atkal būs problēmas ar back pogu, so

[hmnc]

1. vienmēr ir jāapsver visi varianti

2. Un kam vajag vienu lieku selectu prastā guestbookaa?

3. hidden fieldu var padot ar vienu rindiņu. kur tev tur trīs es nezinu. un tad 2 taisot vienu bezjēdzīgu selectu (īstenībā pat ar vienu var izbraukt, ja lieto classi)

4. vot - uzliec uz savas kastes serveri un salīdzini no 50 querijiem vidējo laiku cik aizņem string search un numeric search. Where clause ir viens un tas pats. varu derēt, ka laiki atšķirsies ne vairāk kā par vienu tūkstošo līdz miljono daļu sekundes. atkarībā no kastes protams. bet viena tūkstošā daļa sekundes jau ir ļoti daudz ne..

5. 1 sekundē nenomirsi gan jau.

6. Nope. PHP ir serverside scripting līdz ar to jaunais headeris vienkārši tiek iebāzts browserim nāsīs kā nākamā lapa. un spiežot back atgriezīsies pie aizpildītas formas.

un es ļoti ceru, ka tu parādīsi man, kuram browserim ir problēmas ar formas pēcievades header redirektu.

[japets]

Protams, ja runaajam par guestbook, tad risinaajums var buut dajebkaads, ka tik straadaa.

Ja runaajam vispaariigi, tad unikaala key padoshana formai nav tas sliktaakais variants, un manupraat tas ir pat labaaks par redirect. btw, man vislaik shkjita, ka nosuutot redirect headeri browseris pac izlemj, ko dariit taalaak - sekot tam taisot jaunu pieprasiijumu, vai nee... Un ja veelies zinaat browseri, kursh tik tieshaam atsakaas no redirectiem - lynx...

 

Aiz, zb tomeer shii diskusija, vieniigais, ko gribeeju pateikt - nevajg nolikt tik ljoti risinaajumu ar kaut kaada key padoshanu uz formu!

 

1. vienmēr ir jāapsver visi varianti

2. Un kam vajag vienu lieku selectu prastā guestbookaa?

3. hidden fieldu var padot ar vienu rindiņu. kur tev tur trīs es nezinu. un tad 2 taisot vienu bezjēdzīgu selectu (īstenībā pat ar vienu var izbraukt, ja lieto classi)

4.  vot - uzliec uz savas kastes serveri un salīdzini no 50 querijiem vidējo laiku cik aizņem string search un numeric search. Where clause ir viens un tas pats. varu derēt, ka laiki atšķirsies ne vairāk kā par vienu tūkstošo līdz miljono daļu sekundes. atkarībā no kastes protams. bet viena tūkstošā daļa sekundes jau ir ļoti daudz ne..

5. 1 sekundē nenomirsi gan jau.

6. Nope. PHP ir serverside scripting līdz ar to jaunais headeris vienkārši tiek iebāzts browserim nāsīs kā nākamā lapa. un spiežot back atgriezīsies pie aizpildītas formas.

un es ļoti ceru, ka tu parādīsi man, kuram browserim ir problēmas ar formas pēcievades header redirektu.

[japets]

btw, attieciibaa uz Tavu 1. pretargumentu - ja tiek prasiits, kaa kastreet kakjenes, tad nevajag atbildeet, kaa maaksliigi apaugljot kuces! Viens bijushais pasniedzeejs teiktu - "funkcionaalais analfabeetisms"...

 

1. vienmēr ir jāapsver visi varianti

2. Un kam vajag vienu lieku selectu prastā guestbookaa?

3. hidden fieldu var padot ar vienu rindiņu. kur tev tur trīs es nezinu. un tad 2 taisot vienu bezjēdzīgu selectu (īstenībā pat ar vienu var izbraukt, ja lieto classi)

4.  vot - uzliec uz savas kastes serveri un salīdzini no 50 querijiem vidējo laiku cik aizņem string search un numeric search. Where clause ir viens un tas pats. varu derēt, ka laiki atšķirsies ne vairāk kā par vienu tūkstošo līdz miljono daļu sekundes. atkarībā no kastes protams. bet viena tūkstošā daļa sekundes jau ir ļoti daudz ne..

5. 1 sekundē nenomirsi gan jau.

6. Nope. PHP ir serverside scripting līdz ar to jaunais headeris vienkārši tiek iebāzts browserim nāsīs kā nākamā lapa. un spiežot back atgriezīsies pie aizpildītas formas.

un es ļoti ceru, ka tu parādīsi man, kuram browserim ir problēmas ar formas pēcievades header redirektu.

[hmnc]

btw, attieciibaa uz Tavu 1. pretargumentu - ja tiek prasiits, kaa kastreet kakjenes, tad nevajag atbildeet, kaa maaksliigi apaugljot kuces! Viens bijushais pasniedzeejs teiktu - "funkcionaalais analfabeetisms"...

 

es jau variantus neaplieku - es tikai izsaku savas domas, ka redirektu variants viesugrāmatā būtu vislabākais un viselementārākais risinājums.

 

nevajag jaukt kuces ar PHP. tipat labi var uzlikt query $_GET['login']; un gaidīt kad tev uztaisīs mysql injection. dažādas lietas tomēr. bet mana pieredze gadu gaitā ar PHP rāda - jo mazāk skripts ir atkarīgs no, no lietotāja padotajiem mainīgajiem, jo labāk.

 

un kāpēc gan lynx nesuportētu redirektu? iekāp kaut vai šepat forumā un ieposto kaut ko. ta jau manīs vai nestrādās, bet esmu pārliecināts, ka strādās.

[Guest future_funk_squad]

piebildiishu, ka runa neiet tikai un vieniigi par guestbooku, bet vispaar par shaada veida probleemu

 

nu vareeju jau iesaakt sarunu: "man ir nevis parasts guestbooks, bet liela meeroga projekts"

 

tas, ka sql pieprasiijums nostraadaas daudz aatraak nekaa redirekts, tur es piekriitu, kaadelj vareetu izmantot sho variantu

[hmnc]

piebildiishu, ka runa neiet tikai un vieniigi par guestbooku, bet vispaar par shaada veida probleemu

 

nu vareeju jau iesaakt sarunu: "man ir nevis parasts guestbooks, bet liela meeroga projekts"

 

tas, ka sql pieprasiijums nostraadaas daudz aatraak nekaa redirekts, tur es piekriitu, kaadelj vareetu izmantot sho variantu

 

saproti - nekas nav universāls. arī šie divi piemēri. un kā vēsta leģenda - kas der visam, tas neder nekam. un gan jau nākotnē sapratīsi, ka jo mazāk SQL pieprasījumu, jo labāk.

un kā jau teicu - šis sql risinājums neatrisina to variantu, kad parādās tizlais warnings par to, ka lietotājs spaida back.

[Guest future_funk_squad]

es to ljoti labi saprotu!

[Guest lameris]

Cik aatrumaa paarlasiju sho topiku tad sapratu ka spieshot login tev atkal un atkal posteejaas vecie dati. Lai atbriivoties no veciem postdatiem lieto header('Location: lapa.php'); Tas pats redirekts jau ir Var jau rakstiit arii ar scriptu <script>pirnt("<a href="lapa.php">")</script> vai kaut kas liidziigi. iisti neatceros. Header gadiijumaa tev taa rindinja jaaraksta pirms visiem print vai echo nu principaa pirms tad kur jebkas tiek izvadiits uz browzera