/ Forside / Teknologi / Udvikling / PHP / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
PHP
#NavnPoint
rfh 3959
natmaden 3372
poul_from 3310
funbreak 2700
stone47 2230
Jin2k 1960
Angband 1743
Bjerner 1249
refi 1185
10  Interkril.. 1146
Flere sider i en. Hvordan ?
Fra : Emil Petersen


Dato : 08-12-07 23:32

Hej,

Det er lidt indviklet at forklare. Tit står der i URL:
index.php?id=12 eller index.php?id=79 osv. Hver side er
forskellig men er vel stadig index.php hvordan gør man det? Nogen
der kan hjælpe ?

/Emil Petersen.

--
Vil du lære at kode HTML, XHTML, CSS, SSI, ASP eller ASP.NET?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

 
 
Holst (08-12-2007)
Kommentar
Fra : Holst


Dato : 08-12-07 23:46


Emil Petersen wrote:

> Det er lidt indviklet at forklare. Tit står der i URL:
> index.php?id=12 eller index.php?id=79 osv. Hver side er
> forskellig men er vel stadig index.php hvordan gør man det? Nogen
> der kan hjælpe ?

Du læser en introduktion/guide/whatever til PHP. En hurtig googling
fandt for eksempel denne:

http://www.razor.dk/php/guider/

Jeg kender den ikke, men den kan vel være lige så god som så mange andre.

Kim Ludvigsen (09-12-2007)
Kommentar
Fra : Kim Ludvigsen


Dato : 09-12-07 01:08

Den 08-12-07 23.31 skrev Emil Petersen følgende:

> Det er lidt indviklet at forklare. Tit står der i URL:
> index.php?id=12 eller index.php?id=79 osv. Hver side er
> forskellig men er vel stadig index.php hvordan gør man det?

Det er fordi indholdet typisk hentes i en database. Man bruger php til
at aflæse id-nummeret i adressen, og så bruger man id-nummeret til at
hente det ønskede i databasen. Grundsiden er altså den samme, det er
blot indholdet, der er forskelligt.

--
Mvh. Kim Ludvigsen
Polimiken - en levende netavis, der tør, hvor selv Ekstra Bladet tier.
http://polimiken.dk

Philip Nunnegaard (09-12-2007)
Kommentar
Fra : Philip Nunnegaard


Dato : 09-12-07 04:45

> Det er lidt indviklet at forklare. Tit står der i URL:
> index.php?id=12 eller index.php?id=79 osv. Hver side er
> forskellig men er vel stadig index.php hvordan gør man det? Nogen
> der kan hjælpe ?

Helt rigtigt. Det er altid index.php (i dette tilfælde).
Den henter så typisk forskellige poster fra en database og præsenterer dem
på index-siden.
I det enen tilfælde en post med id-nummer 12 og i det andet tilfælde en post
med ID-nummer 79.

Personligt bryder jeg mig ikke om en url med "id=12". W3Cs HTML-validator
brokker sig lidt over det, fordi den ikke kan skelne mellem en <div>-id og
en databasepost-id. Derfor foretrækker jeg noget a la
"index.php?artikel_id=12"
Og i den SQL-sætning, jeg kalder frem på index.php hedder det så noget i
retning af:

select [kolonnenavne] from [tabellens_navn] where id=".$_GET["artikel_id"];
// I dette tilfælde artiklen med ID-nummer 12.

En lille forklaring findes her:
http://www.html.dk/tutorials/asp/lektion10.asp

Ovenstående er godt nok hentet fra HTML.dks ASP-tutorial, men den kan også
bruges i PHP.


Emil Petersen (09-12-2007)
Kommentar
Fra : Emil Petersen


Dato : 09-12-07 17:56

Philip Nunnegaard wrote in dk.edb.internet.webdesign.serverside.php:
> > Det er lidt indviklet at forklare. Tit står der i URL:
> > index.php?id=12 eller index.php?id=79 osv. Hver side er
> > forskellig men er vel stadig index.php hvordan gør man det? Nogen
> > der kan hjælpe ?
>
> Helt rigtigt. Det er altid index.php (i dette tilfælde).
> Den henter så typisk forskellige poster fra en database og præsenterer dem
> på index-siden.
> I det enen tilfælde en post med id-nummer 12 og i det andet tilfælde en post
> med ID-nummer 79.
>
> Personligt bryder jeg mig ikke om en url med "id=12". W3Cs HTML-validator
> brokker sig lidt over det, fordi den ikke kan skelne mellem en <div>-id og
> en databasepost-id. Derfor foretrækker jeg noget a la
> "index.php?artikel_id=12"
> Og i den SQL-sætning, jeg kalder frem på index.php hedder det så noget i
> retning af:
>
> select [kolonnenavne] from [tabellens_navn] where id=".$_GET["artikel_id"];
> // I dette tilfælde artiklen med ID-nummer 12.
>
> En lille forklaring findes her:
> http://www.html.dk/tutorials/asp/lektion10.asp
>
> Ovenstående er godt nok hentet fra HTML.dks ASP-tutorial, men den kan også
> bruges i PHP.
>


Tak for hjælpen.

--
Vil du lære at kode HTML, XHTML, CSS, SSI, ASP eller ASP.NET?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

Kasper Eulert (09-12-2007)
Kommentar
Fra : Kasper Eulert


Dato : 09-12-07 20:26

On 08 Dec 2007 22:31:55 GMT, Emil Petersen <ep12@live.dk> wrote:

>Hej,
>
>Det er lidt indviklet at forklare. Tit står der i URL:
>index.php?id=12 eller index.php?id=79 osv. Hver side er
>forskellig men er vel stadig index.php hvordan gør man det? Nogen
>der kan hjælpe ?
>
>/Emil Petersen.

Som de andre forklaret hvorledes adressen skal tydes. Vær opmærksom på
at google absolut ikke bryder sig om værdier i url. Samtidig ændrer
værdierne sig hvergang du laver noget nyt og så kan søgemaskinen
begynde forfra - og det holder de op med på et tidspunkt.
Koder du selv eller bruger du CMS?
Mvh
Kasper Eulert
www.kaffe-cafe.dk - Alt om kaffe!
Ny side om kaffe - Vind 5 poser kaffe!

Kim Ludvigsen (09-12-2007)
Kommentar
Fra : Kim Ludvigsen


Dato : 09-12-07 20:35

Den 09-12-07 20.26 skrev Kasper Eulert følgende:

> Som de andre forklaret hvorledes adressen skal tydes. Vær opmærksom på
> at google absolut ikke bryder sig om værdier i url.

Det kommer så sandelig an på, hvilke værdier du taler om.
index.php?side=91 eller index.php?side=ikke_en_kinamands_chance virker
ganske udmærket. Sidstnævnte har endda den fordel, at Google bruger
ordene til at indeksere siden, og at ordenede i url'en tæller højere end
ordene på selve siden.

> Samtidig ændrer
> værdierne sig hvergang du laver noget nyt og så kan søgemaskinen
> begynde forfra - og det holder de op med på et tidspunkt.

Hvorfor skulle de ændre sig?

--
Mvh. Kim Ludvigsen
Polimiken - en levende netavis, der tør, hvor selv Ekstra Bladet tier.
http://polimiken.dk

Martin Højriis Krist~ (09-12-2007)
Kommentar
Fra : Martin Højriis Krist~


Dato : 09-12-07 20:45

"Kim Ludvigsen" <usenet@kimludvigsen.dk> skrev i en meddelelse
news:475c4354$0$2093$edfadb0f@dtext02.news.tele.dk...
> index.php?side=91 eller index.php?side=ikke_en_kinamands_chance virker
>> Samtidig ændrer
>> værdierne sig hvergang du laver noget nyt og så kan søgemaskinen
>> begynde forfra - og det holder de op med på et tidspunkt.
> Hvorfor skulle de ændre sig?

Hvis man fx holder op med at bruge php...

--
Martin Højriis Kristensen
http://www.martinshjemmeside.dk/ - Lidt af hvert
http://www.mestomaarhus.dk/ - Mest om Århus



Bertel Lund Hansen (09-12-2007)
Kommentar
Fra : Bertel Lund Hansen


Dato : 09-12-07 21:45

Martin Højriis Kristensen skrev:

> > Hvorfor skulle de ændre sig?

> Hvis man fx holder op med at bruge php...

Intet varer evigt. Om man holder op med at bruge PHP, bliver trær
af hjemmesider eller dør, kommer vel ud på ét? Det er ikke noget
man kan tage hensyn til i den øjeblikkelige situation.

--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

Martin Højriis Krist~ (09-12-2007)
Kommentar
Fra : Martin Højriis Krist~


Dato : 09-12-07 23:51

"Bertel Lund Hansen" <unospamo@lundhansen.dk> skrev i en meddelelse
news:9tkol3h0v4a768a36c4ni5b1dmp568bua1@4ax.com...
>> > Hvorfor skulle de ændre sig?
>> Hvis man fx holder op med at bruge php...
> Intet varer evigt. Om man holder op med at bruge PHP, bliver trær
> af hjemmesider eller dør, kommer vel ud på ét? Det er ikke noget
> man kan tage hensyn til i den øjeblikkelige situation.

Man kan ikke tage hensyn til alt, men der er ingen grund til at gemme data i
sin URI som ikke er betydningsbærende. At man anvender php eller asp er
sjældent relevant for brugeren og kan ligeså godt udelades.
Genudsendelse: http://www.w3.org/Provider/Style/URI

--
Martin Højriis Kristensen
http://www.martinshjemmeside.dk/ - Lidt af hvert
http://www.mestomaarhus.dk/ - Mest om Århus



Bertel Lund Hansen (10-12-2007)
Kommentar
Fra : Bertel Lund Hansen


Dato : 10-12-07 00:24

Martin Højriis Kristensen skrev:

> Genudsendelse: http://www.w3.org/Provider/Style/URI

Vi beskæftiger os med to postulater (ikke dine):

1. Google kan ikke lide værdier i URL'er.

2. Når man laver noget nyt, ændrer ens gamle URL'er sig.

Vil du forsvare dem?

--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

Martin Højriis Krist~ (10-12-2007)
Kommentar
Fra : Martin Højriis Krist~


Dato : 10-12-07 00:31

"Bertel Lund Hansen" <unospamo@lundhansen.dk> skrev i en meddelelse
news:07uol3dsvhcfcjr6ktejf4v2n3dcdluget@4ax.com...
> Vi beskæftiger os med to postulater (ikke dine):
> 1. Google kan ikke lide værdier i URL'er.

Det har jeg hørt men aldrig set dokumenteret, hvilket også ville være svært
med googles begrænsede offentlighed på det punkt.

> 2. Når man laver noget nyt, ændrer ens gamle URL'er sig.
> Vil du forsvare dem?

Jeg forsvarer det jeg sagde oprindeligt.. Hvis man holder op med at bruge
php så holder URL'er baseret på index.php?noget=noget typisk op med at
virke. Man kan sagtens lave en tilsvarende URL i et nyt sprog, men hvis man
alligevel vil afkoble navne-rummet fra teknologien, så kan man liges godt
gøre det nu.

--
Martin Højriis Kristensen
http://www.martinshjemmeside.dk/ - Lidt af hvert
http://www.mestomaarhus.dk/ - Mest om Århus



Martin (10-12-2007)
Kommentar
Fra : Martin


Dato : 10-12-07 05:38

Martin Højriis Kristensen wrote:
> "Bertel Lund Hansen" <unospamo@lundhansen.dk> skrev i en meddelelse
> news:07uol3dsvhcfcjr6ktejf4v2n3dcdluget@4ax.com...
>> Vi beskæftiger os med to postulater (ikke dine):
>> 1. Google kan ikke lide værdier i URL'er.
>
> Det har jeg hørt men aldrig set dokumenteret, hvilket også ville være svært
> med googles begrænsede offentlighed på det punkt.

Jeg har hørt det, men nej ikke på dokumentation, men nu er google jo
heller ikke særlig åbne omkring dokumentationen om deres søgemaskine :)

Lidt sjov morgen googling gav følgende...
index.php?page=
53.6 mio hits

index.php?id=
30.9 mio hits

imo så er der flere cm systemer der bruger id= end page= så jeg tror der
er en lille smule omkring det... måske :)

>
>> 2. Når man laver noget nyt, ændrer ens gamle URL'er sig.
>> Vil du forsvare dem?
>
> Jeg forsvarer det jeg sagde oprindeligt.. Hvis man holder op med at bruge
> php så holder URL'er baseret på index.php?noget=noget typisk op med at
> virke. Man kan sagtens lave en tilsvarende URL i et nyt sprog, men hvis man
> alligevel vil afkoble navne-rummet fra teknologien, så kan man liges godt
> gøre det nu.
>

mod_rewrite? (noget lign virker også på IIS, ved dog ikke lige hvad det
hedder der)

domæne.dk/page=foo
bliver til
domæne.dk/index.php?page=foo
(eller domæne.dk/index.html?page=foo)

Eller endnu bedre
domæne.dk/foo
bliver til
domæne.dk/index.php?page=foo
(eller domæne.dk/index.aspx?page=foo)

Så kan man skifte index.php ud med hvad man nu har lyst til med et
snuptag, uden at søgemaskinerne behøver at vide resten

Martin (10-12-2007)
Kommentar
Fra : Martin


Dato : 10-12-07 05:47

Martin wrote:
> mod_rewrite? (noget lign virker også på IIS, ved dog ikke lige hvad det
> hedder der)
>
> domæne.dk/page=foo
> bliver til
> domæne.dk/index.php?page=foo
> (eller domæne.dk/index.html?page=foo)
>
> Eller endnu bedre
> domæne.dk/foo
> bliver til
> domæne.dk/index.php?page=foo
> (eller domæne.dk/index.aspx?page=foo)
>
> Så kan man skifte index.php ud med hvad man nu har lyst til med et
> snuptag, uden at søgemaskinerne behøver at vide resten

Et rigtig godt eksempel er http://newz.dk (tryk på Læs mere, og se på
URL'en)

Desuden så slipper man også for alle de warnings på validatoren hvis man
bruger "rigtige" urls istedet for

domæne.dk/index.php?page=1&do=this&that=do
(2 warnings - desværre er der rigtig rigtig få webhoteller der har
udkommenteret linjen arg_separator.output i php.ini)

Kan omskrives til
domæne.dk/1/this/do

Fx. er man på index.php?id=1&do=that, så skriver
$_SERVER['REQUEST_URI']
ikke med &amp; istedet for & hvis arg_separator.output ikke er
udkommenteret - kan selvfølgelig hurtig klares med en str_replace, meeen
så er "real urls" lidt pænere, og sikkert også mere søgemaskinevenlige :)

Peter Brodersen (10-12-2007)
Kommentar
Fra : Peter Brodersen


Dato : 10-12-07 10:38

On Mon, 10 Dec 2007 05:46:40 +0100, Martin <martin@aarhof.eu.invalid>
wrote:

>Desuden så slipper man også for alle de warnings på validatoren hvis man
>bruger "rigtige" urls istedet for
>
>domæne.dk/index.php?page=1&do=this&that=do
>(2 warnings - desværre er der rigtig rigtig få webhoteller der har
>udkommenteret linjen arg_separator.output i php.ini)

Det har du nævnt før - men er det ikke blot fordi man skal bruge &amp;
i stedet for & ?

Det har ikke noget med selve URL'en at gøre, men snarere den måde, man
encoder værdier i HTML'en på.

Det samme er tilfældet med andre værdier, fx value til et input.
Følgende er fx ulovligt:

<input type="text" name="ugeblad" value="Se&Hør" />

--
- Peter Brodersen
Kendt fra Internet

Martin (10-12-2007)
Kommentar
Fra : Martin


Dato : 10-12-07 11:00

Peter Brodersen wrote:
> On Mon, 10 Dec 2007 05:46:40 +0100, Martin <martin@aarhof.eu.invalid>
> wrote:
>
>> Desuden så slipper man også for alle de warnings på validatoren hvis man
>> bruger "rigtige" urls istedet for
>>
>> domæne.dk/index.php?page=1&do=this&that=do
>> (2 warnings - desværre er der rigtig rigtig få webhoteller der har
>> udkommenteret linjen arg_separator.output i php.ini)
>
> Det har du nævnt før - men er det ikke blot fordi man skal bruge &amp;
> i stedet for & ?

Jep, men $_SERVER['REQUEST_URI'] så skal man smide den igennem en
str_replace før den validerer.

>
> Det har ikke noget med selve URL'en at gøre, men snarere den måde, man
> encoder værdier i HTML'en på.

Hvis man selv skriver sin URLs så skal man selvfølgelig gå ind og lave
&amp;s istedet - men hvor mange skriver URLs selv i CM systemer

>
> Det samme er tilfældet med andre værdier, fx value til et input.
> Følgende er fx ulovligt:
>
> <input type="text" name="ugeblad" value="Se&Hør" />
>

Enig... & er irriterende, og jeg synes nu stadig det er en "bug" i
validatoren, eller rettere jeg synes ikke den skulle give en error, men
bare en warning.

Peter Brodersen (10-12-2007)
Kommentar
Fra : Peter Brodersen


Dato : 10-12-07 18:28

On Mon, 10 Dec 2007 11:00:26 +0100, Martin <maaNO@SPAMscandesigns.dk>
wrote:

>> Det har du nævnt før - men er det ikke blot fordi man skal bruge &amp;
>> i stedet for & ?
>Jep, men $_SERVER['REQUEST_URI'] så skal man smide den igennem en
>str_replace før den validerer.

Det er så rigtigt nok. I praksis er det sjældent, jeg har oplevet at
det var et problem. Det mest oplagte sted, jeg lige kan se, er hvis
man skal klistre flere argumenter på den eksisterende url eller lade
en form submitte til sig selv.

Jeg tror, jeg har for vane altid at behandle QUERY_STRING for sig selv
med en passende fortolkning. Men REQUEST_URI kan jo betragtes som alt
andet brugerinput, som man fx bør smide igennem htmlspecialchars() alt
efter konteksten.

Det er ikke alle browsere, som urlencoder specialtegn (IE encoder fx
ikke <>"), så hvis du blot benytter REQUEST_URI uden videre, er din
hjemmeside sårbar over for XSS-angreb.

Så altså: du skal med al sandsynlighed alligevel bruge
htmlspecialchars() i de tilfælde.

>> Det har ikke noget med selve URL'en at gøre, men snarere den måde, man
>> encoder værdier i HTML'en på.
>Hvis man selv skriver sin URLs så skal man selvfølgelig gå ind og lave
>&amp;s istedet - men hvor mange skriver URLs selv i CM systemer

Det skal systemet helst gerne gøre for én, hvis man bruger et CMS.
Brugeren leverer generisk content, som så skal kodes tilsvarende, alt
efter om det skal bruges i HTML, i en mail, etc.

Så brugeren skal ikke bekymre sig om hvorvidt, &amp; er nødvendigt.

>> <input type="text" name="ugeblad" value="Se&Hør" />
>Enig... & er irriterende, og jeg synes nu stadig det er en "bug" i
>validatoren, eller rettere jeg synes ikke den skulle give en error, men
>bare en warning.

Altså, det er jo netop forskellen mellem om din HTML er gyldig eller
ej.
--
- Peter Brodersen
Kendt fra Internet

Søg
Reklame
Statistik
Spørgsmål : 177459
Tips : 31964
Nyheder : 719565
Indlæg : 6408195
Brugere : 218881

Månedens bedste
Årets bedste
Sidste års bedste