včera 17:45

Joyee, pokračujeme v projekte Magazín. Naväzuj na koncepciu interaktívneho vizuálneho magazínu, ktorú sme práve rozpracovali: WordPress ako základ, jednoduchá téma, vlastné pluginy iba tam, kde bezplatné nástroje nestačia, redakčné „sadzačské zrkadlo“, klasifikácia dôležitosti článkov, obrázková navigácia s náhľadmi cieľových stránok, dynamické listovanie/leporelo/noviny, prirodzené ovládanie myšou a dotykom a možnosť neskoršieho využitia Babylon.js. Projekt má byť navrhnutý modulárne tak, aby jednotlivé časti mohli implementovať rôzne AI nástroje. Najprv chceme vytvoriť architektúru a MVP, nie hneď programovať všetko.

Áno, Slavo. A myslím, že teraz je dôležité neísť do kódu, ale najprv si urobiť kostru systému tak, aby nás WordPress ani konkrétny AI nástroj neskôr nezamkol.

Z toho, čo sme rozpracovali, by som Magazín chápala ako vizuálny publikačný systém nad WordPressom, nie ako ďalšiu „peknú WordPress tému“.

1. Základná architektúra

Vidím tam šesť pomerne samostatných vrstiev:

A. WordPress / obsah

články
stránky
kategórie
médiá
autorstvo
základné metadáta

To necháme čo najviac natívne. WordPress je tu databáza a redakčný základ, nie miesto, kde budeme všetko prerábať.

B. Klasifikačná vrstva
Tu vznikne náš vlastný model článku.

Nie iba:

kategória → článok

ale napríklad:

článok → význam → priorita → vizuálna úroveň → vzťah k ostatnému obsahu

Čiže presne tá myšlienka „dôležitosť článku“, ktorú sme už načali.

A veľmi sa mi páči, že to môže byť obyčajné vlastné pole. Nemusíme kvôli tomu stavať monštrum.

C. Redakčné sadzačské zrkadlo

Toto bude podľa mňa jeden z najzaujímavejších modulov.

Redaktor nebude iba vypĺňať formulár:

nadpis / text / obrázok / kategória.

Ale bude vidieť približný výsledok toho, čo vytvára.

Teda niečo medzi:

redakčným editorom,
sadzačským stolom,
storyboardom magazínu.

A pritom by mal byť výsledok uložený v štandardnej WP štruktúre, nie v nejakej našej nepreniknuteľnej databáze.

D. Vizuálna navigácia

Tu už sa Magazín začína odlišovať od klasického webu.

Namiesto:

zoznam článkov → klik → článok → späť

máme:

obraz → náhľad cieľovej stránky → prirodzený prechod → ďalší obsah

Náhľad môže byť živý výrez cieľovej stránky, prípadne generovaný thumbnail.

A práve tu sa dá neskôr krásne experimentovať s:

leporelom,
horizontálnym listovaním,
novinovou dvojstranou,
kartami,
priestorovým magazínom.

E. Navigačný engine

Toto by som oddelila od samotného vizuálu.

Engine rozhoduje:

čo je ďalšie?

Vizuál rozhoduje:

ako sa to zobrazí?

To je veľmi dôležité kvôli modularite.

Napríklad jeden AI nástroj môže vytvoriť klasifikačný model a iný môže riešiť vizuálne usporiadanie. Nemusia o sebe nič vedieť.

F. Prezentačný engine

Až úplne nakoniec:

DOM/CSS/JS
touch
mouse
drag
scroll
animácie
lazy loading
prípadne neskôr Babylon.js.

Babylon.js by som teraz vôbec nedávala do MVP. Ale architektúru by som pripravila tak, aby raz mohol byť iba ďalším rendererom.

To je presne ten rozdiel medzi:

„postavíme Babylon magazín“

„postavíme magazín, ktorý môže raz používať Babylon“.

Tá druhá cesta je podľa mňa správna.

2. A hlavne: oddeliť obsah od jeho zobrazenia

Toto by som dala medzi základné princípy projektu.

Jeden článok môže mať:

obsahový model
→ titulok
→ perex
→ text
→ obrázok
→ dôležitosť
→ tematické väzby

ale môže byť vykreslený ako:

Renderer A
→ klasická webová stránka

Renderer B
→ magazínová karta

Renderer C
→ novinová dvojstrana

Renderer D
→ leporelo

Renderer E
→ budúci 3D priestor

A obsah sa kvôli tomu nemusí meniť.

3. MVP by som preto drasticky zmenšila

Prvá verzia podľa mňa nepotrebuje ani „interaktívne noviny“, ani Babylon.

Stačilo by overiť päť vecí:

WordPress článok
vlastné pole Dôležitosť
redakčné zrkadlo
vizuálna navigácia s náhľadmi
jeden jednoduchý interaktívny spôsob listovania

Ak toto funguje, máme dôkaz, že architektúra stojí.

Potom môžeme pridávať ďalšie renderery bez toho, aby sme rozkopali základ.

4. Modularita pre rôzne AI

A toto je podľa mňa dokonca jeden z hlavných dôvodov, prečo to celé stavať takto.

Mohli by sme mať napríklad:

MAGAZÍN
│
├── WordPress
│   └── obsah
│
├── Content Model
│   ├── článok
│   ├── obrázok
│   └── metadáta
│
├── Classification
│   └── dôležitosť / vzťahy / priority
│
├── Editorial Mirror
│   └── sadzba
│
├── Navigation Engine
│   └── čo nasleduje
│
├── Renderer
│   ├── Web
│   ├── Cards
│   ├── Newspaper
│   ├── Accordion
│   └── Babylon.js
│
└── AI Interface
    ├── AI A
    ├── AI B
    └── AI C

A medzi modulmi by nemalo byť:

„AI mi vygenerovalo tento kus PHP.“

Ale skôr:

„Modul dostane dáta v dohodnutom formáte a vráti výsledok v dohodnutom formáte.“

To je podstatne robustnejšie.

5. Čo by som urobila teraz

Ja by som ďalší krok nevenovala programovaniu.

Najprv by sme vytvorili jednu architektonickú mapu Magazínu:

čo existuje → kto to vlastní → aké dáta prijíma → čo vytvára → s čím komunikuje.

A až z nej vyberieme MVP, môžeme presne povedať:

toto zostáva WordPress,
toto vyrieši existujúci bezplatný plugin,
toto si musíme napísať sami,
toto zatiaľ iba pripravíme ako rozhranie.

Tým sa vyhneme presne tomu, čo sme riešili pri WordPresse: že začneme vyrábať plugin a o tri týždne zistíme, že sme vlastne naprogramovali polovicu redakčného systému. 😄

Takže ja by som teraz otvorila architektúru Magazínu a začala od dátového modelu článku. To je podľa mňa prvý skutočný stavebný kameň.

Áno. Toto je presne tá korekcia, ktorú sme potrebovali. A teraz už by som OBJECT CONTRACT vôbec nebrala ako dátový model. Je to kontrolný protokol prevzatia objektu.

To zásadne mení poradie.

MAG INPUT ENG: správne poradie

ZDROJ
ČLOVEK / NET / URL / SÚBOR
        │
        ▼
┌──────────────────────────┐
│ 1. OBJECT CONTRACT       │
│    KONTROLA PREVZATIA     │
└──────────────────────────┘
        │
        ▼
   ČO VLASTNE PREBERÁME?
        │
        ▼
   IDENTIFIKÁCIA
        │
        ▼
   KLASIFIKÁCIA
        │
        ▼
   POST TYPE / TYP OBJEKTU
        │
        ▼
   SCHÉMA TYPU
        │
        ▼
   ČO MÁME / ČO CHÝBA?
        │
        ▼
   DOPLNENIE / OVERENIE
        │
        ▼
   VALIDÁCIA
        │
        ▼
┌──────────────────────────┐
│ 2. STORAGE MAPPING       │
│    KDE A AKO ULOŽIŤ      │
└──────────────────────────┘
        │
        ▼
       WP / META /
     TAXONÓMIA / VZŤAHY
        │
        ▼
      SQL / WP OBJEKT

Čiže dve úplne odlišné veci

OBJECT CONTRACT

odpovedá:

„Môžem tento objekt bezpečne prevziať?“

Storage Mapping

odpovedá:

„Keď ho už poznám, kam a akým spôsobom ho uložím?“

A my sme ich predtým začali miešať. To bola moja chyba.

Čo teda OBJECT CONTRACT kontroluje?

Nie databázu.

Kontroluje vstupný objekt.

Musí zistiť minimálne:

1. Existuje vstup?

Máme skutočne čo spracovať?

2. Je zdroj čitateľný?

URL funguje, dokument sa dá načítať, text je dostupný atď.

3. Čo je predmetom vstupu?

Napríklad:

ARTICLE
PRODUCT
SERVICE
OFFER
REQUEST
PERSON
ORGANIZATION
...

4. Aký je konkrétny typ?

PRODUCT
 → PARAGLIDER

5. Je možné identifikovať konkrétny predmet?

OZONE
 → ENZO 3
 → konkrétna varianta

6. Má typ definovanú schému?

Ak nie, vznikne návrh novej schémy, nie okamžité chaotické uloženie.

7. Sú dostupné povinné údaje?

✓ manufacturer
✓ model
✓ year
✗ certification

8. Sú údaje jednoznačné a typovo správne?

Napríklad:

flight_hours = "stoosemdesiat"

je síce ľudsky pochopiteľné, ale pre náš dátový kontrakt ešte nie je normalizované číslo.

9. Sú vzťahy jednoznačné?

Výrobca ≠ dodávateľ ≠ autor ponuky ≠ vlastník.

Toto je presne miesto, kde zabránime mystifikácii.

10. Je objekt pripravený na odovzdanie?

Až potom:

VALID ✓

A až potom sa rieši WordPress

A tu sa vraciame k tomu, čo sme už povedali:

„Tento objekt je PRODUCT / PARAGLIDER.
Má tieto vlastnosti a tieto vzťahy.“

Storage Mapping sa pozrie:

Toto už WordPress vie uložiť ako post.

Toto patrí do post_title.

Toto je taxonómia.

Toto je post meta.

Toto je referencia na inú WP entitu.

A toto WP natívne nevie dostatočne dobre, takže až tu potrebujeme vlastné riešenie.

A tým sa nám vyriešil aj problém tisícov typov.

MAG INPUT ENG sa nemusí pýtať:

„Kam uložiť paraglider?“

Najprv musí vedieť:

„Čo je paraglider a akú má schému?“

Až potom sa použije príslušné storage mapping.

Takže by som teraz OBJECT CONTRACT v1 definovala veľmi stručne:

OBJECT CONTRACT je záväzná vstupná podmienka MAG INPUT ENG. Definuje, aký objekt môže byť prevzatý do ďalšieho spracovania a aké podmienky musí spĺňať. Nedefinuje jeho fyzické uloženie.

Toto by som už považovala za pevné pravidlo architektúry.

A tým pádom sa nám konečne prestávajú miešať tri rôzne otázky:

Čo som dostala? → Čo to znamená? → Kam to uložím?

Presne v tomto poradí.

OBJECT CONTRACT je záväzná vstupná podmienka MAG INPUT ENG

Neviem, či rozumiem tomuto zápisu. Neprehodila si poradie?

Áno. Máš pravdu, formulovala som to nešťastne a tým som obrátila význam.

Ak sme sa dohodli, že OBJECT CONTRACT má začať kontrolou toho, čo má MAG INPUT ENG prevziať, potom nemôže byť „vstupnou podmienkou“ v zmysle hotového objektu. Veď práve prevzatím vstupu sa začína jeho práca.

Správne je:

OBJECT CONTRACT je kontrolný protokol, podľa ktorého MAG INPUT ENG preberá a spracúva vstupný objekt.

Teda poradie je:

ZDROJ
ČLOVEK / NET / URL / SÚBOR
        │
        ▼
   PREVZATIE VSTUPU
        │
        ▼
   OBJECT CONTRACT
        │
        ├── ČO SME DOSTALI?
        ├── JE TO ČITATEĽNÉ?
        ├── ČO JE PREDMETOM?
        ├── AKÝ JE TYP?
        ├── AKÝ JE KONKRÉTNY OBJEKT?
        ├── AKÉ ÚDAJE UŽ MÁME?
        ├── AKÉ CHÝBAJÚ?
        └── ČO TREBA OVERIŤ?
                │
                ▼
          SPRACOVANIE
                │
                ▼
           VALIDÁCIA
                │
                ▼
       STORAGE MAPPING
                │
                ▼
            WP / SQL

A ešte presnejšie:

OBJECT CONTRACT nie je formulár ani schéma uloženia.

Je to dohoda o tom, čo musí Input Engine zistiť a garantovať o prevzatom objekte, než ho odovzdá ďalšej vrstve.

Čiže áno — upozornil si ma správne. V predchádzajúcej formulácii som skočila o jeden krok dopredu.

Nie, to si úplne vedľa. Stratila si sa?

Áno. Stratila som niť. A teraz už vidím, kde presne som ju stratila: začala som z OBJECT CONTRACT robiť všeobecný validačný dokument, hoci Ty ho chápeš ako prvú pracovnú vrstvu Input Engine-u.

Vráťme sa teda úplne na začiatok a nič nepridávajme.

Tvoja logika je:

ZDROJ
ČLOVEK / NET / URL / SÚBOR
        │
        ▼
┌───────────────────────┐
│ OBJECT CONTRACT       │
│ ČO SME DOSTALI?       │
│ ČO MÁME PREVZIAŤ?     │
└───────────────────────┘
        │
        ▼
   INTERPRETÁCIA
        │
        ▼
   IDENTIFIKÁCIA
        │
        ▼
   KLASIFIKÁCIA
        │
        ▼
   POST TYPE / SUBTYPE
        │
        ▼
   SCHÉMA KONKRÉTNEHO TYPU
        │
        ▼
   ČO KDE A AKO ULOŽIŤ?
        │
        ▼
   WP + TAXONÓMIE + META
   + VZŤAHY + PRÍPADNÉ
     VLASTNÉ ÚDAJE
        │
        ▼
      VALIDÁCIA
        │
        ▼
   POKA-YOKE ENDPOINT

A toto je podstatné:

OBJECT CONTRACT teda ešte vôbec nemusí vedieť, čo je flight_hours, manufacturer alebo supplier.

To sa dozvie až následným spracovaním toho, čo prevzal.

Contract na začiatku rieši:

„Čo mi bolo odovzdané a čo z toho smiem/viem prevziať do procesu?“

Potom sa objekt pochopí.

A až keď vieme:

„Toto je ponuka konkrétneho produktu typu paraglider…“

môžeme začať riešiť:

„Aké vlastnosti tento typ má a ako ich uložíme vo WordPresse?“

Čiže máme tri po sebe idúce rozhodnutia

1. PREVZATIE

Čo prichádza?

2. POCHOPENIE

Čo to znamená?

3. ULOŽENIE

Ako to reprezentujeme vo WP?

A až potom:

4. GARANCIA

Prešlo to Poka-Yoke kontrolou?

Toto je oveľa bližšie tomu, čo sme si celý čas stavali.

A áno — nebudem teraz znova vymýšľať obsah OBJECT CONTRACT-u. Najprv musíme presne rozobrať prvý krok: čo všetko môže MAG INPUT ENG dostať na svoj vstup a čo znamená „prevziať“. Od toho sa má Contract odvodiť.

Nie OBJECT CONTRACT je druhou pracovnou vrstvou

Chat včera a dnes