Page nav class, er dette smart?

Synes det lyder ambitiøst. Men er lidt bekymret doe serverens mulighed for at cache...

Hvad er det, præcis, du ønsker at opnå med sådan en "loader" ?
- templates, eller customisérbarhed (for brugerne) ?

doe = for

Det er udelukkende for at lette programmeringen af sitet, ja og så for at lære oop også ;-)

men om man henter en side(del) ved index.php?action=noget
og derefter laver noget ala, if action = noget i sin kode og så skal gøre det for hver action eller om man har lavet sådan en class det er vel det samme sådan cache mæssigt?

min tanke med det her var bare at jeg ikke skulle kode ny kode for hver action jeg tilføjer (andet end selve den side der skal hentes selvfølgelig)

jeg ved ikke så meget om server cache
men jeg forestiller mig da at en cache funktion cache'r både
side.php og side.php?action=noget som fuld serveret html sider og så skulle der vel ikke være nogen problemer med caching?

Nu bliver sitet jeg er gået i gang med heler ikke verdens største så som sådan er det nok ikke noget problem :-)

før i tiden lavede jeg en switch/case for hver action, bla. det sparer jeg på den her måde....

men tak for input om caching havde jeg ikke lige tænk på kunne være en faktor :-)

Hvis det er for at lære OOP er du allerede ude på et sidespor.
Formålene med OOP er at opnå indkapsling, polymorfi og nedarvning for dermed at nå et større mål; nemlig kodegenbrug og minimering af vedligehold.

Et par ting som så er at notere mig:
I din pageNav::__construct() forudsætter du at det altid er en $_GET variabel indekseret 'a' som angiver klassens $action variabel.
Det låser brugeren til at konsekvent anvende $_GET['a'] til sideangivelser. Hvis jeg nu hellere ville bruge $_SERVER["PATH_INFO"] måtte jeg skrive dit objekt om. Det øgede vedligeholdelsen og mindskede fleksibiliteten.

whichPage::loadPage er allerede taintet her, idét de dårlige forudsætninger fra parent klassen er indopereret - udover det faktum at du har harcoded stier til de angivne sider der skal være tale om. Medmindre du er ved at kode et større framework (hvilket det ikke tyder på, med så lille en router) så giver det ikke meget mening - det bør være muligt at angive via en konfiguration, simpel variabel eller lignende istedet for at have to hardcodede stier i den samme funktion.

Ydermere giver nedarvningen ikke umiddelbar mening, men jeg håber du kan forklare formålet?

#1
Hvorfor er du bekymret for muligheden for caching?

Ikke fordi jeg ved en hel masse om det, men caching handler om at serveren kan have ting "liggende klar" i memory - og ikke skal ned på disken og hente dem.
- det kan den vel dårligt, hvis de først skal beregnes... Jeg ku' tage fejl : )

#6
Caching er jo - som du siger - for at undgå at lade maskineriet arbejde mere end højst nødvendigt.

Det kan man gøre på mange måder; den mest anvendte findes i form af at tunge sider, som tager tid at generere, dannes som en statisk fil der bare hentes frem når den kaldes.

Altså, noget simpelt ala (pseudo):


Simpelt, men utroligt effektivt.

Der findes masser af muligheder for mere specifik caching - APC og memcache eksempelvis, men så er fokus et andet sted, hvor optimering af kode oftest kan løse mere.

Ja, "hjemmelavet caching" kan spare enormt, til "menuer" f.eks. som kun sjændent ændrer sig.

Jeg har engang været med til at levere søgeresultater på den måde!
Der var tusinder af søgninger hver dag i en enorm (næsten statisk) database.
En analyse viste at alle søgte efter mere eller mindre det samme (ca. 150 queries)
- Mon ikke man ku' spare lidt strøm ved at ... Det ku' man!

Men jeg tænkte mere på den "automagiske" caching.
Flade .html og .js filer, som serveren bare skal levere, as is - kan caches helt ude på "netværks-komponenterne" (og hos brugerne selvfølgelig)

#4
Jo, jeg ved godt OOP er for nedarvning, poly og kodegenbrug og deslige..... men i en OOP læreproces regner jeg ikke lige med at skrive den nye form check superclass der vil blive brugt world wide ;-)

at jeg bruger $_GET ['a'] er jo som en standard variabel til pageload actions i klassen, det er jo en pageload klasse og ikke en alt omkring $_GET på siden klasse.... en eller anden varialbel skal jeg jo bruge....

mht. til hardkodning at stier osv. så er klassen jo først på baby stadiet og er da nogle ting der skal rettes, og ja det er læring mens jeg koder, men mht. kode genbrug ville klassen da når den var færdig godt kunne bruges andre steder hvis man valgte at lave en side/mappe struktur der passede til den....

Men OOP handler vel også om at gøre kodning effektiv og som sitet vokser vil sådan en klasse da alligevel spare mig meget tid mht. at jeg ikke skal lave en masse if ($_GET['xxx'] = xxx) then gør dit og dat

læser da hvad jeg nu kan overskue om OOP, og sådan i bedste fald kan det her vel godt kaldes for en del af et "stucture layer"
Ja hvad ved jeg, men altid godt med input....

mht. om nedarvningen giver mening så er jeg på bar bund, læste forskelligt mens jeg prøvede at lave det, men jeg kunne ikke få
whichPage::loadPage() til at virke uden den nedarvning, fordi construteren fra en klasse jo ikke bliver kaldt uden en instantiering af klassen, så det lader ikke til at kunne lade sig gøre at lave den static function og få den til at virke uden den nedarvning.... fortæl gerne hvordan hvis det er muligt :-)

argh sikke en smøre.... lol.... tror sengetid nærmer sig

"at jeg bruger $_GET ['a'] er jo som en standard variabel til pageload actions i klassen, det er jo en pageload klasse og ikke en alt omkring $_GET på siden klasse.... en eller anden varialbel skal jeg jo bruge...."
Ja - brug en parameter til din __construct() så du slipper for at låse din bruger og dit objekt.

"Men OOP handler vel også om at gøre kodning effektiv og som sitet vokser vil sådan en klasse da alligevel spare mig meget tid mht. at jeg ikke skal lave en masse if ($_GET['xxx'] = xxx) then gør dit og dat"

Det er en misforstået idé du har om brugen af OOP. OOP giver dig, ganske rigtigt, effektiv kodning. Men hvis du bare bruger OOP for at pakke if-sætninger og slippe for at echo de samme ting ud hele tiden, så vinder du intet ved at bruge OOP frem for almindelige funktioner eller bare procedural kode.

"mht. om nedarvningen giver mening så er jeg på bar bund, læste forskelligt mens jeg prøvede at lave det, men jeg kunne ikke få
whichPage::loadPage() til at virke uden den nedarvning, fordi construteren fra en klasse jo ikke bliver kaldt uden en instantiering af klassen, så det lader ikke til at kunne lade sig gøre at lave den static function og få den til at virke uden den nedarvning.... fortæl gerne hvordan hvis det er muligt "

Din nedarvning giver ikke mening, fordi din opdeling er ulogisk. At du ikke kunne få fat i den interne variabel giver meget god mening - i hvert fald hvis man kigger på koden... personen der har tænkt strukturen er dog den eneste der kan give forklaring på det overordnede formål.

Der er ingen grund til den faktiske opdeling. whichPage::loadPage giver dig ingen fordel i forhold til at kombinere klasserne - og er der en grund til at funktionen er statisk? Eller er det også noget du læste dig frem til?