Taak 20: nieuwe display i.p.v. losse view, plus de horcat-valkuil

Bob vroeg of hij een losse view moet maken of de bestaande kopieren.
Beslissend: de app-kant is display-gebaseerd - HorecagelegenheidoverzichtCall
heeft de viewnaam hardcoded in de URL en alleen display_id is variabel. Een
losse view kost een nieuwe API-call plus een aanpassing aan de custom action;
een extra display kost alleen een andere parameterwaarde.

Gemeten valkuil: horcat= (leeg) geeft 0 items, niet 'alles'. De app stuurt
horcat altijd mee, dus het horcat-filter moet op de nieuwe display weg,
anders is de lijst gegarandeerd leeg.

Filter aangescherpt naar het specifieke veld field_hor_bez_ophaalbezorg
i.p.v. het generieke 'Has taxonomy terms'.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

TASKS.md

@@ -162,54 +162,69 @@ merkbaar (max 3), maar wel iets voor de livegang.
 krijg je een HTML-foutpagina in plaats van JSON, wat makkelijk voor "leeg"
 wordt aangezien.
 
-**Taak 20 (P1-5) · view `flutterflowmobiel_establishments` — "Thuis
-bezorgen".**
-Het drawer-menu heeft een item *Thuis bezorgen* dat nu nergens heen kan.
-De data bestaat: de vocabulaire **`thuisbezorgen_afhaalbezorgen`** heeft
-een term **"Bezorgen"**.
-1. Maak een **nieuwe Services-display** op deze view (wordt
-   `services_8` of hoger).
-2. Zet **Filter criteria** voor die display op **override** (anders raak je
-   alle andere displays!) en voeg toe: **Content: Has taxonomy terms** →
-   vocabulaire **`thuisbezorgen_afhaalbezorgen`** → term **"Bezorgen"**.
-3. De overige filters (published, type, `townid` exposed als
-   `term_node_tid_depth`) moeten blijven zoals in `services_1`, anders
-   werkt de plaatskeuze niet.
-4. **Velden hoeven niet aangepast**: de app heeft aan de bestaande set
-   genoeg (`nid, titel, adres, plaats, logo, categorie` — nagemeten
-   2026-09-10). Je hoeft `afhaalopties` dus niet toe te voegen; het
-   filter doet het werk.
-5. Geef Claude daarna het **`display_id`** door (= taak 26).
+**Taak 20 (P1-5) · "Thuis bezorgen" — nieuwe DISPLAY op
+`flutterflowmobiel_establishments`, geen losse view.**
+
+Bob's vraag 2026-09-11: losse view maken, of de bestaande kopiëren?
+**Antwoord: geen van beide — maak een nieuwe display op de bestaande view.**
+
+**Waarom dat beslissend is:** de app-kant is *display*-gebaseerd, niet
+*view*-gebaseerd. `HorecagelegenheidoverzichtCall` heeft de viewnaam
+**hardcoded in de URL**
+(`.../views/flutterflowmobiel_establishments.json`) en alleen
+`display_id` is variabel. Een losse view (of een kopie, want die krijgt een
+eigen machine name) betekent dus een **nieuwe URL → nieuwe API-call in
+FlutterFlow → aanpassing van de custom action** `fetchAlleHorecagelegenheden`.
+Een extra display kost aan de app-kant niets meer dan een andere
+parameterwaarde. Bijkomend voordeel: één view betekent één set velden, dus
+geen risico dat de twee uit elkaar gaan lopen (precies wat bij P1-45 met
+`categorie` gebeurde).
+
+**De display instellen:**
+1. Nieuwe **Services**-display (wordt `services_8` of hoger).
+2. **Filter criteria → override** (niet "All displays", anders krijgen de
+   zeven bestaande displays óók alleen nog bezorgers).
+3. Filter toevoegen op het **specifieke veld**:
+   **`field_hor_bez_ophaalbezorg`** ("Ophaal/Bezorgen", term reference naar
+   `thuisbezorgen_afhaalbezorgen`) → waarde **"Bezorgen"**. Gebruik dit
+   veldfilter en niet het generieke *Has taxonomy terms* — dan kun je niet
+   per ongeluk op dezelfde term in een ánder veld matchen.
+4. **Haal het `horcat`-filter weg op deze display** — zie de valkuil
+   hieronder.
+5. Laat `published`, contenttype en het exposed `townid` staan zoals in
+   `services_1`.
+6. Velden hoef je niet aan te raken: `nid, titel, adres, plaats, logo,
+   categorie` is genoeg (nagemeten 2026-09-10).
+
+⚠️ **Valkuil met `horcat`, gemeten 2026-09-11 — dit is waarom stap 4 nodig
+is.** De app stuurt `horcat` **altijd** mee, en een lege waarde betekent hier
+niet "geen filter":
+```
+horcat=17967        -> 75 items
+horcat=   (leeg)    ->  0 items   ← niet 'alles', maar niets
+horcat weggelaten   -> 100 items
+```
+De custom action kan de parameter niet weglaten, dus als het `horcat`-filter
+op de nieuwe display blijft staan krijg je gegarandeerd een lege lijst. Haal
+je 'm weg, dan wordt de meegestuurde waarde simpelweg genegeerd en hoeft er
+aan de app-kant niets te veranderen.
+
+7. Geef Claude daarna het **`display_id`** door (= taak 26).
+
+**Open ontwerpvraag voor Bob:** "Thuis bezorgen" is één lijst, terwijl
+`horecagelegenhedenOverzichtCurrent` uit zes categorietabs bestaat. Wil je
+die tabs daar ook, of liever een aparte, simpele lijstpagina? Dat bepaalt of
+Claude een `display_id`-page-parameter op de bestaande pagina zet (zes
+bindingen) of een nieuwe pagina bouwt.
 
 ⚠️ **Correctie 2026-09-11 op een eerdere aanname van Claude.** Ik schreef
-hierboven dat "het horeca-overzicht al een `display_id`-parameter accepteert".
-**Dat klopt niet** — ik haalde het door elkaar met `HomeUitgaantabelKaartComponent`,
-waar P1-44 die parameter wél heeft toegevoegd. De werkelijke stand van
-`horecagelegenhedenOverzichtCurrent` (ex-Copy3):
-- page parameter: **alleen `plaats`** (String), geen `display_id`;
-- de zes tabs roepen elk `fetchAlleHorecagelegenheden(<horcat>, plaats,
-  'services_1')` aan met een **hardcoded categorie-id** (17969, 17963, 34,
-  17965, 17967, 17968) én een hardcoded `'services_1'`.
-
-De custom action zelf heeft `displayId` wél al als derde argument en geeft
-'m door aan de API-call, dus de leiding ligt er — alleen de pagina vult 'm
-niet. **Gevolg: er is één app-stap extra nodig** die nog nergens stond:
-een page parameter `display_id` toevoegen en die op de zes aanroepen binden
-(met `services_1` als default, anders breken de bestaande routes).
-
-**En een ontwerpvraag die je eerst moet beantwoorden:** "Thuis bezorgen"
-levert één lijst op, terwijl deze pagina uit zes categorietabs bestaat. Wil
-je die tabs daar ook? Zo niet, dan is een aparte, simpele pagina (of
-dezelfde pagina met de tabbalk verborgen) waarschijnlijk netter dan deze
-pagina oprekken. Zeg wat je wilt, dan bouw ik het.
-
-⚠️ **Lees eerst de meting hieronder — dit filter is nu niet te testen.**
-Op 2026-09-11 staan er in heel Nederland **4 toekomstige evenementen**:
-3 in Valkenburg, 1 in Roermond. Per display: services_1 = 4, services_2 = 3,
-services_3 = 1, services_5 = 3, en services_4/6/7 = **0**. Een filter
-Vandaag / Dit weekend / Deze week valt daar niet op te controleren, en in de
-app zou het vrijwel altijd een lege lijst opleveren. Mijn advies: bouw het
-pas als er echte vulling is, of accepteer dat je het blind oplevert.
+eerder dat "het horeca-overzicht al een `display_id`-parameter accepteert".
+**Dat klopt niet** — ik haalde het door elkaar met
+`HomeUitgaantabelKaartComponent`, waar P1-44 die parameter wél kreeg. De
+pagina heeft **alleen `plaats`**; de zes tabs hardcoden elk een categorie-id
+(17969, 17963, 34, 17965, 17967, 17968) plus `'services_1'`. De custom action
+héést `displayId` wel al als derde argument, dus de leiding ligt er — alleen
+vult de pagina 'm niet.
 
 **Taak 21 (P2-1) · view `flutterflowmobiel1` — datumfilter Vandaag / Dit
 weekend / Deze week.**