Zvláštní předávání proměnných a hezké URI

Fanda

Takovéhle taktika se většinou používá pokud není možné použít mod_rewrite. Můžeš si o tom myslet v podstatě dvě věci.( Záleží na tom jak to autor toho scriptu myslel )

1) Neuměl mod_rewrite a proto to obchází tímto způsobem
2) Je zastáncem názoru, že o routování by se měla starat až samotná aplikace.

Osobně mám taky radši jednoduchý .htaccess a routovat až v aplikaci než 50 mod_rewrite pravidel.

Ale mám pocit, že člověk, který dělá takovouhle věc spadá do té druhé skupiny. navíc posléze jednoduchým pravidlem může odstranit index.php z adresy a má v podstatě hezké URI.

Hlanve je otazka co znamena cislo "5" v "hezke uri". Moc hezke tam neni.

ninja

V tomhle případě tam číslo 5 není úplně ideální, ale je to prostě jedineční ID stránky. Při každém vytváření se musíš rozhodnout podle jakého jedinečného identifikátoru budeš rozhodovat o obsahu stránky.

ID z databáze má tu výhodu, že je v podstatě vždy jedinečné pro nějaký celek ( tabulku ) a nehrozí kolize. Navíc operování nad int sloupci je rychlejší.

Samozdřejmě můžes ID v URI dostat pryč, ale za cenu operování nad řetězcem v DB. ( pokud je na sloupci index tak je to i docela rychlé ) Musíš, ale zajistit jedinečnost tohoto stringu. Proto se u věcí u kterých se předpokládá možná kolize radši dělá URI typu

www.example.com/produkt/mixer-electrolux-2542/

BetaCam: ja samozrejme vim proc tam ta petka je. Slo o narazku na "hezke uri", ktere ale ve skutecnosti moc hezke neni, protoze coby uzivatel nemam poneti jaky tam ma ta petka vyznam.

Ani se nedomnivam ze je tento zpusob snazsi nez www.example.com/produkt/mixer-electrolux. Jestli desifruji URL na konkretni zaznam v databazi podle ID nebo jineho jedinecneho sloupce, neni velky rozdil. A odpadnou mi problemy s resenim duplicit typu:

www.example.com/produkt/5/mixer-electrolux
www.example.com/produkt/5/mycka-nadobi


Neni to nic zasadniho, ale kdyz uz se neco podobneho pripravuji, udelam to poradne.

ninja

„A odpadnou mi problemy s resenim duplicit typu:

www.example.com/produkt/5/mixer-electrolux
www.example.com/produkt/5/mycka-nadobi “

Tyhle URI sou blbost ID záznamu z nějakého celku je vždy jedinečné. Není třeba se starat o jeho jedinečnost postará se o to samotná databáze. Tyto URI sou naprosto nesmyslné. Pokud narážíš na podstrčení nevalidního URI ( URI kde identifikátor zůstane stejný, ale jiné části URI sou pozměněny ) tak tomu nezabráníš ani vygenerováním jedinečného stringu. Tak jako tak to budeš muset ověřit. Rozdíl je jediný s ID se nemusíš starat o URI je vždy jedinečné. Se stringem musíš kontrolovat jestli už takoví string neexistuje pokud ano tak přidat nějaký identifikátor který to rozliší.

S ID kontroluješ jen výsledek a při vstupu nic neřešíš.
Se stringem musíš ověřovat už při ukládání následně případně ošetřovat string. A s pořadavkem zase musíš ověřit validnost URI.

Jinak ID se hlavně používá pokud se nějaká aplikace předelává, protože to vyžaduje menší zásahy do ní.

Když už chcete pěkné URI bez mod rewrite, tak co to udělat spíš takhle:

;)

Fanda
Ak by ta zaujimalo, ako je to robene, tak hľa, pisal som o tom.

BetaCam: kontrolovat ID musis uplne stejne jako string. Vetsinou staci osetrit vkladani, tedy aby v databazi bylo vzdy unikatni ID ci URL (muzes vytvaret onFly pri konstrukci dotazu z nazvu).

Jediny rozdil je ze ukladani produktu/clanku/atd. musis provest v pripade neuspesneho vlozeni jeden SQL dotaz ze uz takovy zaznam je.

Podvrzenych/upravenych/chybnych URL se na internetu vytvori tolik, ze ti duplicity se stejnym ID a jinym URL vzniknou.

ninja
„Podvrzenych/upravenych/chybnych URL se na internetu vytvori tolik, ze ti duplicity se stejnym ID a jinym URL vzniknou.“

Vzniknout můžou důležité je aby nefungovali nebo, aby byli přesměrovány na validní URI.

„kontrolovat ID musis uplne stejne jako string. Vetsinou staci osetrit vkladani, tedy aby v databazi bylo vzdy unikatni ID ci URL“

Pro id je vymoženost typu auto_increment. Tedy o unikátnost v rámci určitého celku se nemusíš při ukládání starat.

String musíš ošetřit při ukládání. Nelze zajistit, že například někdo nenapíše dva články se stejným názvem. Tím bere zasvé i tvá onFly konstrukce pomocí názvu.

BetaCam: Vzniknout můžou důležité je aby nefungovali nebo, aby byli přesměrovány na validní URI.

A jak tedy u url http://www.example.com/5/mixer-eta overis, ze "mixer-eta" je u ID 5 ten pravy a nemas nekam presmerovat?

String musíš ošetřit při ukládání.

Ano, musim nejdrive zjistit, jestli jiz dane URL nemam zapsane v DB a kdyz ano, zmenit jej. Par radku kodu. Stejne jako nutne overovani a presmorovavani u tve verze.

ninja

„A jak tedy u url http://www.example.com/5/mixer-eta overis, ze "mixer-eta" je u ID 5 ten pravy a nemas nekam presmerovat?“



„Ano, musim nejdrive zjistit, jestli jiz dane URL nemam zapsane v DB a kdyz ano, zmenit jej. Par radku kodu. Stejne jako nutne overovani a presmorovavani u tve verze.“

Já neříkám, že oboje má své také proto sem tady již dříve napsal :

„Jinak ID se hlavně používá pokud se nějaká aplikace předelává, protože to vyžaduje menší zásahy do ní.“

Pokud se předělává aplikace je většinou právě stavěná na ID parametru, proto se tento ID parametr ponechá a aplikace může zůstat téměř beze změn. Pokud by se ID nepředávalo musela by se aplikace daleko více upravovat.

Nothrem
„Když už chcete pěkné URI bez mod rewrite, tak co to udělat spíš takhle:“
„http://www.obchod.com?produkty/mycka_nadobi ;)“
Jak potom zjistíš, že se ta proměnná jmenuje "produkty/mycka_nadobi"? Dá se nějak získat n-tá proměnná předaná přes GET, aniž by skript znal její název?

imploder

V tomto případě například takto :