ugrás a tartalomhoz

Ne lehessen frissíteni egy adott oldalt! Lehetséges?

haho · 2009. Május. 25. (H), 06.01
Az a problémám - és nem is igazán tudom hova sorolni - megoldható-e az, hogy egy adott oldalt a böngészők frissítés gombjával ne lehessen frissíteni vagy, hogy legalábbis a frissítés után ne akarja újra elküldeni az űrlapot.
Tehát van nekem pl. egy php-s üzenetküldő űrlapom és a felhasználók elküldik az üzenetet, majd egyesek nem tudom miért frissítik az oldalt, így ugyanazt az üzenetet többször is megkapom. Milyen megoldások léteznek erre?

Előre is köszönöm, nagyon fontos lenne!
‹ Karakterkódolási probléma Üdvözlőképernyő nem jelenik meg ›
 ■
1

Persze

janoszen · 2009. Május. 25. (H), 06.36
Persze. A megoldást úgy hívják: Get After Post. Avagy kiküldesz egy location headert azon az oldalon, ahova postolsz, hogy átdobja a felhasználót egy másik oldalra, amit kedvére frissíthet. Bónuszként még a back gombot is működőképessé teszi. Innentől gugli. :)
2

Egyszerű vizsgálat

bonga · 2009. Május. 25. (H), 09.00
De a post mentése előtt egy egyszerű lekérdezéssel is ellenőrizheted, hogy adott user adott témához az elmúlt mondjuk fél órában ugyanezt a hozzászólást post-olta-e. Ha igen, duplikálásra hivatkozva visszadobod neki, hogy bocs öreg, de ez már kinn van a post-ok között.
Btw próbáltad már duplán post-olni a hozzászólásodat a weblaborra? Valami hasonló lehet a védelem itt is. :)
4

próbáld ki máskor

gex · 2009. Május. 25. (H), 09.37
simán előfordulnak duplák, semmiféle dupla posztolás nincs itt kivédve.
5

próbáld ki máskor

gex · 2009. Május. 25. (H), 09.37
simán előfordulnak duplák, semmiféle dupla posztolás nincs itt kivédve.
3

Előtte az ellenőrzés szimpatikusabb!

haho · 2009. Május. 25. (H), 09.07
Igen, valóban az ellenőrzés a szimpatikusabb megoldás. Az egyik űrlapomnál már meg is oldottam.
Mindenesetre proclub megoldásának is utána néztem és feljegyeztem magamnak a használt script és megoldás gyűjtimbe.
Köszi
6

viszont a másik egyszerűbb

gex · 2009. Május. 25. (H), 09.40
amit proclub írt az A Megoldás minden űrlapokat használó oldal esetében. az duplázás ellenőrzése felesleges bonyolítás az egyetlen header kiadásához képest. mindent csinálj úgy ahogy van, csak az adatbázisba írás után add ki a "Location: ..." fejlécet. ennyi és nem több.
7

Ez nem opcionális, amit

Fraki · 2009. Május. 25. (H), 13.50
Ez nem opcionális, amit proclub írt, az kell neked, nem duplikátum-ellenőrzés. (Ilyenkor hiányzik a comment rating.) Ráadásul ha nem irányítasz át, akkor a böngésző még mindig rákérdez, hogy újraposztolja-e az űrlapot.

És átirányíthatsz ugyanarra (a posztolt) oldalra is, a lényeg, hogy legyen átirányítás.
8

Ne!

janoszen · 2009. Május. 25. (H), 19.06
Erőteljesen javaslom, hogy legyen külön URLje a mentésnek, ugyanis a saját URLre átirányításkor változatosabbnál változatosabb böngészőbugok jönnek elő. (Ezt anno a RoR próbálkozásaimnál tapasztaltam.)
9

konkrétum?

gex · 2009. Május. 25. (H), 19.33
nem nagyon tapasztaltam még ilyet. én legalábbis.
10

Passzolom

janoszen · 2009. Május. 25. (H), 21.30
Nem tudom fejből megmondani, hogy mi volt a bajom, egy éve legalább volt. Valami olyasmi volt, hogy ha egy URLen levő formból önmagára POSToltam, majd megint csak önmagára nyomtam egy redirectet, akkor a back gomb használatával előjött az ominózus kérdés, hogy biztosan újratöltse-e. Ki kellene próbálni, hogy melyik böngészővel él a bug, ha él. Viszont külön URLt dedikálni neki nem kerül semmibe.
11

tehát semmi konkrét

gex · 2009. Május. 25. (H), 21.41
amíg nem jön valami konkrétum ez ügyben egy kis fenntartással kezelem a "változatosabbnál változatosabb böngészőbugok jönnek elő" kijelentésed.

Viszont külön URLt dedikálni neki nem kerül semmibe.
a semminél is kevesebbe kerül nem dedikálni egy külön url-t. ;)
12

PoC

janoszen · 2009. Május. 25. (H), 22.03
Na, kiteszteltem. Ahogy elnézem, ez a bug már azóta elmúlt, legalábbis FF3, IE7 és Opera 9 alatt. Ez esetben elnézést kérek. :)

Más: nálam szervezési oka is van annak, hogy más URL-je van, ugyanis URL alapján így a controller egy másik actionjére futtatom rá a kérést.
13

REQUEST_METHOD

Hodicska Gergely · 2009. Május. 31. (V), 04.46
Ahogy elnézem, ez a bug már azóta elmúlt
Fura, én még nem nem nagyon találkoztam ezzel, pedig nagyon régóta bevett szokás, hogy nem általában magára POST-oltatok.

Más: nálam szervezési oka is van annak, hogy más URL-je van, ugyanis URL alapján így a controller egy másik actionjére futtatom rá a kérést.
Emiatt nem kell feltétlenül külön URL, hisz a REQUEST_METHOD alapján tudsz differenciálni. Nálunk a routingban elő lehet írni ezt is, ami pl. REST jellgű cuccnál is érdekes lehet:
<?php
return array(
'Article/Add'     => 'POST:/articles'
'Article/ListAll' => 'GET:/articles'
'Article/Show'    => '/article/{digit:articleId}'
);
?>
14

Ez valós kód? Mert akkor két

Fraki · 2009. Május. 31. (V), 13.18
Ez valós kód? Mert akkor két kulisszakérdésem volna :)

1. Miért nem fordítva van?
array(  
'POST:/articles'             => 'Article/Add',
'GET:/articles'              => 'Article/ListAll',
'/article/{digit:articleId}' => 'Article/Show'
);
2. controller metódusok miért kezdődnek nagybetűvel?

+1. A digit:articleId kitételben miért van benne a változónév? Hiszen a show paramlistájában ez úgyis megadható.

Mindegyik kérdésre kielégítő válaszlehetőség a "Csak." :)
15

nem csak :)

Hodicska Gergely · 2009. Május. 31. (V), 20.27
Miért nem fordítva van?
Egy kis háttér: alapvetően 3 féle rule-t lehet megadni. Statikus: egyszerű szöveg egyezést figyelünk ilyenkor. Extended: ilyenkor lehetnek ilyen {} közötti cuccok, amikkel mintákat lehet megadni, valamint nevesített paramétereket lehet begyűjteni. Regexp: ilyenkor egy tetszőleges reguláris kifejezést lehet használni. Ilyenkor nevesített regexp begyűjtkkel lehet paramétereket maghatásozni az URL-ben. Ezen definíció alapján generáljuk az URL-eket, így ha valaminek szeretnénk az URL-jét megváltoztatni, akkor elég a routing konfigot átírni, és máris a generált URL-ek is automatikusan megváltoznak. Ez az URL generálás a konfig kulcsai közül kapja meg az egyiket, és a definíció alapján generálja le az URL-t. Namost ez működik statikus és extended definíciók esetén, de regexp esetén már nem, ezért ilyenkor meg kell adni egy reverseUrl mintát. Ilyenkor a definíció már egy tömb, már csak ezért sem lehet a definíció a kulcs. Viszont az URL generálás szempontjából is ez az előnyös, amikor meg a route-olást megy, akkor ebből a szempontból mindegy.

controller metódusok miért kezdődnek nagybetűvel?
A tényleges metódusnevek egy execute előtagot kapnak, tehát pl. executeAdd.

A digit:articleId kitételben miért van benne a változónév?
A konkrét esettől eltekintve: ha egy URL-ben pl. több paramétert is van, akkor ha nem lennének nevesítve, akkor a controllernél honnan tudod, hogy melyik melyik? A sorrendre hagyatkozol (engem ez nagyon zavarna, jobb szeretek nem ilyesmire hagyatkozni, mert nagyon érzékeny a módosításokra)?

Nálunk ehhez még hozzájön az is, hogy a FrontController Reflection Api segítségével kitölti a Controller metódusok paramétereit, ahol a forrás lehet a routing során kinyert paraméter vagy get/post/cookie. Ez Tolmi ötlete volt, és nagyon kényelmes. Alapvetően nem teszünk különbséget a paraméterek forrása között, de ha kell, akkor fixen elő lehet írni, hogy mi lehet az. A FrontController a DocBlock kommentet használja valamint a metódus paraméter listáját. Ha valami hiányzik, akkor már ő kiabál, így megúszunk egy csomó, a változók meglétének ellenőrzését végző kódot a kontrollerekből, így azok karcsúbbak lesznek. Ezenkívül alapvetően agnosztikusak lehetne a kérésre, adott esetben használhatjuk őket parancssorból is.

Mindegyik kérdésre kielégítő válaszlehetőség a "Csak." :)
Sem tervezni, sem válaszolni nem szoktam így. ;)
16

Erre már korábban is

Fraki · 2009. Júl. 16. (Cs), 13.28
Erre már korábban is szerettem volna reagálni, de valahogy most lett rá érkezésem...

A harmadik kérdéshez: ha a URL-ben nincs nevesítés, akkor ez az információ már ott elvész, a bemenetben sincs meg, tehát innentől meg már mindegy, hogy a paramétereknek hol adsz nevet, a routerben vagy a controllerben, vagy bárhol máshol az üzleti logikában. Nem jól látom? Én jobb híján sorrendre hagyatkozom, max. regexpre, illetve esetleg a URL-ben nevesítek (pl. /nev:ertek/), és engem is zavar a sorrendnek ez az érzékenysége, de mint mondtam, ez alapvetően az URL-stratégia gyengéje, nem az üzleti logikáé.

Nálatok is ha van egy /month/day/ sémájú URL, ez ugyanúgy el fogja fogadni, ha ha valaki /day/month-ot ír be.
17

van nevesítés

Hodicska Gergely · 2009. Júl. 16. (Cs), 15.52
ha a URL-ben nincs nevesítés
De hát van nevesítés, nézd meg az Article/Show rule-t: "/article/{digit:articleId}". Ez egy olyan URL-re illeszkedik, ahol a /article/ után egy szám van. Ezt a számot articleId néven gyűjti be.

illetve esetleg a URL-ben nevesítek (pl. /nev:ertek/)
Szerintem ez az infó nem az URL-be való.

de mint mondtam, ez alapvetően az URL-stratégia gyengéje
Mint a példa is mutatja, simán megoldhatod anélkül, hogy az URL-eket megváltoztatnád, csak okosabb controller kell.

Nálatok is ha van egy /month/day/ sémájú URL, ez ugyanúgy el fogja fogadni, ha ha valaki /day/month-ot ír be.
Nem, van olyan rendszer ami direkt így működik?
18

Elbeszélünk egymás

Fraki · 2009. Júl. 16. (Cs), 17.36
Elbeszélünk egymás mellett.

Onnan indultunk ki, hogy a routerben nevesítve vannak az URL paraméterei. Visszakérdeztél, hogy „ha egy URL-ben pl. több paramétert is van, akkor ha nem lennének nevesítve, akkor a controllernél honnan tudod, hogy melyik melyik?” A sorrendből, igen, de én most visszakérdezek úgy, hogy miért, a routerben – vagy akárhol máshol, ahol az URL-t feldolgozod – honnan tudod, hogy melyik melyik? Ugyanúgy a sorrendből.

És ez azért van így, mert már magában a bemenetben (URL) sincs meg a névinformáció. Tehát ez az érzékenység, ami a sorrendiségből, vagyis a nevek hiányából fakad, már az URL-nél eldől.

A konkrét példát nézve:

„Ez egy olyan URL-re illeszkedik, ahol a /article/ után egy szám van.”

De ha két szám van, akkor az a rule ugyanúgy a sorrendiségre támaszkodik már.
19

De közben gondolkodom tovább,

Fraki · 2009. Júl. 16. (Cs), 17.49
De közben gondolkodom tovább, és rájöttem a lényegre (azt hiszem): amit mondasz, az az, hogy a routerben egy mintában nevesíteni átláthatóbb dolog, mint egy paraméterlista egy függvényben.

Ez igaz, így értem, rendben.