[ALG] Logica achter website URL's

[Reveller]

Ik ga ervan uit dat elke URL bestaat uit een domain, pad en een querystring. Bovendien wil je niet de achterliggende techniek aan de gebruiker blootleggen (heeft ook geen zin overigens), dus een typische URL bij mijn CMS is:

code:

http://www.website.com/groenten/winter/witlof?size=medium&supplier=greenery
<------ domein ------><-------- pad --------><-------- querystring ------->

Nu vraag ik me alleen af: zit er een bepaalde logica achter wat je in het pad zelf en wat je in de querystring zet? Bovenstaande URL zou ik ook als volgt kunnen schrijven:

code:

http://www.website.com/groenten/winter/witlof/medium/greenery

Dat zou dan eigenlijk weer niet logisch zijn, omdat een gebruiker best eerst "greenery" zal kunnen selecteren, en pas daarna "medium". De url zou dan moeten eindigen op witlof/greenery/medium. Als "properties" van wat een pagina beschrijft in willekeurige volgorde kunnen worden gekozen, zou je het in een querystring kunnen zetten. Aan de andere kant zou je dan ook "groenten" en "witlof" kunnen omdraaien: winter/groenten/medium/greenery, maar dat ziet er veel minder logisch uit.

* Hoe bepaal je wat er logischerwijs als pad en wat als querystring moet worden weergegeven?

Een tweede voorbeeld zou GoT zelf kunnen zijn: waarom Programming & Webscripting in plaats van http://gathering.tweakers.net/forum?id=14 en waarom dan weer wel http://gathering.tweakers...5D=OR&data%5Bforums%5D%5B%5

Zou je kunnen zeggen dat alles wat een gebruiker via een form zelf kan submitten, in de querystring moet? Ik stel deze vraag in P&W omdat velen hier een eigen CMS bouwen, en vast allemaal wel eens met dergelijke vragen gezeten hebben

[ Voor 16% gewijzigd door Reveller op 04-10-2005 19:07 ]

[Not Pingu]

Een pad is letterlijk een weergave van de hierarchische navigatiestructuur, of dat pad nou fysiek is of virtueel in een database staat. Daarbij is het ook logisch om te veronderstellen dat de gebruiker in de URL gaat zitten hacken. Bij het voorbeeld dat je noemt, zie ik niet in waarom je zou verwachten dat de gebruiker van de URL gebruik zou maken om bepaalde parameters toe te voegen.

Als ik het goed zie, gebruik je hier pad en parameters door elkaar en dat lijkt me geen goed idee. Hoe weet je CMS dan of een URL segment een parameter is of onderdeel van het pad?

[ Voor 8% gewijzigd door Not Pingu op 04-10-2005 19:17 ]

[Verwijderd]

Geheel niet ontopic op je problematiek, maar je neemt ten onrechte http:// mee bij het domein.

Om dan toch ook maar iets ontopics toe te voegen:
Je stelt voor je navigatie eerst verschillende entiteiten op die je site gaat laten zien.

Parameters zijn eigenlijk bedoeld om data binnen zo'n entiteit te laten stromen of door data van de ene naar de andere entiteit door te sturen. Nu gebruik je daar doorgaans eerder Post dan Get voor.

Als je consequent altijd Post voor datasturen gebruikt, kun je parameters ook gebruiken voor site-navigatie, maar dan moet je niet ook een pad gebruiken voor sitenavigatie. Áls je dat wel doet, dan moet je met pad op een abstracter niveau navigeren dan met parameters.

Ik zelf heb een site daar maakt het pad enkel onderscheid tussen gewoon en /admin. Binnen beide stukken navigeer ik dan met parameters. Pad is dus een abstractere navigatie dan parameters. Verder gebruik ik ten alle tijden Post om data tussen of binnen de verschillende entiteiten te laten flowen.

Onconsequent zijn en de boel door elkaar gebruiken is nooit echt overzichtelijk. Zowel niet voor jou als onderhouder van de website als voor eenieder die er mee moet werken.

Athans, dat is mijn visie op het geheel

edit/toevoeging: het voordeel van je volledige navigatie zo veel mogelijk in parameters te zetten is dat het vrij makkelijk is om een dynamische site te maken zonder dingen dubbel of met (i)frames te moeten doen (alhoewel je natuurlijk ook steeds headers en footers kunt includen, maar dat werkt ook niet altijd perfect).

[ Voor 16% gewijzigd door Verwijderd op 04-10-2005 19:40 ]

[H!GHGuY]

ik denk dat je algemeen bij een boomstructuur waarin elk niveau een deelverzameling voorstelt van het element op het vorig niveau, best zo snel mogelijk tot een zo klein mogelijke deelverzameling komt.

veronderstellen we jou voorbeeld met greenery en medium, dan kun je veronderstellen dat het aantal "merken"(?) groter is dan het aantal groottes. Dus met eerst greenery te selecteren en dan pas medium, moet je bij je 2de "subquery" minder werk verrichten.

maar zowiezo zou ik het pad gebruiken voor de fysieke pagina's op de server onder te verdelen.
Dus deze URL:

code:

http://www.website.com/groenten/winter/witlof?size=medium&supplier=greenery
<------ domein ------><-------- pad --------><-------- querystring ------->

impliceert dat er wel ergens een subpagina is waar je zowel wintergroentjes als zomergroentjes kan selecteren en je daarna naar een pagina genomen wordt waar je witlof of andere groentjes kunt selecteren.

[JHS]

Ik zie het probleem niet met een dubbelle virtuele hiërarchie. Waar niet zowel /witlof/medium/greenery als /witlog/greenery/medium ? Het zijn beide onderverdelingen, alleen moet er dan een krachtige alias engine achterzitten die fouten voorkomt .

Een andere mogelijkheid is de gedachte dat je op een gegeven moment een onderscheid maakt tussen een pagina en een selectie / bewerking van die pagina. Bij GoT heb je bijvoorbeeld de highlighting functie. Dat is een bewerking van een pagina, en zou in dat opzicht het beste in een querystring passen.

De grootste vraag is dan echter wat je daadwerkelijk als pagina ziet, en wat als selectie. In het witlof voorbeeld zou ik zeggen dat je een onderverdeling aan het maken bent op type plant. Dus je hebt /groenten/seizoen/soort/grootte/ : dat zijn allemaal selecties binnen de grotere groep, gebaseerd op het type plant. Van welke supplier de plant komt is niet relevant voor het type, en zou dan in een querystring kunnen.

Bovenstaande is niet echt een duidelijk voorbeeld trouwens. Ik vind de onderverdeling selectie / bewerking in pad resp. querystring het duidelijkst . Dus ik denk toch dat je zoveel mogelijk moet gaan voor een krachtige engine achter je urls. Want waarom zou je niet naar /groenten/witlof/ kunnen gaan, mits dat één pagina oplevert, anders zou je een error scherm kunnen voorschotelen.