Contentbeheer, vaste pagina’s en footer

16.1 Doel

Contentbeheer maakt tekstuele inhoud beheerbaar zonder dat OefenHub verandert in een vrije pagebuilder.

Beheerders kunnen vooraf bepaalde contentblokken, footeronderdelen, URL-records en vaste publieke pagina’s beheren. De structurele paginaopbouw, blokvolgorde, componentkeuze, layout, renderlocaties, responsive gedrag en formulierlogica blijven codegedreven.

Dit hoofdstuk beschrijft de functionele grenzen rond:

• frontpagecontent;
• vaste publieke pagina’s;
• tekstuele footerinhoud;
• herbruikbare URL-records;
• footersecties;
• footerlinktoewijzingen;
• wijzigingshistorie;
• codegedreven structuur versus beheerbare inhoud.

16.2 Domeinafbakening

Onderdeel	Binnen scope	Buiten scope
Frontpagecontent	Tekstuele inhoud binnen bestaande frontpageblokken beheren.	Nieuwe frontpage-layouts, componenten of rolcombinatieontwerpen bouwen.
Vaste publieke pagina’s	Tekstuele blokinhoud van bestaande vaste pagina’s beheren.	Nieuwe vaste pagina’s of formulierlogica via de GUI toevoegen.
Footerinhoud	Tekstuele footertekst en footerlinktoewijzingen beheren.	Nieuwe footergebieden, kolommen of responsive layoutregels maken.
URL-records	Herbruikbare interne en externe links beheren en valideren.	Autorisatie, routeconfiguratie of navigatiestructuur wijzigen.
Geschiedenis	Wijzigingen aan content, links en footerplaatsingen herleidbaar tonen.	Algemene audit, accountlogging of technische deploymenthistorie vervangen.

Contentbeheer wijzigt geen rollen, relaties, autorisaties, oefeningen, resultaten, meldingen, systeemberichten, systeemnotificaties, popups of featuretoggles.

16.3 Uniform contentblokmodel

Voor frontpagecontent, vaste publieke pagina’s en tekstuele footerinhoud geldt één logisch contentblokmodel.

Contentblokken worden functioneel geïdentificeerd door:

Sleutel	Betekenis
DomainType	Het domein waarin het contentblok gebruikt wordt, bijvoorbeeld FrontPage, StaticPage of Footer.
ContextType	De rendercontext waarin het blok gebruikt wordt, bijvoorbeeld Public, NoRole, Admin, Teacher, Student of Guardian.
ReferenceKey	Codevaste verwijzing waarmee de applicatie weet welk blok op welke vaste plek getoond wordt.

Samen vormen DomainType, ContextType en ReferenceKey de functionele sleutel van een contentblok.

Beheerbare velden zijn tekstueel, zoals:

• titel;
• tekst;
• label;
• toelichting;
• knoptekst waar de bestaande codecontext dat ondersteunt.

Niet beheerbaar via het contentblokmodel zijn:

• layout;
• componenttype;
• volgorde;
• zichtbaarheid als vrij aan/uit-vinkje;
• nieuwe renderlocaties;
• nieuwe blokreferenties;
• nieuwe technische contexten;
• custom rendererlogica.

IsVisible is bewust geen onderdeel van het uniforme contentblokmodel. Een contentblok is dus geen featuretoggle en geen vrij schakelbaar layoutblok.

16.4 Ontbrekende contentblokken

Een productieomgeving mag functioneel zonder vooraf aangemaakte contentblokken starten.

Wanneer een verwacht contentblok ontbreekt:

• wordt het blok niet geladen of niet getoond;
• ontstaat geen automatische seed- of migratieactie;
• blijft de structurele paginaopbouw codegedreven;
• mag de pagina niet crashen door alleen het ontbreken van beheerbare tekstinhoud;
• kan beheer later het ontbrekende contentblok aanmaken of vullen via de daarvoor bedoelde beheerinterface, wanneer deze flow beschikbaar is.

Het ontbreken van een contentblok is dus geen autorisatiefout en geen bewijs dat de onderliggende pagina niet bestaat.

16.5 Geen vrije pagebuilder

Beheerders wijzigen inhoud, niet structuur.

Niet beheerbaar via de GUI zijn:

• blokvolgorde;
• kolomstructuur;
• componenttype;
• CSS of styling;
• responsive regels;
• layoutposities;
• custom rendergedrag;
• nieuwe frontpagegebieden;
• nieuwe vaste pagina’s;
• nieuwe footergebieden;
• nieuwe technische sleutelsets;
• nieuwe route- of formulierlogica.

Deze grens voorkomt dat contentbeheer impliciet verandert in een pagebuilder, routeringsbeheer of componentbeheer.

Wanneer de applicatie een nieuwe blokpositie, vaste pagina, footerstructuur of rendercontext nodig heeft, is dat een code- en documentatiewijziging en geen gewone beheeractie.

16.6 Frontpagebeheer

Frontpagebeheer werkt per basiscontext.

Ondersteunde basiscontexten zijn:

ContextType	Functionele context
Public	Niet-ingelogde publieke frontpage.
NoRole	Ingelogde gebruiker zonder actieve rolcontext.
Student	Leerlingfrontpage.
Guardian	Ouder-/voogdfrontpage.
Teacher	Docentfrontpage.
Admin	Beheerderfrontpage.

De beheerder kan binnen een basiscontext alleen bestaande beheerbare contentvelden wijzigen.

Gecombineerde rolfrontpages worden runtime samengesteld uit de onderliggende basiscontexten. Zij worden niet als aparte persistente ontwerpen beheerd.

Voor gecombineerde frontpages geldt:

• er is geen aparte contentset voor iedere rolcombinatie;
• de vaste prioriteit uit het FO blijft leidend;
• beheer wijzigt geen runtime-samenstellingslogica;
• controle van runtime-samenstelling is een raadpleeg- of previewactie, geen mutatie van rolcombinatieconfiguratie.

Zie ook Frontpages en overzichtsschermen.

16.7 Vaste publieke pagina’s

De beheerpagina Handige links & pagina’s ondersteunt tekstbeheer voor vaste publieke pagina’s.

Minimaal ondersteunde vaste publieke pagina’s zijn:

• Over OefenHub;
• Privacybeleid;
• Contact.

Deze pagina’s bestaan uit vaste codegedreven blokken met beheerbare tekstuele inhoud.

Beheer mag binnen deze pagina’s:

• bestaande tekstblokken vullen of wijzigen;
• bestaande titels of toelichtingen aanpassen waar toegestaan;
• wijzigingsgeschiedenis raadplegen;
• inhoud actualiseren zonder deploy.

Beheer mag niet:

• nieuwe vaste publieke pagina’s aanmaken;
• bestaande vaste pagina’s verwijderen;
• de route van vaste pagina’s wijzigen;
• blokken vrij verplaatsen;
• componenttypes wijzigen;
• formulierlogica wijzigen;
• het contactformulier technisch aanpassen;
• meldingen- of ticketlogica via contentbeheer wijzigen.

16.8 Over OefenHub

De pagina Over OefenHub is een vaste publieke pagina met beheerbare tekstblokken.

Deze pagina is bedoeld voor toelichting op:

• doel van OefenHub;
• doelgroep;
• achtergrond;
• werkwijze;
• algemene positionering van de applicatie.

De structuur, blokopbouw en route blijven codegedreven. Beheer wijzigt alleen de tekstuele inhoud binnen bestaande blokken.

16.9 Privacybeleid

De pagina Privacybeleid is een vaste publieke pagina met beheerbare tekstblokken rond privacy en gegevensverwerking.

Beheerbare inhoud kan onder meer betrekking hebben op:

• algemene privacyuitleg;
• gegevensverwerking;
• rollen;
• bewaartermijnen;
• contactinformatie;
• verwijzingen naar rechten of procedures.

Hoewel juridische tekst via beheer kan worden aangepast, blijft de structurele paginaopbouw vast. Contentbeheer is geen juridisch workflow- of akkoordensysteem.

16.10 Contact

De pagina Contact bevat beheerbare tekstuele blokken rond contactinformatie en toelichting.

Het contactformulier zelf valt buiten het vrije contentbeheer.

Dat betekent:

• omliggende tekst is beheerbaar;
• formulierlabels zijn alleen beheerbaar wanneer dit expliciet als beheerbaar veld is uitgewerkt;
• formulierroutering is codegedreven;
• validatie is codegedreven;
• verwerking van contactberichten of meldingen valt buiten deze pagina;
• de melding- of ticketflow wordt niet via contentbeheer aangepast.

Wanneer contactfunctionaliteit gekoppeld wordt aan meldingen, hoort die koppeling in het meldingen- of ticketdomein en niet in het contentblokmodel.

16.11 URL-records

URL-records worden vastgelegd als herbruikbare links.

Een URL-record bevat minimaal:

• linktype;
• weergavenaam;
• URL of interne route;
• openen in nieuw tabblad;
• aanmaak- en wijzigingsinformatie;
• soft-delete-informatie waar relevant.

Ondersteunde linktypen zijn:

LinkType	Betekenis
Internal	Interne route binnen OefenHub.
External	Externe URL.

Bij opslaan moet de URL functioneel gevalideerd worden.

Voor interne routes geldt dat zij moeten passen binnen de toegestane routevormen van OefenHub.

Voor externe URL’s geldt dat zij geldig en veilig genoeg moeten zijn volgens de vastgestelde validatieregels.

Opslaan mag niet slagen wanneer URL-validatie faalt.

16.12 Verwijderen van URL-records

URL-records worden logisch verwijderd via soft delete.

Een URL-record mag alleen verwijderd worden wanneer het niet actief gebruikt wordt in footerlinktoewijzingen.

Bij verwijderen geldt:

• bestaande actieve footerlinktoewijzingen blokkeren verwijdering;
• de URL verdwijnt na verwijdering uit de beheer-GUI;
• historie blijft behouden;
• verwijdering legt actor en tijdstip vast;
• de verwijdering verwijdert geen eerdere historyrecords.

Verwijderen van een URL-record is dus geen hard delete en geen wijziging van historische footerweergaven of auditinformatie.

16.13 Footerbeheer

De footer bestaat functioneel uit drie kolommen:

1. links;
2. midden;
3. rechts.

De desktopweergave toont deze kolommen naast elkaar. Bij smalle schermen worden zij onder elkaar geplaatst in deze volgorde:

1. midden;
2. rechts;
3. links.

Deze responsive volgorde is codegedreven en wordt niet door beheerders vrij aangepast.

16.14 Footercontexten

Footerinhoud is contextafhankelijk.

Voor footeropbouw worden dezelfde functionele contextwaarden gebruikt als bij contentblokken en frontpagecontent, zoals:

• Public;
• NoRole;
• Student;
• Guardian;
• Teacher;
• Admin.

De footercontext bepaalt welke tekstuele inhoud, secties en linktoewijzingen bij de actuele gebruikers- of rolcontext horen.

De contextbepaling blijft server-side en applicatiegedreven. Een beheerder maakt geen willekeurige nieuwe contexten aan via de GUI.

16.15 Linkerkolom

De linkerkolom bevat tekstuele footerinhoud, zoals:

• titel;
• korte toelichting;
• copyrighttekst;
• eventueel vaste contextuele tekst.

Deze tekstuele inhoud hoort bij het contentblokmodel met DomainType = Footer.

De linkerkolom gebruikt geen vrije lijst met URL-records zoals de middelste en rechterkolom. Wanneer later linkgedrag in de linkerkolom nodig is, moet dit expliciet worden uitgewerkt.

16.16 Middelste en rechterkolom

De middelste en rechterkolom werken via footersecties en linktoewijzingen.

Daarbij geldt:

• een footersectie bepaalt context, kolom en sectietitel;
• een footerlinktoewijzing koppelt een bestaand URL-record aan een footersectie;
• een footerlinktoewijzing bepaalt de volgorde binnen die sectie;
• dezelfde URL mag binnen dezelfde footersectie niet dubbel actief voorkomen;
• volgorde moet deterministisch zijn.

De beheerder kan bestaande of toegestane footersecties inhoudelijk beheren en URL-records koppelen volgens de toegestane beheerflow.

16.17 FooterSections

FooterSections beschrijven beheerbare secties binnen de footer.

Een footersectie bevat minimaal:

• context;
• kolomtype;
• sectietitel;
• aanmaak- en wijzigingsinformatie;
• soft-delete-informatie waar relevant.

Ondersteunde kolomtypes zijn:

ColumnType	Betekenis
Middle	Middelste footerkolom.
Right	Rechter footerkolom.

Binnen één context en kolom mag functioneel slechts één actieve footersectie bestaan, tenzij later expliciet een meervoudig sectiemodel wordt uitgewerkt.

16.18 FooterLinkAssignments

FooterLinkAssignments koppelen SiteLinks aan een FooterSection.

Een footerlinktoewijzing bevat minimaal:

• footersectie;
• URL-record;
• volgorde;
• aanmaak- en wijzigingsinformatie;
• soft-delete-informatie waar relevant.

Voor footerlinktoewijzingen geldt:

• alleen bestaande, niet-verwijderde URL-records mogen actief gekoppeld worden;
• dezelfde URL mag binnen dezelfde footersectie niet dubbel actief gekoppeld zijn;
• volgorde binnen een footersectie moet eenduidig zijn;
• verwijderen van een toewijzing is logisch en historisch herleidbaar;
• verwijderen van een toewijzing verwijdert het onderliggende URL-record niet.

16.19 Geschiedenis

Wijzigingen aan contentblokken, URL-records, footersecties en footerlinktoewijzingen moeten historisch herleidbaar zijn.

Minimaal vast te leggen zijn:

• actor;
• tijdstip;
• gewijzigd object;
• gewijzigd veld;
• oude waarde;
• nieuwe waarde;
• wijzigingstype waar relevant.

Voor contentblokken geldt dat wijzigingen op veldniveau herleidbaar moeten zijn.

Voor URL-records, footersecties en footerlinktoewijzingen geldt dat aanmaken, wijzigen en soft delete auditbaar moeten blijven.

Historyrecords worden niet door normale beheeracties aangepast of verwijderd.

16.20 Cache en publicatiegedrag

Wijzigingen aan beheerbare content moeten na opslaan consistent zichtbaar worden zonder applicatieherstart.

Daarom geldt:

• opslaan werkt wijzigingsmetadata bij;
• relevante cache wordt ververst of ongeldig gemaakt;
• de eerstvolgende render gebruikt de actuele server-side waarde;
• oude clientstate mag geen beheerwijziging blijven afdwingen;
• mislukte opslag mag geen gedeeltelijk bijgewerkte contentweergave opleveren.

Wanneer caching wordt toegepast, mag caching nooit een autorisatie- of contextgrens doorbreken. Footer- en contentwaarden moeten passen bij de actuele context van de gebruiker.

16.21 Relatie tot systeemnotificaties, popups en templates

Contentbeheer is gescheiden van systeemnotificaties, popups en systeemberichttemplates.

Domein	Doel
Contentbeheer	Beheer van tekstuele inhoud op vaste plekken.
Systeemnotificaties	Tijdelijke of geplande overlays boven frontpages.
Popups	Actie-, fout- of bevestigingsfeedback via popupkeys.
Systeemberichttemplates	Inhoudsbasis voor concrete mailbox-systeemberichten.
Featuretoggles	Aan- of uitschakelen van expliciet togglebare functies.

Contentblokken mogen niet worden gebruikt om systeemnotificaties, popups, systeemberichten of featuregedrag na te bootsen.

16.22 Lege toestanden en fouttoestanden

Lege toestanden zijn normaal wanneer er geen beheerbare inhoud of links binnen een view aanwezig zijn.

Voorbeelden:

• geen URL-records;
• geen footerlinks in een kolom;
• geen contentblokhistorie;
• geen wijzigingen binnen een periode;
• geen ingevulde tekst voor een optioneel contentblok;
• geen footersectie voor een context.

Fouttoestanden ontstaan wanneer:

• een verplichte URL ongeldig is;
• een interne route niet toegestaan is;
• een externe URL onveilig of ongeldig is;
• een URL-record nog gebruikt wordt en daarom niet verwijderd mag worden;
• een contentblok niet binnen een toegestane context valt;
• een ReferenceKey onbekend is;
• een footersectie dubbel ontstaat binnen dezelfde context en kolom;
• een footerlinktoewijzing dubbel ontstaat binnen dezelfde sectie;
• een wijziging niet historisch vastgelegd kan worden;
• opslag of cacheverversing faalt.

Bij fouttoestanden worden geen technische stacktraces, tokens, interne identifiers of onnodige technische details aan gewone gebruikers getoond.

16.23 Gerelateerde bronverwijzingen

Bron	Link
Technisch Ontwerp — domeinmodel	Domeinmodel en datamodel-overzicht
Technisch Ontwerp — databaseontwerp	Databaseontwerp, migraties, seeddata en constraints
Technisch Ontwerp — frontend Blazor	Frontend, Blazor, routing, state en componentopbouw
Usecases — frontpagebeheer	Frontpagebeheer
UC-BEH-FRONT-001 — Frontpagebeheer openen	Frontpagebeheer openen
UC-BEH-FRONT-002 — Frontpagecontext selecteren	Frontpagecontext selecteren
UC-BEH-FRONT-003 — Frontpage-contentblok bewerken	Frontpage-contentblok bewerken
UC-BEH-FRONT-004 — Frontpagewijziging opslaan	Frontpagewijziging opslaan
UC-BEH-FRONT-005 — Frontpagegeschiedenis bekijken	Frontpagegeschiedenis bekijken
UC-BEH-FRONT-006 — Runtime-samenstelling van gecombineerde frontpage controleren	Runtime-samenstelling van gecombineerde frontpage controleren
Usecases — handige links en vaste pagina’s	Handige links en vaste pagina’s
UC-BEH-LINKS-001 — Handige links en pagina’s openen	Handige links en pagina’s openen
UC-BEH-LINKS-002 — URL-record aanmaken of wijzigen	URL-record aanmaken of wijzigen
UC-BEH-LINKS-003 — URL-validatie uitvoeren	URL-validatie uitvoeren
UC-BEH-LINKS-004 — URL-record verwijderen	URL-record verwijderen
UC-BEH-LINKS-005 — Footertekst bewerken	Footertekst bewerken
UC-BEH-LINKS-006 — Footerlink-toewijzingen beheren	Footerlink-toewijzingen beheren
UC-BEH-LINKS-007 — Vaste publieke pagina bewerken	Vaste publieke pagina bewerken
UC-BEH-LINKS-008 — Wijzigingsgeschiedenis raadplegen	Wijzigingsgeschiedenis raadplegen
Schermdocumentatie — site instellingen frontpage	Site instellingen — frontpage
Schermdocumentatie — handige links en pagina’s	Handige links en pagina’s
Schermdocumentatie — Over OefenHub	Over OefenHub
Schermdocumentatie — Privacybeleid	Privacybeleid
Schermdocumentatie — Contact	Contact
Database-informatie — configuratie en contentbeheer	Configuratie en contentbeheer
Ontwerpbron — header, footer en navigatie	Header, footer en navigatie
FO — applicatieschil, header, footer en navigatie	Applicatieschil, header, footer en navigatie
FO — frontpages en overzichtsschermen	Frontpages en overzichtsschermen
FO — popups, templates, features en systeemnotificaties	Popups, templates, features en systeemnotificaties