Mooi Stijn. Dan gaan we door naar de volgende CAMTE-bouwlaag.
We hebben nu:
✅ CAMTE 1.1 — Cloud Architecture & Multi-Tenant visie
✅ CAMTE 1.2 — Identity & User Management Engine
✅ CAMTE 1.3 — Database Engine & Google Cloud Data Layer
Nu bouwen we de verbinding tussen de webview (index.html) en de database.
De API-laag zorgt ervoor dat:
de webpagina gegevens kan opvragen;
gebruikers gegevens kunnen opslaan;
wijzigingen gecontroleerd worden;
alle modules dezelfde communicatie gebruiken.
De HTML praat nooit direct met Google Sheets.
INDEX.HTML
│
│ google.script.run
▼
Code.gs
│
▼
Router.gs
│
┌────────────┼────────────┐
▼ ▼ ▼
Players.gs Planning.gs Users.gs
│ │ │
▼ ▼ ▼
Database.gs
│
▼
Google Spreadsheet
Code.gs is de voordeur van de WebApp.
Het regelt:
HTML laden;
API-aanvragen ontvangen;
algemene instellingen.
Wanneer iemand de website opent.
Flow:
Gebruiker opent:
padelschool-os
↓
doGet()
↓
index.html
↓
WebApp geladen
Voor HTML onderdelen.
Bijvoorbeeld:
index.html
+
dashboard.html
+
players.html
+
style.css
worden samengevoegd.
Dit is de verkeersregelaar.
Alles komt hier binnen.
Voorbeeld:
HTML vraagt:
getPlayers
Router bepaalt:
getPlayers
↓
Players.gs
↓
Database.gs
↓
Sheet Players
Router.gs
route(action,data)
switch(action)
getPlayers
savePlayer
updatePlayer
getPlanning
saveLesson
getDashboard
CAMTE gebruikt acties.
Bijvoorbeeld:
USER_LOGIN
USER_CREATE
USER_UPDATE
USER_DELETE
PLAYER_GET
PLAYER_CREATE
PLAYER_UPDATE
PLAYER_ARCHIVE
PLAYER_SEARCH
PLANNING_GET
BOOKING_CREATE
BOOKING_UPDATE
BOOKING_CANCEL
LESSON_CREATE
LESSON_UPDATE
LESSON_COPY
LESSON_COMPLETE
Iedere actie geeft hetzelfde formaat terug.
Bijvoorbeeld:
Succes:
{
"success":true,
"message":"Player saved",
"data":{
"id":"PLY-000001"
}
}
Fout:
{
"success":false,
"message":"Permission denied"
}
Waarom?
Omdat de frontend altijd weet wat hij moet doen.
Iedere API-call gaat eerst door Security.
Bijvoorbeeld:
Trainer wil speler aanpassen.
Flow:
HTML
↓
Router
↓
Security.checkPermission()
↓
Players.update()
↓
Database.update()
↓
Logger.log()
↓
Resultaat terug
We maken de eerste echte endpoint:
getDashboard()
Deze verzamelt:
aantal spelers;
aantal trainers;
aantal lessen;
planning vandaag;
openstaande acties.
Resultaat:
{
"players":25,
"trainers":4,
"lessonsToday":12,
"pendingInvoices":3
}
index.html:
google.script.run
.withSuccessHandler(showDashboard)
.getDashboard();
Apps Script:
index.html
↓
Code.gs
↓
Router.gs
↓
DashboardService
↓
Database.gs
↓
Google Sheet
Voor overzicht voegen we toe:
Services/
DashboardService.gs
PlayerService.gs
TrainerService.gs
PlanningService.gs
InvoiceService.gs
Waarom?
Omdat Router niet zelf de logica moet uitvoeren.
Router verwijst alleen door.
Apps Script
├── Code.gs
├── Router.gs
├── Config.gs
├── Database.gs
├── Security.gs
├── Logger.gs
├── Users.gs
├── Roles.gs
├── Permissions.gs
├── Services
│
├── DashboardService.gs
├── PlayerService.gs
├── TrainerService.gs
├── PlanningService.gs
├── InvoiceService.gs
├── Models
├── PlayerModel.gs
├── TrainerModel.gs
├── LessonModel.gs
Open WebApp.
Verwacht:
✅ index.html verschijnt
Dashboard laden.
Verwacht:
✅ gegevens uit Sheet zichtbaar
Nieuwe speler maken.
Verwacht:
✅ speler toegevoegd
✅ ID aangemaakt
✅ logregel gemaakt
Onbevoegde gebruiker.
Verwacht:
❌ toegang geweigerd
Klaar wanneer:
✅ WebApp opent via Apps Script
✅ Router werkt
✅ API structuur bestaat
✅ HTML kan data ophalen
✅ HTML kan data opslaan
✅ Security controleert acties
✅ Logging werkt
✅ Dashboard endpoint werkt
We hebben nu:
CAMTE
1.1 Architectuur
1.2 Identity
1.3 Database
1.4 API + Router
De belangrijkste technische lagen staan.
Hier bouwen we jouw eerdere idee verder uit:
"Maak nieuwe trainer → maak automatisch omgeving."
Daar ontwerpen we:
automatisch nieuwe traineromgeving;
rechten toewijzen;
Google Drive map maken;
optioneel spreadsheet maken;
standaard lesbibliotheek koppelen;
agenda koppelen;
facturatie omgeving activeren.
Dit wordt de eerste echte "magische" CAMTE functie.
Dit is precies het moment waarop het project interessanter wordt. Tot nu toe hebben we losse modules gemaakt. Vanaf Sprint 1.4 gaan we de kernarchitectuur bouwen waarop alle volgende 46 sprints kunnen steunen.
Ik zou hierbij wel een belangrijke wijziging maken ten opzichte van de eerdere opzet.
De eerdere versie gebruikte rechtstreeks localStorage en losse arrays zoals DB.players. Dat is prima voor een prototype, maar als je uiteindelijk een systeem wilt met spelers, trainers, planning, evaluaties, AI en Google Sheets, dan ga je veel code moeten herschrijven.
Daarom zou ik Sprint 1.4 anders opzetten.
Alle modules gebruiken één centrale Data Engine.
Interface
│
Router
│
Modules
│
CRUD Engine
│
Data Engine
│
Storage Adapter
│
LocalStorage
Google Sheets
Firebase
Supabase
Hierdoor hoef je later alleen de onderste laag te vervangen als je van LocalStorage naar Google Sheets of Supabase wilt.
js/
app.js
router.js
core/
dataEngine.js
crud.js
storage.js
state.js
modules/
dashboard.js
players.js
trainers.js
groups.js
planning.js
Dat maakt de code veel overzichtelijker.
In plaats van:
DB.players.push(...)
werken alle modules straks zo:
Data.create("players", player);
of
Data.update("players", id, changes);
of
Data.delete("players", id);
Daardoor weten de modules helemaal niet meer waar de data vandaan komt.
De CRUD Engine krijgt vier standaardfuncties:
Create
Read
Update
Delete
Later gebruiken alle modules exact dezelfde functies.
Bijvoorbeeld:
Spelers
Trainers
Groepen
Lessen
Planning
Oefeningen
Evaluaties
zonder extra code.
We introduceren één centrale state:
State = {
user:{},
players:[],
trainers:[],
groups:[],
planning:[],
lessons:[]
}
Elke wijziging gebeurt eerst in de State.
Daarna wordt opgeslagen.
Daarna wordt de interface opnieuw opgebouwd.
Dit patroon voorkomt veel synchronisatieproblemen.
Elke module krijgt dezelfde structuur:
players/
players.list()
players.show()
players.create()
players.edit()
players.delete()
players.search()
players.filter()
Hetzelfde geldt straks voor trainers, groepen en planning.
De kaarten worden niet meer hard gecodeerd.
Bijvoorbeeld:
Spelers:
48
↓
DB.players.length
Of:
Lessen vandaag
↓
Planning.today().length
Daardoor werkt het dashboard automatisch mee met de gegevens.
Vanaf deze sprint krijgt iedere module dezelfde mogelijkheden:
🔍 Zoeken op naam
🎯 Filter op niveau
👤 Filter op trainer
📅 Filter op datum
🏟️ Filter op locatie
Je hoeft dit daarna niet per module opnieuw te bouwen.
Na Sprint 1.4 is de fundering klaar voor:
Dashboard met live statistieken
Drag-and-drop planning
Google Sheets-koppeling
Export naar PDF, TXT en WhatsApp
AI Coach
Radar Charts
Lesgenerator
Evaluaties
Videoanalyse
Na Sprint 1.4 heb je niet alleen een HTML-pagina, maar de eerste versie van een softwareframework voor Padelschool OS.
In plaats van direct verder te gaan met losse functionaliteit, bouwen we in Sprint 1.5 een Enterprise Foundation:
Core Engine (eventbus, state, services)
Component Library (herbruikbare kaarten, formulieren, tabellen, modals)
API Layer (klaar voor LocalStorage én Google Sheets)
Plugin System (zodat AI Coach, Planning, Evaluaties en andere modules eenvoudig kunnen worden toegevoegd)
Dat kost iets meer werk aan het begin, maar voorkomt dat we later grote delen van de applicatie moeten herschrijven wanneer Padelschool OS uitgroeit tot een compleet platform.
Versie: 1.0 – Foundation
Sprint: 1 van 50
Status: In ontwikkeling
Padel is één van de snelst groeiende sporten ter wereld. Steeds meer spelers, trainers, clubs en padelscholen werken dagelijks met verschillende applicaties voor planning, communicatie, betalingen, reserveringen, trainingen en administratie.
Deze systemen functioneren vaak goed binnen hun eigen specialisme, maar sluiten onvoldoende op elkaar aan. Hierdoor ontstaan dubbele invoer, versnipperde informatie, tijdverlies en een gebrek aan overzicht.
PadelSchool OS is ontwikkeld vanuit de overtuiging dat de toekomst niet ligt in nóg een losse applicatie, maar in een open en modulair platform dat bestaande oplossingen met elkaar verbindt en tegelijkertijd nieuwe mogelijkheden biedt op het gebied van coaching, communicatie, planning, administratie en kunstmatige intelligentie.
Wij geloven dat iedere speler beter kan leren, iedere trainer efficiënter kan coachen en iedere padelschool professioneler kan organiseren wanneer alle informatie samenkomt in één intelligent platform.
PadelSchool OS wordt de digitale werkomgeving waarin spelers, trainers, clubs, padelscholen en partners samenwerken vanuit één centrale omgeving.
Het platform ondersteunt niet alleen de dagelijkse werkzaamheden, maar helpt ook bij groei, kennisdeling en continue ontwikkeling.
Onze missie is het ontwikkelen van het meest complete digitale Operating System voor de internationale padelwereld.
Een platform dat:
spelers ondersteunt in hun persoonlijke ontwikkeling;
trainers helpt betere lessen te geven;
administraties tijd bespaart;
clubs en padelscholen overzicht biedt;
communicatie vereenvoudigt;
AI inzet als slimme assistent;
bestaande software koppelt in plaats van vervangt.
PadelSchool OS wordt ontwikkeld samen met trainers, spelers, clubs, ontwikkelaars en partners.
Iedere module moet bijdragen aan een betere sportervaring.
Complexe processen worden eenvoudig gemaakt.
Waar mogelijk ondersteunt het platform integraties met bestaande software.
AI, automatisering en data-analyse worden ingezet om mensen te ondersteunen, niet te vervangen.
Het platform groeit mee met spelers, trainers, organisaties en de internationale ontwikkeling van padel.
Vandaag werken veel organisaties met een combinatie van:
Excel
Google Sheets
Google Calendar
Boekhoudsoftware
Clubsoftware
Reserveringssystemen
Losse documenten
Papieren aantekeningen
Daardoor ontstaan onder andere:
dubbele administratie;
ontbrekende informatie;
versnipperde communicatie;
onvoldoende inzicht in voortgang;
beperkte samenwerking;
tijdverlies voor trainers en administratie.
PadelSchool OS brengt al deze processen samen in één geïntegreerd platform.
Het systeem fungeert als digitale schakel tussen:
spelers;
trainers;
teams;
groepen;
padelscholen;
clubs;
administraties;
partners;
AI;
externe software.
Persoonlijke planning
Leerdoelen
Evaluaties
Video's
Communicatie
Betalingen
Voortgang
Agenda
Lesplanning
Lesvoorbereiding
Evaluaties
AI Coach
Facturatie
Kennisbibliotheek
Organisatie
Trainers
Planning
Kwaliteitsbewaking
Rapportages
Communicatie
Leden
Banen
Trainers
Evenementen
Toernooien
Dashboard
Betalingen
Facturen
Contracten
Lespakketten
Rapportages
Integraties
API
Marketplace
Sponsoring
PadelSchool OS is geen reserveringssysteem.
PadelSchool OS is geen boekhoudpakket.
PadelSchool OS is geen CRM.
PadelSchool OS is geen chatapp.
PadelSchool OS is geen AI-tool.
PadelSchool OS is de digitale laag die al deze onderdelen met elkaar verbindt.
Planning, agenda's, lessen, locaties en teams.
Lessen, oefeningen, evaluaties en AI-ondersteuning.
Chats, meldingen, documenten en kennisdeling.
Gebruikers, facturen, betalingen en rapportages.
Academy, certificering, kennisbank en analyses.
PadelSchool OS groeit uit tot een internationaal platform waarop:
padelscholen samenwerken;
trainers kennis delen;
spelers zich ontwikkelen;
AI ondersteuning biedt;
partners nieuwe diensten aanbieden;
ontwikkelaars integraties bouwen;
sportorganisaties data en inzichten benutten om de kwaliteit van de sport te verhogen.
Bij iedere nieuwe functie stellen we de volgende vragen:
Helpt dit de speler?
Helpt dit de trainer?
Helpt dit de organisatie?
Kan dit gekoppeld worden aan bestaande software?
Is het eenvoudig te gebruiken?
Is het schaalbaar?
Kan AI hier waarde toevoegen?
Is het veilig en privacyvriendelijk?
Kan het internationaal worden toegepast?
Draagt het bij aan de kwaliteit van de padelsport?
Aan het einde van Sprint 1 ligt het fundament vast waarop alle volgende sprints voortbouwen.
We hebben een duidelijke visie, een gedeelde taal, een strategische richting en een set ontwerpprincipes die iedere technische en functionele keuze ondersteunen.
Na Sprint 1 zijn de volgende onderdelen vastgesteld:
✔ Productvisie
✔ Missie en kernwaarden
✔ Probleemdefinitie
✔ Doelgroepen
✔ Strategische positionering
✔ Lange termijnvisie
✔ Ontwikkelprincipes
✔ Fundament voor Sprint 2
In plaats van alleen een "UI Design System" wil ik de volledige gebruikerservaring (UX) van PadelSchool OS ontwerpen. We werken dan alle schermen uit: de nieuwe index.html, de sidebar, topbar, dashboards, kaarten, tabellen, formulieren, mobiele weergave en navigatie. Dat ontwerp wordt vervolgens de blauwdruk voor alle HTML-, CSS- en JavaScript-code die we in de daaropvolgende sprints gaan ontwikkelen. Daarmee voorkomen we dat we later opnieuw grote delen van de interface moeten aanpassen.