Url logika - melyik a jobb?
2014-01-13T20:43:58+01:00
2014-01-19T01:53:50+01:00
2022-07-19T02:51:55+02:00
  • /user/peter/view
    /user/peter/edit
    /user/peter/friends
    stb...

    majd az idő eldönti, jól döntöttem-e vagy nem (vagy tök mindegy volt :D)
    Mutasd a teljes hozzászólást!
  • és végülis milyenek lesznek az url-jeid? melyik elgondolás mellett tetted le a voksod?
    Mutasd a teljes hozzászólást!
  • Köszönöm a további tippeket, gondolatokat.

    A kérdésem csupán elméleti volt, nem egy projekt van, hanem mondjuk a következő 3 év összes projektje :)

    Eddig egy fix séma mentén kellet dolgoznom ami a controllerek és azok metódusait ábrázolta az url-ben, most lehetőségem van magam eldönteni mit fogunk csinálni :)

    Amikor elkezdtem php-ban programozni még az volt a kritérium, hogy "menjen ie6-ban kikapcsolt javaScriptel...." a 4-5 paraméter GET-ként az URL-ben senkit nem érdekelt, 2-3 éve URL-ek is alapkritériumok "mert halottam az unokatesóm fiától hogy szeóval első leszek a google-ben minden szóra..." - megtörtén eset :S

    Jelenleg azt a trendet látom, hogy már nem csak embereknek kell programozni hanem különböző értelmezőknek akik az emberek számára átalakítják és egyénileg tálalják az információkat - gondolok itt akár az akadálymentesítő szoftverekre vagy rich snippets-ek alapján aggregátor oldalakra stb...

    A hozzászólásokat olvasgatva és tovább gondolva nekem most az erősen objektum orientált szemlélet tűnik ismét szimpatikusnak (ellenben azzal hogy az URL-ek a kontrollereket ábrázolják)

    reméltem, hogy a téma több ember figyelmét is felkelti (nem csak php hanem mondjuk .net, vagy jsp fejlesztőkét is) köszönöm az eddigi válaszokat így is nagyon tanúságos volt :)
    Mutasd a teljes hozzászólást!
  • a saját javaslatomhoz annyit tennék hozzá hoyg a nézet mégiscsak lehet hogy kellene. tehát lenne kovácspista/nézet (vagy esetedben peter/view) és emellett a / kilistázná az elérhető funkciókat. tehát ott listába szedve látnád azokat a linkeket hogy ./nézet ./törlés ./módosítás stb
    Mutasd a teljes hozzászólást!
  • Próbálj több saját magad által alkalmazott példát hozni az URL-ek feldolgozásával/használatával kapcsolatban és az lesz a legjobb, ami jobban illeszkedik az eddigi (megtartandó) megoldásaidra.

    Tudom hogy ez így túl általános, ezért pár 5let:

    1) Milyen framework-öt használsz általában? Ez pl egy kiindulási alap lehet, mert ezeknél eleve van egy "ajánlás"/alapértelmezett megoldás (persze egymódosított routing esetén máris borul a dolog)

    2) Vannak-e olyan extra tételek, amiket mindenképp bele kell építened minden X url-be?

    Pl: 
    - változó+érték helyett hash-ekkel kell-e dolgozni a nem/kevésbé megjósolható url-ek végett, 
    - vagy szükség van-e a lehető legrövidebb url-ekre (url shorting)? 

     Tehát az url "olvashatósága+értelmezése" mennyire fontos?

    3) mennyire "szereted" párosával tartani az URL paramétereket?



    változó=érték/változó=érték azaz: user=11/muvelet=edit
    Ebben az esetben a 1. talán szerencsésebb..

    Persze ehelyett lehet azt is mondani, hogy 11/edit. Akkor lehet belőle kavarodás ha egy url-en több ilyet akarsz átadni.
    Főleg ha az "edit" ághoz tartozik további információ mivel így a user "ID" része nem tolódik az url vége felé, hanem szorosan "párban maradnak".


    4) Van-e korábbi projected/v több, aminél már az egyik megoldás kiválasztottad? Mert így gyakorlatilag időt spórolhatsz..
    Mutasd a teljes hozzászólást!
  • ugyanakkor viszont az első megoldással bármelyik user megtekintésből egy egyszerű relatív linkkel el tudod érni a szerkesztés lapot (href="./edit"), ami egyszerűsítheti az oldalak közötti navigációt.

    (mindkettő teljesen érvényes szemantika. az első inkább az objektum-orientált megközelítésre hajaz - vannak user objektumok, akiknek lehetnek műveletei, és ha valamelyik nem értelmezett az adott felhasználón, majd visszadob egy 4xx vagy 5xx hibát, a második pedig inkább a szolgáltatás-orientált megközelítés - vannak funkcióink amiket paraméterezni lehet, és ha adott paraméterrel nincs joga vagy nem értelmezett a művelet, hibát ad).

    úgyhogy azt javaslom, válaszd azt, amelyikkel könnyebben tudsz dolgozni.

    személy szerint nekem az első jobban tetszik, korszerűbb megközelítés.
    Mutasd a teljes hozzászólást!
  • Köszönöm az eddigi válaszokat, kérdésem az url-ek re vonatkozott, természetesen a feldolgozásuk nem okoz gondot bármelyik variáció is legyen....
    off: még regex se feltétlenül kell neki, explode elég ide :)


    Kicsit tovább gondoltam a kérdést:
    - ha nem csak az alap CRUD 4-es van...
    mondjuk egy friends/about stb... is és nem id hanem slug

    pl:
    http://example.com/user/peter/ - http://example.com/user/peter/
    http://example.com/user/peter/edithttp://example.com/user/edit/peter
    http://example.com/user/peter/friendshttp://example.com/user/friends/peter
    http://example.com/user/peter/abouthttp://example.com/user/about/peter

    a kérdés továbbra is elméleti, és az url-ekre vonatkozik az implementálásra nem...

    szóval ha valaminek van még véleménye vagy új gondolata ne tartsa magában :)
    Mutasd a teljes hozzászólást!
  • Tök mindegy.

    Funkcionális szempontból nyilván a második változat fogja jobban a programod felépítését tükrözni, hiszen utóbbi nyilván nem úgy fog működni, hogy minden felhasználónak lesz törlés meg módosítás lapja, hanem úgy, hogy lesz törlés meg módosítás lap, ami minden felhasználóra alkalmazható lesz. Éppen ezért én mondjuk az ID-t nem is építeném be a path-be, hanem query paraméterként hagynám.

    Ugyanakkor abszolút nincs jelentősége se a sorrendnek, se annak, hogy query paraméterként vagy a path részeként adod -e át a felhasználó azonosítóját, mert hogy - szemben az itt korábban elhangzott állításokkal - megfelelő regexp kifejezésekkel akármilyen formához ugyanolyan egyszerű router szerkezetet lehet írni.
    Mutasd a teljes hozzászólást!
  • Második, mivel így meg tudod úgy írni a router függvényedet (ami kiválasztja az URL alapján, hogy milyen funkciót / filet kell meghívni), hogy a rewrite részein menjen egy ciklussal végig, és így lehet pl. a user mappában 3 file: index.php, edit.php és delete.php.

    $include = "controller"; foreach ($rewrite as $r) { if (file_exists($include . "/" . $r) && is_dir($include . "/" . $r)) { $include .= "/" . $r; continue; } if (file_exists($include . "/" . $r . ".php")) $include .= "/" . $r . ".php"; elseif (file_exists($include . "/index.php")) $include .= "/index.php"; else $include = "controller/404.php"; break; }

    Ez csak egy gyors példa, ha így csinálod, a ".."-ra (parent dir) mindenképp figyelni kell, hogy ne legyen az url-ben megengedve.
    Mutasd a teljes hozzászólást!
  • nekem az első természetesebbnek hat. id=kovácspista. ekkor a mondat
    kovácspista/nézet
    kovácspista/törlés
    kovácspista/szerkesztés
    nálad annyi még hogy a nézet nincs igy kimondva, hanem a kovácspista/ alól az jön be.
    a második eset inkább olyan nekem hogy van törlés, és ott aztán bármit törölhetek, például usert, vagy erőforrást vagy fájlt. és csak egy opció hogy most usert törlök
    Mutasd a teljes hozzászólást!
  • Én a második variáció mentén szoktam haladni.
    Mutasd a teljes hozzászólást!
  • Sziasztok!

    Egy elméleti kérdésem lenne, hogy szerintetek melyik logika szerint érdemes egy új projektben az url-eket felépíteni?

    1 variáció nekem ezt sugallja: USER objektumnak vannak funkciói és azokat hívjuk meg.
    * http://example.com/user/ID -> user adatlapja
    * http://example.com/user/ID/edit -> user módosítása
    * http://example.com/user/ID/delete -> user törlése

    2 variáció nekem ezt sugallja: Vannak user törlésért és frissítéséért felelős funkcióink, és azok paramétere a user id-je.
    * http://example.com/user/ID -> user adatlapja
    * http://example.com/user/edit/ID -> user módosítása
    * http://example.com/user/delete/ID -> user törlése

    A kérdéseim a következők:
    * Mi a bevált gyakorlat nálatok?
    * Az url kövesse a kód logikáját?
    * Jelenleg van-e olyan gyakorlat mely elterjedtebb a másiknál?

    Nekem az a problémám, hogy az 1. variáció jobban fedi a program logikáját nálam, de a 2. jobbnak tűnik url pirítás szempontjából ( én azt szeretem hogy a path-ek sorrendje meghatározza azok változatosságát --> az url vége változzon gyakrabban ne a közepe) 
    pl:
    * http://example.com/user/101/edit - http://example.com/user/edit/101
    * http://example.com/user/202/edit - http://example.com/user/edit/202
    * http://example.com/user/404/edit - http://example.com/user/edit/404
    az utóbbi szebb nekem.
    Mutasd a teljes hozzászólást!
Címkék
abcd