Content model je dogovor o tome koji sadržaj postoji, od kojih se podataka sastoji, kako je povezan i kroz koje statuse prolazi. U custom CMS-u on predstavlja vezu između poslovnih pravila, baze podataka, administratorskog interfejsa i javnog sajta. Ako se taj model preskoči i razvoj počne od ekrana, često nastanu duplirana polja, nejasne relacije i ručne procedure koje kasnije postaju skupe za promenu.
Praktičan odgovor na pitanje kako strukturirati podatke pre programiranja glasi: prvo treba popisati tipove sadržaja i njihove odgovornosti, zatim definisati polja i pravila validacije, a tek onda odlučiti kako će se sve prikazivati u CMS-u. Model treba da bude dovoljno precizan za razvoj, ali i dovoljno fleksibilan da podrži buduće stranice, jezike, uloge i kanale objave.
Šta content model zapravo obuhvata
Content model nije samo spisak kolona u bazi. On opisuje strukturu sadržaja na više nivoa:
- Entiteti – samostalne vrste podataka, kao što su članak, proizvod, usluga, autor, lokacija ili FAQ stavka.
- Polja – vrednosti koje entitet poseduje, na primer naslov, sažetak, cena, slika, datum ili status.
- Relacije – veze između entiteta, kao što su članak–autor, proizvod–kategorija ili usluga–FAQ.
- Pravila – obaveznost, format, jedinstvenost, dozvoljene vrednosti i uslovi prikaza.
- Životni ciklus – način na koji sadržaj prelazi iz nacrta u pregled, odobrenje i objavu.
- Prezentacioni izlaz – način na koji se podaci koriste na stranici, u pretrazi, API-ju ili drugom kanalu.
Ova razlika je važna jer jedan model može hraniti više prikaza. Na primer, entitet „autor“ ne bi trebalo pretvarati u običan tekst unutar svakog članka ako se njegovo ime, biografija i fotografija koriste na više mesta. U tom slučaju autor je zaseban entitet povezan sa člancima.
Počnite od sadržaja i procesa, ne od menija u administraciji
Pre razgovora o ekranima i komponentama napravite inventar stvarnog sadržaja. Korisno je razgovarati sa osobama koje ga pripremaju, proveravaju i objavljuju, a ne samo sa vlasnikom projekta. Cilj je da se otkrije šta se zaista menja, šta se ponavlja i gde nastaju greške.
Pitanja koja treba postaviti
- Koje vrste stranica postoje danas, a koje treba da postoje nakon lansiranja?
- Koji podaci se koriste na više stranica?
- Da li urednik menja ceo sadržaj ili samo pojedina polja?
- Ko odobrava izmene i da li se čuva istorija verzija?
- Da li sadržaj postoji na više jezika?
- Da li se isti podaci prikazuju na sajtu, u pretrazi, aplikaciji ili eksternom sistemu?
- Šta se dešava kada se kategorija, autor ili proizvod arhivira?
Odgovori na ova pitanja često pokažu da „stranica“ nije dovoljan model. Na primer, katalog može sadržati proizvode, brendove, kategorije, tehničke karakteristike i dokumente. Ako se sve sačuva kao jedan veliki rich-text blok, urednik dobija slobodu, ali sistem gubi mogućnost filtriranja, ponovne upotrebe i kontrolisane validacije.
Kako prepoznati entitete
Entitet je dobar kandidat za zaseban tip sadržaja kada ima sopstveni identitet, životni ciklus ili se pojavljuje na više mesta. Dobar test je pitanje: da li bi ovaj podatak trebalo izmeniti jednom, a da se promena odrazi svuda gde se koristi?
Uobičajeni entiteti mogu biti:
- stranica ili landing page;
- članak ili vest;
- autor;
- kategorija i tag;
- proizvod ili usluga;
- lokacija ili poslovnica;
- FAQ stavka;
- medijski fajl;
- poziv na akciju ili promotivna komponenta.
Ne treba svaki vizuelni element pretvoriti u entitet. Dugme unutar jedne stranice može biti samo grupa polja: tekst, URL i način otvaranja. Međutim, kampanjski baner koji se prikazuje na deset mesta i ima sopstveni period važenja verovatno zaslužuje zaseban model.
Razdvojite tip sadržaja od šablona prikaza
Tip sadržaja odgovara na pitanje šta podatak jeste, dok šablon odgovara na pitanje kako se prikazuje. Jedan članak može biti prikazan na stranici članka, u kartici preporučenih tekstova i u rezultatima pretrage. Ako se model vezuje za samo jedan izgled, svaka nova upotreba zahteva promenu strukture podataka.
Zato je korisno prvo definisati semantički model, a zatim mapirati polja na prikaze. Naslov, autor i datum objave treba da imaju jasno značenje bez obzira na to da li se prikazuju u zaglavlju, kartici ili API odgovoru.
Definišite polja tako da imaju jedno jasno značenje
Svako polje treba da ima naziv, tip, svrhu, obaveznost, pravila validacije i očekivanu upotrebu. Umesto neodređenog polja „tekst“, preciznije je razlikovati naslov, sažetak, glavni sadržaj, tekst dugmeta, SEO opis i internu napomenu.
| Polje | Tip | Pravilo | Primer upotrebe |
|---|---|---|---|
| Naslov | kratak tekst | obavezan, ograničena dužina | naslov članka i HTML title logika |
| Sažetak | plain text | bez dekorativnog formatiranja | kartica, listing i deljenje |
| Glavni sadržaj | rich text ili blokovi | dozvoljene samo definisane komponente | telo članka |
| Autor | relacija | povezan sa postojećim autorom | biografija i atribucija |
| Status | kontrolisana vrednost | dozvoljeni statusi workflowa | nacrt, pregled, objavljeno |
Za strukturu i validaciju podataka može pomoći pristup poznat iz zvanične dokumentacije za JSON Schema, posebno kada se definišu tipovi, obavezna polja i dozvoljene vrednosti. To nije zamena za poslovni model, ali pomaže da očekivani oblik podataka bude eksplicitan i proverljiv.
Posebno izbegavajte polja koja pokušavaju da pokriju više nepovezanih potreba. „Dodatne informacije“ obično postane mesto za nepredvidiv tekst koji kasnije nije moguće filtrirati, prevesti ili koristiti u drugom prikazu. Ako postoje tri različite vrste informacija, bolje je napraviti tri jasna polja ili strukturisanu grupu.
Relacije: kada koristiti povezane entitete, a kada ugrađene blokove
Relacija je opravdana kada povezani sadržaj ima sopstveni identitet ili se koristi na više mesta. Ugrađeni blok je praktičniji kada je sadržaj mali, specifičan za jednu celinu i nema smisla izvan nje.
Na primer, lista FAQ pitanja može biti:
- ugrađena u stranicu ako se pitanja odnose samo na tu stranicu;
- zaseban entitet ako se ista pitanja prikazuju na više usluga, imaju sopstvenu klasifikaciju ili ih urednici održavaju centralno.
Kod relacija treba unapred odrediti kardinalnost: jedan prema jedan, jedan prema više ili više prema više. Takođe treba definisati šta se dešava pri brisanju ili arhiviranju povezanog zapisa. Tehnički, relacione baze podržavaju ovakva pravila kroz ograničenja poput foreign key veza; PostgreSQL dokumentacija o ograničenjima daje primer kako se integritet povezanih podataka štiti na nivou baze.
Važna odluka je i da li relacija treba da čuva redosled. Preporučeni članci, stavke menija i galerije najčešće nisu samo skup zapisa, već uređena lista. Redosled treba modelirati eksplicitno, umesto da zavisi od slučajnog redosleda upisa.
Rich text ili strukturisani blokovi
Rich-text editor je koristan za tekstualne forme kao što su članci, saopštenja i opisi. Ipak, potpuno slobodan sadržaj često otežava dosledan dizajn, pristupačnost i kasnije izmene. Za ponovljive obrasce bolji su strukturisani blokovi, na primer:
- naslovna sekcija sa naslovom, sažetkom i pozivom na akciju;
- tekst sa slikom;
- lista prednosti;
- citati;
- tabela karakteristika;
- FAQ grupa;
- povezani sadržaj.
Blokovi ne treba da budu samo kopija frontend komponenti. Ako se model zasnuje isključivo na vizuelnim detaljima kao što su „plavi blok“ ili „treća kolona“, biće teško održavati sadržaj kada se dizajn promeni. Bolje je modelovati značenje: „promotivna poruka“, „uporedna tabela“ ili „lista koraka“, a izgled rešavati u prezentacionom sloju.
URL, SEO i metapodaci kao deo modela
URL i metapodaci ne treba da budu naknadni dodatak. Za svaki javni tip sadržaja unapred definišite slug, canonical pravilo ako je potrebno, status indeksiranja, SEO naslov, opis i način generisanja Open Graph podataka. Ne mora svako polje biti ručno popunjeno: model može predvideti podrazumevanu vrednost iz naslova, uz mogućnost uredničke izmene.
Slug treba da bude stabilan identifikator, dok naslov može da se promeni. Ako je promena URL-a dozvoljena, model mora predvideti redirect ili istoriju prethodnih slugova. U suprotnom, urednička izmena naslova može prekinuti interne i eksterne veze.
Za sadržaj koji treba da se koristi u strukturisanim podacima važno je čuvati činjenice u zasebnim poljima, a ne samo u vizuelnom tekstu. Na primer, lokacija može imati adresu, radno vreme i kontakt kao strukturisane podatke. To olakšava konzistentan prikaz, ali samo po sebi ne garantuje posebne rezultate u pretrazi.
Više jezika, mediji i ponovna upotreba
Podrška za više jezika mora biti odluka modela, ne samo opcija interfejsa. Treba odrediti da li svaki prevod ima isti identitet kao izvorni zapis, da li sva polja moraju biti prevedena i šta se prikazuje kada prevod nedostaje. Naslov, slug, SEO opis i glavni sadržaj često imaju lokalizovane vrednosti, dok interni identifikator ili tehnički status ne moraju.
Medijski fajl takođe zaslužuje jasna pravila. Uz fajl mogu se čuvati alternativni tekst, naslov, fokusna tačka, licenca i varijante za različite prikaze. Ako se slika unosi kao HTML kod u tekstualno polje, te informacije se lako izgube i teško je sprovesti doslednu proveru.
Preporučljivo je odvojiti originalni medijski zapis od njegovog mesta upotrebe. Ista slika može imati drugačiji alternativni tekst u članku i u dekorativnoj kartici, pa model treba da omogući kontekstualnu odluku umesto slepog kopiranja.
Workflow, verzije i prava pristupa
Statusi sadržaja treba da opisuju stvarni proces, a ne samo tehničke faze. Minimalni tok može biti nacrt, na pregledu, odobreno i objavljeno, ali složeniji timovi mogu zahtevati vraćanje na doradu, zakazanu objavu ili arhivu. Za svaki prelaz definišite ko sme da ga izvrši i šta se beleži.
Content model i dozvole su povezani. Ako urednik sme da menja samo određene tipove sadržaja ili polja, ta ograničenja treba planirati pre izrade administracije. Više o razdvajanju odgovornosti između editora, reviewera i administratora nalazi se u vodiču Uloge i dozvole u CMS-u.
Za detaljnije planiranje statusa i odobravanja koristan je i tekst o editorial workflowu u custom CMS-u. Bez jasnog workflowa, CMS često samo centralizuje unos, ali ne rešava pitanje odgovornosti za objavu.
Content model za pretragu, skaliranje i programmatic SEO
Ako će CMS generisati veliki broj sličnih stranica, model mora razlikovati korisne podatke od šablonskog teksta. Lokacija, kategorija, karakteristika ili usluga treba da budu stvarni, proverljivi atributi, a ne samo promenljiva u URL-u. Svaka kombinacija filtera ne mora automatski postati indeksabilna stranica.
Pre odluke o generisanju stranica definišite minimalne podatke, kriterijume za objavu, jedinstvenost kombinacije i način interne navigacije. Dodatne smernice za ovu odluku nalaze se u članku Programmatic SEO u custom CMS-u bez thin content-a. Model treba da podrži skaliranje samo tamo gde postoji stvarna informativna vrednost.
Kontrolna lista pre početka programiranja
- Napravite tabelu svih tipova sadržaja i njihovih vlasnika.
- Za svaki tip navedite polja, tip podatka, obaveznost i validaciju.
- Označite polja koja se ponavljaju i odlučite da li postaju zasebni entiteti.
- Nacrtajte relacije i navedite kardinalnost, redosled i ponašanje pri arhiviranju.
- Definišite URL, lokalizaciju, SEO metapodatke i pravila za medije.
- Opišite statuse, dozvoljene prelaze i odgovorne uloge.
- Dodajte najmanje po jedan realan primer zapisa za svaki tip sadržaja.
- Proverite kako model podržava javni sajt, pretragu, API i buduće prikaze.
- Tek nakon toga mapirajte model na administratorske ekrane i frontend komponente.
Ovaj dokument ne mora biti savršen pre prvog sprinta. Treba da bude dovoljno konkretan da razvojni tim i urednici dele isto razumevanje podataka. Tokom implementacije mogu se pojaviti opravdane izmene, ali svaka promena treba da ima razlog: novi poslovni zahtev, bolju ponovnu upotrebu ili jasnije pravilo, a ne samo reakciju na trenutni izgled ekrana.
Sledeći korak: pretvorite model u tehničku specifikaciju
Kada su entiteti, polja, relacije i workflow usaglašeni, sledeći korak je njihovo prevođenje u bazu, API, validacije i CMS interfejs. To je jedna od ključnih faza izrade custom CMS-a, jer kvalitet implementacije zavisi od toga koliko su poslovna pravila jasno opisana pre programiranja.
Ako projekat obuhvata i javni sajt, content model treba uskladiti sa njegovom informacijskom arhitekturom, komponentama i tehničkim zahtevima. Kontekstualno planiranje kroz proces izrade sajta pomaže da se izbegne situacija u kojoj CMS čuva podatke koje frontend ne može smisleno da prikaže. Koristan rezultat ove faze je kratka specifikacija sa primerima zapisa, matricom dozvola i spiskom otvorenih odluka.
