Počínaje tímto dílem našeho seriálu zcela opustíme poněkud nudnou šeď teorie PHP programování, a vrhneme se na praxi. V několika následujících dílech totiž poslepujeme úplně nový web a projdeme přitom všechny kroky, které byste měli v takové situaci mít na paměti. Programování v PHP je dosti svázáno s dalšími technologiemi, takže jeden větší příklad bude lepší než několik malých fragmentů kódu.

Je to samozřejmě dilema - čím kratší je příklad, tím spíše se můžete soustředit na to, co opravdu řeší - ale čím je rozsáhlejší, tím spíše pochopíte, jak spolu jednotlivé etapy práce a části kódu souvisejí. Budeme tedy používat nejen PHP, ale HTML a MySQL (možná trochu i styly). Navíc, budu se snažit představit vám jednotlivé kroky stavby webu tak, jak v praxi opravdu probíhají. Tím by čtenář (zejména pokud s webovou tvorbou začíná) měl získat alespoň základní představu o tom, co a kdy se má dělat.

Nebude to internetový obchod

Ne! Internetové obchody dělá jako příklad na PHP každý. Navíc mi (pokud se implementuje přihlašování i nakupování) přijdou pro začátečníka poněkud obtížné na pochopení. Namísto toho zkusíme naprogramovat web o nějaké vymyšlené hudební skupině. Bude to prinicpiálně velmi jednoduché a nebudou v tom žádné záludnosti (účetní věci, DPH apod.), které by internetový obchod zcela jistě provázely.

Jak jen to půjde, nebudeme se zabývat žádnými záležitostmi, které přímo nesouvisejí s PHP. Naše "stránky" tedy nebudou mít žádnou nebo téměř žádnou grafiku, abychom se soustředili na to, co nás opravdu zajímá. Velmi málo (pokud vůbec) se budeme zabývat věcmi jako je klientské skriptování nebo DHTML.

Zadání

První věc, kterou byste si měli při návrhu webu ujasnit, je zadání. My budeme tvořit web propagující smyšlenou hudební skupinu. Součástí stránek bude následující funkcionalita:

• rozhraní pro zadávání koncertů (datum, čas, místo konání) s tím, že se budou ukládat v databázi a zobrazovat na webu
• diskografie - názvy alb a seznam písní na těchto albech
  
• správu uživatelů (přihlašování, odhlašování, sekce "jen pro členy"...)
• nějaký mechanismus pro zveřejňovaní textů písní, aby si je později mohla kapela sama publikovat
• přihlášení členové si budou moci stahovat texty písní a dema
  
• budeme počítat s tím, že si náš virtuální zadavatel může ještě na něco vzpomenout a pokusíme se na to myslet
  

Jednotlivé body budeme chtít samozřejmě rozpitvat. Taktická - poznámka: pokud by se jednalo o komerční věc, tohle je nejlepší udělat spolu se zákazníkem. Tak tedy, rozhraní pro zadávání koncertů by mělo umět následující věci:

• Zadávat koncerty bude smět pouze uživatel s oprávněními administrátora
  
• Z formuláře se zadá datum, čas a místo koncertu, to bude uloženo v databázi
• Na webu se budou zobrazovat pouze koncerty v budoucnosti (ne ty, co už byly)
• Aplikační logika by neměla povolit zadat více než jeden koncert denně

Podsekce diskografie by měla mít následující funkce

• Názvy alb a písní by se měly zadat do databáze
• Půjdou zobrazit buď jen alba, nebo alba a písně
• Vyhledávání - podle názvu písně najít album nebo alba, na nichž byla uvedena
  
• Jedna píseň bude moci být na více albech

Správa uživatelů by měla mít následující funkce:

• Uživatel se bude moci zaregistrovat pomocí přezdívky, e-mailu a hesla
• Heslo by mělo mít minimálně 4 znaky
• Aplikační logika by měla povolit pouze jednoho uživatele na jeden e-mail
• Aplikace by měla umět odeslat zapomenuté heslo (max. 1x denně), změnit heslo a zrušit registraci

Zveřejňování textů písní by mělo mít následující vlastnosti:

• Půjde zveřejnit jen text k písni, která již je v databázi
• Bude to moci dělat jen administrátor
• Text písně se bude dát exportovat do textového souboru
• Texty písní budou k dispozici jen pro registrované uživatele

Trochu jsem to rozepsal - zejména abych předvedl, jak je důležité mít "cílový koncept". Asi si umíte představit, že kdybyste tento seznam tvořili se zákazníkem, mohl by být daleko rozsáhlejší. A taky si asi už v téhle chvíli umíte představit, co by se stalo, kdybyste začali pracovat bez ujasnění těchto základních pravidel hry.

Pozn.: Pokud se jedná o komerční záležitost, jen naprostý sebevrah by byl schopen zkalkulovat cenu předtím, než udělá nějaký podobný cílový koncept. Profík si naopak vyhradí, že s každou změnou funkcionality se znovu probere otázka financí.

Technický rozbor

Teď není chvíle, kdy bychom měli "přijít od zákazníka, sednout a psát", nýbrž chvíle pro nějakou tu technologickou poradu. Samozřejmě, že aplikace bude vyžadovat skriptování na straně serveru - jasně volíme PHP. Bude potřeba databáze (minimálně na uložení alb, písní, textů a uživatelů). Zvolíme tedy (například) MySQL. Možná budeme potřebovat poshánět nějaký ten software - už jsme o tom psali. Další věci ke zvážení.

Teď něco z HTML. Budeme potřebovat stanovit, jaký typ dokumentu vlastně vyvíjíme - zda HTML, XHTML a jakou verzí specifikace se přitom budeme chtít řídit. To je nesmírně důležité, protože náš kód by měl být vždy validní (psal o tom Luboš Turek). Dobrý rozbor této problematiky najdete zde.

Aplikace by měla už od prvopočátku mít nějakou koncepci rozvržení, tzv. layoutu. V zásadě se na každý složitější site použije některá ze tří následujících technologií:

• Organizace pomocí rámů
• Layout pomocí tabulek
• Formátování pomocí kaskádových stylů

Každý z těchto způsobů má své zastánce, pěkně to shrnuje článek Pavla Káchy. Formálně je nejsprávnější použít technologii kaskádových stylů, protože právě za tímto účelem byla vyvinuta. My použijeme tabulky, protože to bude pro výklad některých pasáží názornější než CSS.

Pozn.: Pokud to s tvorbou webu myslíte vážně, rozhodně uvažujte o kaskádových stylech. Je to budoucnost webdesignu. Jednou větou - styly nejlépe umožňují oddělit obsah stránek od formy.

V dalším díle seriálu si poslepujeme "kostru" našeho webu a ujasníme si, jak vyřešíme navigaci mezi jednotlivými částmi stránek.