[feat] Url's : usernames mappen naar user_id

[drm]

Is het mogelijk bij myreact, posthistory en profile url's usernames te mappen naar user id's?

Bijvoorbeeld:
[norml]http://gathering.tweakers.net/forum/myreact/drm[/]
is hetzelfde als
[norml]http://gathering.tweakers.net/forum/myreact/22119[/]

_{in mijn geval is dat natuurlijk al zo omdat hij default naar je eigen myreact pagina Maar ook bij andere usernames is het wel "handig", hoef je niet eerst het id op te zoeken.}

[Verwijderd]

Nou stel nu dat er iemand is met spaties in zijn of haar nick ?? of met rare tekens.. dan word het wat lastiger toch

[drm]

De meeste browsers vertalen dat bij het verzenden van de url wel naar een encoded url.

En de meeste rare tekens zijn toch al niet toegestaan in nicknames.

[André]

Dat is omdat jij het zo makkelijker wil maken om users te zoeken? Eigenlijk zou er dan net als op de FP (in de tweaker gallery) een zoekfuntie moeten komen om in profiles te zoeken.

[drm]

Nee, niet om het makkelijker te maken op users te zoeken, want dat is opzich makkelijk zat. Als ik naar de search ga en zoek op topicstarter kan je gewoon de eerste link naar de username pakken want dat is dan ook een myreact url.

Het is juist handig omdat je tijdens het tikken van een post wel een wilt verwijzen naar een user, maar elke keer de user-id op moet zoeken als je een myreact-linkje wilt plaatsen. Scheelt gewoon een hoop tijd bij het verwijzen naar users.

[Verwijderd]

En dan met een snelurl zoals: http://gathering.tweakers.net/LooksLike !

[Verwijderd]

Hebt ik al ooit gevraagd [rml][ FEAT] Nickname kunnen gebruiken i.p.v. IDs in URLs[/rml]

Mjah reden dat het niet kan is een beetje vreemd i.m.o.
Ten eerste kan je namen met / verbieden en op GoT gebeurt dat al.

Ten tweede kun je gewoon controleren, omdat de string in de url voor de naam vast staat. Wordt wat problematischer zodra je met meer variabelen wil gaan werken in een url, maar ook daar is nog omheen te werken.

[drm]

Nelske:
Hebt ik al ooit gevraagd [rml][ FEAT] Nickname kunnen gebruiken i.p.v. IDs in URLs[/rml]

Mjah reden dat het niet kan is een beetje vreemd i.m.o.
Ten eerste kan je namen met / verbieden en op GoT gebeurt dat al.

Klopt, maar je zou ook een soort escape character in kunnen bouwen. Splitten op "[^\]/" ipv. exploden op '/' lijkt me niet zo'n punt

Ten tweede kun je gewoon controleren, omdat de string in de url voor de naam vast staat. Wordt wat problematischer zodra je met meer variabelen wil gaan werken in een url, maar ook daar is nog omheen te werken.

Die volg ik niet helemaal geloof ik

[Verwijderd]

forum/find_user/Nelske/number_posts/100 en
forum/find_user/Nelske/metslash/number_posts/100 bedoel ik

ofwel het equivalent van
forum.php?find_user=Nelske&number_posts=100 en
forum.php?find_user=Nelske/met_slash&number_posts=100

Waarbij number_posts uiteraard een fictieve GET-var is als voorbeeld

[ Voor 51% gewijzigd door Verwijderd op 16-05-2003 17:29 ]

[drm]

Nelske:
forum/find_user/Nelske/number_posts/100 en
forum/find_user/Nelske/metslash/number_posts/100 bedoel ik
ofwel het equivalent van form.php?find_user=Nelske&number_posts=100 en
form.php?find_user=Nelske/met_slash&number_posts=100

Waarbij number_posts uiteraard een fictieve GET-var is als voorbeeld

Dat is een manier van implementeren die hier volgens mij niet gebruikt wordt. Parameters hebben gewoon een vaste positie.

Ik vermoed dat het ongeveer zo in elkaar zit:
De eerste (bijv. forum) is een multiview op forum.php
De tweede (bijv. 'list_message') is de "action"
De derde (bijv. '1691114') is het 'subject_id', waarop voer ik de 'action' uit
De vierde (bijv '2') is het paginanummer
De vijfde weet ik niet ..
De zesde is een comma-seperated list van "zoekwoorden" die gehilite moeten worden.

Dus het heeft niet zoveel te maken met een "rewrite" naar de var=value&var2=value2 syntax, de url wordt gewoon gesplit op '/'

Vermoed ik, maar de devvers mogen me corrigeren als het onzin is

edit:

En dan is een escape character dus voldoende

edit:

Trouwens, als het wel een rewrite zou zijn, zou een escape character ook voldoende zijn, want rewrites werken tenslotte ook op basis van regular expressions

[ Voor 10% gewijzigd door drm op 16-05-2003 17:34 ]

[chem]

Dat heb je helemaal correct, drm. Een escape zou kunnen, maar vereist een zwaardere split() ipv de lichte explode(). Als is dat vv vrij triviaal tov het gehele script, 1 functie of de andere
Een escape lijkt me wel nodig, maar echt mooi is het niet. Misschien in v2, hij zat nog immer op de 'todo-if-feasible' lijst. Dus nog iig even wachten