O tom, že tento blog pohání BLOG:CMS jsem psal hned ve svém prvním příspěvku. Po určité době používání musím konstatovat, že ač se administrace zdá na první pohled složitá, časem se v ní člověk zorientuje. U systému jsem ovšem narazil i na určité nedostatky, které nejsou zrovna příjemné. Za nejzávažnější chybu považuji generování duplicitního obsahu.

V předchozím článku jsem již v popisoval problémy, které může způsobovat duplicitní a podobný obsah, proto nyní jen velmi stručně:

• Vyhledávače obvykle zaindexují pouze jednu URL adresu,
• část zpětných odkazů (směřující na neindexovanou variantu URL) tak ztratí svůj význam,
• dojde ke zhoršení použitelnosti stránek,
• při ukládání na delicious apod. se počítá každý článek zvlášť.
  

Pokud používáte SMARTY šablony, možná jste již narazili na problém s vypsáním pole, které nemá přesně daný počet úrovní. Typický příklad je třeba menu, kdy každý odkaz může obsahovat sub položky.

První krok většinou obnáší naplnění pole z databáze. Tímto tématem se článek nezabývá, různé přístupy k uložení struktur v databázi lze nalézt například v článku na Intervalu.

Předpokládejme tedy, že pole již máte naplněné v proměnné, tu jste předali šabloně a nyní byste rádi pole nějak strukturovaně vypsali.

Při vývoji aplikace, která počítá s přepisováním adres pomocí mod_rewrite (Cool URL, přátelské adresy), je většinou nutné řešit problém s relativními a absolutními cestami. Projekt obvykle běží na vlastní doméně, např.
www.exaple.com. URL stránky potom může vypadat třeba takto:
www.example.com/clanek/adresa-clanku/. Všechny adresy ve stránce (cesty k obrázkům, CSS stylům, ...) potom musí být zapsané tak, aby ukazovaly do kořenového adresáře webu, jinak nebudou fungovat. To lze vyřešit více způsoby, nejoblíbenější je použití lomítka k určení absolutní cesty
(<img src="/obrazky/obrazek.jpg" alt="" />).

Problém nastává v případě, kdy se projekt vyvíjí na lokálním počítači. Na něm existuje více různých aplikací vedle sebe. Běžně jsou potom jednotlivé weby v oddělených adresářích, takže adresa potom vypadá nějak takto:
http://localhost/nazev-projektu/. Výše zmíněné lomítko potom ale bude ukazovat na adresu http://localhost/, což způsobí nefunkčnost aplikace.

Šablonovací systémy mají své příznivce i odpůrce, v některých případech jsou postradatelné, někdy zase vyloženě nenahraditelné. Nutné jsou především tehdy, kdy na jednom projektu dělá více lidí. Šablony v takovém případě nejen pomohou oddělit aplikační a prezentační logiku, ale dají možnost upravovat každou vrstvu zvlášť HTML kodérovi a programátorovi.

Šablony je ovšem výhodné používat také v případě, kdy aplikaci vyvíjí jeden člověk. Představte si situaci, kdy tvoříte nějaký větší projekt, který budete někdy chtít použít znovu. Pokud máte důsledně oddělenou aplikační vrstvu (například jazyk PHP) od prezentační vrstvy (HTML), nebudou úpravy tolik složité. V ideálním případě stačí přepsat pouze HTML kód (v šabloně) a práce je hotová. Začínající programátor si možná řekne, že ten kód přeci může upravit stejně i když šablony nepoužívá. To je sice pravda, ale pokud jsou obě vrstvy promíchané, je třeba projít všechny soubory postupně a upravovat HTML kód mezi řádky PHP, což je o mnoho pracnější, náročnější a delší.