webmanager-mvp/project_docs/UI_F2_RENAME_V1.md

UI_F2_RENAME_V1

1. Doel

Rename moet een expliciete eigen UI-flow krijgen via F2, los van de bestaande F6 move-flow.

Waarom:

• Rename is conceptueel een andere actie dan Move
• een eigen F2-flow sluit beter aan op klassieke file-manager bediening
• het maakt de UI voorspelbaarder: F2 = naam wijzigen, F6 = verplaatsen
• het vereenvoudigt later de verdere scheiding tussen rename en move in de UI, zonder backendwijziging

Bestaande context:

• rename-functionaliteit bestaat backendmatig al via het bestaande rename-endpoint
• move-functionaliteit bestaat backendmatig al via het bestaande move-endpoint
• F6/move-flow bestaat al in de UI
• in deze stap moet dus niets nieuws in backend of API worden ontworpen; alleen een nette eigen rename-flow in de frontend

2. Scope

In scope voor v1:

• exact 1 file geselecteerd
• exact 1 directory geselecteerd
• F2 keyboard shortcut
• Rename-knop in de functiebalk
• compacte rename-popup

Out of scope:

• batch rename
• rename van meerdere selectie-items
• herontwerp van F6
• backendwijzigingen
• nieuwe dependencies

3. Gewenst gedrag

F2 en de bestaande Rename-knop moeten exact dezelfde UI-flow gebruiken.

Voorstel:

• F2 keyboard shortcut activeert de rename-flow
• Rename-knop in functiebalk activeert exact dezelfde flow
• beide openen een compacte rename-popup

Popup-eigenschappen:

• titel: Rename
• toont context van het geselecteerde item
• invoerveld bevat alleen de huidige naam
• dus niet het volledige pad
• focus direct in het invoerveld
• tekst vooraf geselecteerd zodat overschrijven snel kan
• Enter bevestigt
• Escape annuleert
• X rechtsboven sluit de popup

Belangrijk semantisch verschil met F6:

• F2 Rename werkt op naamniveau binnen dezelfde parent
• de popup toont en bewerkt alleen de naam
• geen destination pad, geen implicit move-semantiek

4. Validatie

Frontendvalidatie in v1 moet klein blijven en vooral duidelijke UX geven. De backend blijft de bron van waarheid.

Frontend moet minimaal blokkeren of afvangen:

• lege naam
• ongewijzigde naam
• namen met /
• namen die triviaal ongeldig zijn zoals . of ..

Aanpak:

• lichte pre-validatie in de popup voor snelle feedback
• daarna altijd het bestaande rename-endpoint gebruiken
• backend-validatie blijft leidend voor definitieve afhandeling

Geen nieuwe rename-semantiek ontwerpen:

• geen padbewerkingen in de popup
• geen move-achtige fallback
• geen root- of parent-wijziging

5. Files en directories

Exact 1 file:

• rename toegestaan
• popup opent met huidige bestandsnaam
• bevestigen gebruikt bestaande backend-rename

Exact 1 directory:

• rename toegestaan
• popup opent met huidige mapnaam
• bevestigen gebruikt bestaande backend-rename

Meerdere geselecteerde items:

• in v1 niet ondersteunen
• F2 en Rename doen functioneel niets destructiefs
• aanbevolen UX: knop disabled bij selectedItems.length !== 1
• voor keyboardshortcut: geen actie als rename in de huidige context disabled zou zijn

Dit sluit aan op de bestaande regel dat keyboardshortcuts dezelfde enabled/disabled toestand moeten respecteren als de functiebalkknoppen.

6. Relatie met bestaande flows

Herbruik:

• bestaande backend rename-functionaliteit hergebruiken
• bestaande move-functionaliteit ongemoeid laten
• bestaande selectie- en active-pane-logica hergebruiken

Regels:

• F2 en Rename-knop delen exact dezelfde frontendflow
• F6 blijft ongewijzigd in deze stap
• bestaande F6 rename/move-popup wordt niet herontworpen in deze stap
• geen dubbele implementatie van backendlogica; alleen een aparte UI-laag voor rename

Pragmatische richting:

• introduceer een aparte compacte rename-popup
• submit roept hetzelfde backend-endpoint aan als de huidige renameknop al gebruikt
• succesvolle rename refresht alleen het actieve paneel, zoals nu al logisch is voor rename

7. Regressierisico

Belangrijkste risico's:

• selectieflow: F2 mag niet reageren bij ongeldige selectie
• popup-focus: paneelkeyboard mag niet doorwerken terwijl de rename-popup open is
• interactie met F6: geen verwarring of gedeelde state tussen rename-popup en bestaande rename/move-popup
• onbedoeld herbouwen van bestaande rename/move-logica in plaats van hergebruik

Mitigatie:

• F2 dezelfde disabled-context laten volgen als de Rename-knop
• aparte popup-state voor rename, niet hergebruik van de complexere F6 destination-popup
• bestaande backend-rename endpoint direct blijven gebruiken
• geen aanpassing aan F6 in deze stap

8. Teststrategie

UI smoke/regressietests:

• functiebalk bevat Rename met F2-hint
• rename-popupcontainer aanwezig in HTML
• rename-popup bevat invoerveld en sluitknop
• F2 wiring aanwezig in frontendcode
• bestaande F6 wiring blijft aanwezig

Handmatige validatie:

• exact 1 file geselecteerd -> F2 opent rename-popup met alleen naam
• exact 1 directory geselecteerd -> F2 opent rename-popup met alleen naam
• Enter bevestigt
• Escape sluit
• X sluit
• meerdere selectie -> F2 doet niets / rename blijft disabled
• succesvolle rename refresht actief paneel
• F6 move-flow blijft ongewijzigd werken

9. Aanbeveling

Aanbevolen v1-richting met laag regressierisico:

• voeg een aparte compacte rename-popup toe voor F2 en de Rename-knop
• werk alleen met de naam van exact 1 geselecteerd item
• gebruik het bestaande backend rename-endpoint zonder nieuwe semantiek
• laat F2 en de Rename-knop exact dezelfde flow delen
• laat F6 volledig ongemoeid in deze stap

Waarom dit de veiligste richting is:

• duidelijke scheiding tussen rename en move in de UI
• minimaal risico op regressie in bestaande move-flow
• geen backendwerk nodig
• sluit goed aan op klassieke file-manager verwachtingen