Aantal vragen opzet CMS website
Ik ben bezig met het ontwerp van een site voor iemand. Het is de bedoeling dat zij straks zelf werknemers kan toevoegen bewerken en verwijderen. Verder moet ze wijzigingen kunnen aanbrengen in de tekst van de pagina's. Voorlopig nog niet zelf nieuwe maken of verwijderen dat komt wel als de site af is.
Het inlogscript heb ik al werkend (nog niet perfect beveiligd en met cookies/sessions ed maar dat komt later wel)
Nu moet ik dus verder. Mijn plan is om het zoals vele sites te maken, dus links menu, midden content en boven header waar ook kan worden ingelogd.
Voor de pagina's heb ik al twee tabellen gemaakt inclusief normaliseren.
PAGES:
pageID PRIMARY
title
url
content
view (wie de pagina mag zien) (doormiddel van een getal)
edit (wie de pagina mag wijzigen)
MENU:
pageID PRIMARY
inMenu PRIMARY (inMenu geeft aan in welk menu, ligt aan bevoegdheid user)
position
subPosition (als 0 dan is de pagina geen subpagina)
Het is de bedoeling dat een kopje in een menu kan een subpagina hebben, maar een subpagina zelf kan geen subpagina hebben.
Vraag 1:
Heb ik mijn normalisatie goed gedaan? Zo nee, wat is er fout? Zo ja, kan het nog beter?
Vraag 2:
Het verschil tussen een interface implementeren, of een abstracte class extenden duizelt me een beetje op het moment. Welke manier moet ik gebruiken als ik een interface/abstracte class Pagina wil implementeren/extenden. Dus bijv. public class Info implements/extends Pagina?
Voor de duidelijkheid ik kan prima in c++ en java programmaren (in java ook OOP), OOP ken ik nu ruim een jaar, kan ik redelijk maar niet super goed, kan wel implementeren, extenden en met abstracte classes werken, maar vindt het soms nog wel lastig te zien welke ik moet gebruiken. Verder heb ik ook al een paar keer gebruik gemaakt van MVC in java (bijvoorbeeld met het maken van een spelletje).
Bedankt dat je de moeite hebt genomen dit bericht te lezen en ik hoop dat iemand me kan helpen:)
Toevoeging op 24/02/2012 11:35:44:
O ja wat ik vergeten te vragen ben, is het de bedoeling dat ik in het veld 'content' van de tabel PAGES alle output van de pagina zet, die dan ophaal met een class functie output en dat dan echo?
Gewijzigd op 24/02/2012 18:18:14 door Lisse Veu
Qua database normalisatie... voor mijn gevoel mis je nog wel een aantal velden! Het menu kun je op deze manier bijvoorbeeld ook niet nesten, wat vaak wel heel handig is! :)
Qua implementatie: Ik heb het gevoel dat je veel te moeilijk denkt. Probeer het eerst een procedureel werkend te krijgen zodat je de basis helemaal snapt. Dat is bij korte stukjes code toch wat overzichtelijker. Later kun je het altijd nog OOP maken! :) Eerst de basis dus, dan mooi! :)
Output kun je gewoon echoën :)
Gert Wierbos:
Probeer het eerst een procedureel werkend te krijgen zodat je de basis helemaal snapt. Dat is bij korte stukjes code toch wat overzichtelijker. Later kun je het altijd nog OOP maken! :) Eerst de basis dus, dan mooi! :)
Dit ben ik niet van mening. Als je OO kan moet je gewoon meteen in 1 keer met OO werken. Waarom eerst iets maken wat je later toch weer helemaal moet gaan vervangen en anders schrijven?
Lisse Veu:
Het verschil tussen een interface implementeren, of een abstracte class extenden duizelt me een beetje op het moment. Welke manier moet ik gebruiken als ik een interface/abstracte class Pagina wil implementeren/extenden. Dus bijv. public class Info implements/extends Pagina?
Een abstracte klasse kan ook gewoon normaal properties bevatten, een interface kan alleen maar aangeven welke methods er in de klasse moeten zitten. Even 2 voorbeelden waarin je een OO script met een interface ziet en eentje met een abstracte klasse:
- Storage met interfaces
- Logging klasses met abstracte klassen
Wouter J op 27/02/2012 12:12:16:
Waarom eerst iets maken wat je later toch weer helemaal moet gaan vervangen en anders schrijven?
Omdat ik het gevoel heb dat Lisse Veu veel te moeilijk denkt en dat hij/zij beter even terug kan gaan naar de basis, zodat het voor hem/haar helemaal duidelijk is wat er gebeurt en wat er geschreven moet worden. Het klinkt gewoon alsof er veel te veel onduidelijkheden zijn :) Als je die onduidelijkheden wegneemt dan kan je het mooi maken. Is meer werk, maar waarschijnlijk krijg je dan veel betere code!
De modale programmeur in java en c++ kent de principes van OOP.
OOP maakt het trouwens juist gemakkelijker om abstract/conceptueel te werken.
In plaats van eerst de class te schrijven, kan je ook eerst doen alsof de class bestaat.
bv. een gastenboek. Gewoon even nadenken over "Wat doet zo'n ding?"
Code (php)
En dan moet je maar Guestbook invullen; zien dat Guestbook intern alles regelt.
Alles wat je hier boven ziet van functies, zullen public zijn; alle andere dingen zullen waarschijnlijk private (of protected) moeten zijn.
Gewijzigd op 27/02/2012 14:42:59 door Kris Peeters
Tip van Kris, klinkt goed. Daar ga ik maar eens mee beginnen.
En ik moet zeggen dat ik het niet zo zie zitten om het eerst in niet OO te doen en dan om te gaan schrijven. Is het een idee om eerst een class-diagram te maken met UML? Of is dat overbodig voor zo'n website?
Ik krijg nu iig vooral het idee dat ik gewoon moet beginnen met schrijven en dan kan ik het altijd nog verbeteren.