Webes alkalmazások tervezése, tervezési eszközök

Webes alkalmazások tervezése, tervezési eszközök Példaalkalmazás tervezése A tananyagban a példákat egyetlen példaalkalmazás keretein belül szándékozzuk bemutatni. A példaalkalmazás lehetőséget ad arra, hogy ne csak a technikai problémákat mutassunk be és oldjunk meg apróbb példákon keresztül, hanem azzal is szembesüljünk, hogy egy nagyobb alkalmazás készítésekor ezek az apróbb részletek hogyan állnak egésszé, és milyen további kihívásokat rejtenek magukba. Látni fogjuk, hogy egy nagy egész több mint részeinek összessége. Ebből a célból egy megfelelően nagy, de mégis átlátható méretű példaalkalmazás készítését tűztük ki célul, mely lehetőséget ad mind a kisebb feladatok megoldására, mind pedig a nagy egésszé kovácsolás bemutatására. Ebben a tananyagban célunk egy olyan webes alkalmazás készítése, mely lehetővé teszi fényképbemutatók készítését, megtekintését és publikálását. A fenti szöveg azonban nagyon sok kérdést vet fel:         

pontosan milyen oldalak lesznek? milyen adatok jelenjenek meg az oldalakon? hogyan nézzenek ki ezek az oldalak? (sablon) milyen összefüggésben vannak ezek az oldalak? (oldaltérkép) hogyan azonosítom a felhasználókat, hogyan különböztetem meg, hogy kinek milyen bemutatói vannak? (azonosítás, autentikáció) általában: milyen műveleteket és oldalakat érhetnek el az azonosítatlan és azonosított felhasználók? (szerepkörök, autorizálás) mik az egyes oldalak adatigényei? (modell felépítése, körvonalazása) milyen struktúrában, hogyan tároljuk az adatokat? (adatbázis) milyen eszközök támogatottak? (asztali böngésző, mobil kliensek)

Ezekre a kérdésekre (és még talán egyéb felvetődött kérdésekre) mind válaszolnunk kell AZELŐTT, hogy a konkrét fejlesztésekbe belekezdenénk. Részletes tervezéssel sok későbbi felesleges munkát kiküszöbölhetünk. Ugyanakkor ne áltassuk magunkat: fejlesztés közben vagy akár az alkalmazás (főleg webes alkalmazás) használata közben sok olyan igény felmerülhet, amely az eredeti koncepciónkat megváltoztathatja, felboríthatja. Nézzük végig módszeresen az egyes tervezési szempontokat:   

követelmények összegyűjtése, követelmény-analízis szerepkörök, használati esetek, folyamatok meghatározása oldalfunkciók

    

site struktúra (oldaltérkép) architektúra terv oldalvázlatok készítése adatbázis tervezése designtervek készítése

Követelmények összegyűjtése Ebben a fázisban a fejlesztő felméri, összegyűjti a megrendelő funkcionális és nem funkcionális igényeit, elvárásait, ez alapján meghatározza, vagy közösen meghatározzák az elvárandó funkciókat, definiálják a marketing- és stratégiai célokat. A további tervezési lépések az összegyűjtött követelményekre épülnek, azok kifejtéseinek, fejlesztési szempontból részletezéseinek tekinthetőek. A követelmények összegyűjtésének célja:      

a szükséges emberi, szoftveres, hardveres erőforrások elérendő célok, haszon, a szükséges időszükséglet, költségek, egyéb szervezeti elvárások, a szükséges feladatok, lépések

meghatározása, figyelembe véve a rendelkezésre álló erőforrásokat. A jellemzően nem funkcionális követelményeket érdemes kategorizálni. Legalább az alábbi kategóriák szerint:  Használhatóság, pl.: a látogatók által elért felület legyen jól átlátható, önmagyarázó (egy átlagos látogató felhasználói dokumentáció nélkül is tudja használni).  Teljesítmény, pl.: Egy oldal megjelenése egy linkre kattintástól mérve ne legyen több 2mp-nél (átlagos internetkapcsolatot használva).  Rendelkezésre állás, pl.: a weboldal legyen elérhető egy év 99.5%-ában.  Skálázhatóság, pl.: a becsült felhasználó-létszám nem igényli skálázható rendszer tervezését az első évben.  Biztonság, pl.: a felhasználók jelszavai ne legyenek visszafejthetőek.  Karbantarthatóság, pl.: a weboldal legyen könnyen bővíthető. Egy új oldallal, menüvel, vagy használati esettel való bővítés legyen egyértelmű, és gyorsan végrehajtható.

Természetesen megadhatunk egyéb kategóriákat is, például:  Vevői megszorítások, pl.: az alkalmazásnak online elérhetőnek kell lennie 2012. december 15-én.  Vevői minőségi elvárások, pl:. a webalkalmazásnak egy időben 100 konkurens kérést kell tudnia kiszolgálni, a második év végére pedig 2000-et.  Technológiai elvárások, megszorítások fejlesztői oldalról: olyan technológiai döntések, melyeket már a projekt követelmény-felméréseikor rögzítünk. Ezen megszorítások adódhatnak a rendelkezésre álló erőforrásokból. Jelen jegyzetben arra törekszünk, hogy technológiai döntéseinket a későbbiekben hozzuk meg, azokat indokolva. Ilyen lehet azonban, ha már a projekt elején kijelentjük, hogy például a PHP-t választjuk fejlesztői környezetnek.  Minőségi elvárások, felhasználói oldalról, pl az alkalmazásunk többféle platformról, mobil kliensekről is legyen elérhető, működőképes. Példánkban felmértük az alkalmazással szemben támasztott követelményeket, ezeket felsorolás-szerű leírásban írjuk le: Funkcionális követelmények:  Az alkalmazással a regisztrált felhasználók tudjanak létrehozni fényképbemutatókat.  Az egyes bemutatókba képeket tudjanak feltölteni.  Az egyes bemutatókat lehessen animálva levetíteni.  Legyen lehetőség regisztrációra.  Bizonyos funkciók csak regisztrációt követően legyenek elérhetőek o bemutató készítése o bemutató szerkesztése o képek feltöltése és törlése a saját bemutatókba o bemutató törlése o bemutatók részletes adatainak megtekintése o kedvencnek jelölés  A bemutatók között lehessen keresni.  Az adminisztrátor számára biztosítsunk lehetőséget a felhasználók adatainak szerkesztésére. Nem funkcionális igények:  Használhatóság, pl.: a látogatók által elért felület legyen jól átlátható, önmagyarázó (egy átlagos látogató felhasználói dokumentáció nélkül is tudja használni). Az adminisztrációs felület használata a felhasználói dokumentáció olvasása után legyen egyértelműen használható.

 Teljesítmény, pl.: a weboldal képes legyen 100 látogató egyidejű kiszolgálására. Egy oldal megjelenése egy linkre kattintástól mérve ne legyen több 2mp-nél (átlagos internetkapcsolatot használva).  Rendelkezésre állás, pl.: a weboldal legyen elérhető egy év 99.5%-ában.  Skálázhatóság, pl.: a becsült felhasználó-létszám nem igényli skálázható rendszer tervezését az első évben. (Megjegyzés: a továbbiakban a skálázhatósággal a karbantartási időszakban foglalkoznunk kell)  Biztonság, pl.: a felhasználók jelszavai ne legyenek visszafejthetőek. A felhasználók és adminisztrátorok által bevitt hibás adatokat a rendszer kezelje le: adjon hibajelzést, de próbálja a bevitt adatokat visszaállítani, hogy csak a hibás adatokat kelljen módosítani. A látogatók által elérhető beviteli mezőkön a rendszer végezzen szűrést ártalmas kódokra.  Karbantarthatóság, pl.: a weboldal legyen könnyen bővíthető. Egy új oldallal, menüvel, vagy használati esettel való bővítés legyen egyértelmű, és gyorsan végrehajtható. A megjelenés legyen elválasztva az adatoktól és a vezérléstől, legyen könnyű a megjelenés módosítása.  Vevői megszorítások: o az alkalmazásnak online elérhetőnek kell lennie 2012. december 15én.  Vevői minőségi elvárások: o a webalkalmazásnak egy időben 100 konkurens kérést kell tudnia kiszolgálni, a második év végére pedig 2000-et.  Technológiai elvárások fejlesztői oldalról: nincsenek  Minőségi elvárások, felhasználói oldalról: o a webalkalmazásunk legyen akadálymentes (az oldalaink legyenek validak, feleljenek meg a WCAG 2.0 szabványnak), o az adatbevitel legyen biztonságos, o az alkalmazásunk többféle platformról, mobil kliensekről is legyen elérhető, működőképes. Jelen jegyzetben nem foglalkozunk a marketing és stratégiai elvárásokkal, itt kellene felsorolni az erre vonatkozó elvárásainkat is. Szerepkörök, használati esetek Ebben a részben arról kell döntenünk, hogy milyen jogosultsági csoportokat szeretnénk kialakítani. A jogosultsági csoportokat szerepköröknek hívjuk, a felhasználókat pedig legalább egy szerepkörhöz rendeljük. Az alkalmazásunkban a fenti igények alapján háromféle szerepkör körvonalazódik ki: 

vendég: Az a felhasználó, aki azonosítatlanul használja az alkalmazást. A weben a legtöbb látogató ilyen. A vendég felhasználó csak a publikus





oldalakat és funkciókat érheti el. Ilyenek a főoldal, a címke és felhasználó szerinti listák, a bemutató oldal, valamint a bejelentkezés és regisztráció. bejelentkezett, azonosított felhasználó: a bejelentkezett felhasználók a publikus oldalakon kívül a saját bemutató lista és a szerkesztési oldalakat is használhatja. adminisztrátor: a felhasználói adatokat módosítani képes felhasználó.

Az azonosításon kívül még arra is figyelnünk kell, hogy a bejelentkezett felhasználók milyen tartalmakhoz férhetnek hozzá. Ezt a lépés autorizációnak hívjuk, és a példaalkalmazásban kimerül annyiban, hogy minden bejelentkezett felhasználó csak a saját bemutatóit szerkesztheti, másét nem. A felhasználókhoz hozzárendelhetjük az egyes funkcionális követelményekhez, szkenáriókhoz, azaz a használati esetekhez. Táblázatos formában érdemes összefoglalni az egyes szerepkörök tulajdonságait: Szerepkör neve:

RegisztráltUser

Leírás:

Regisztrált felhasználó. Az alkalmazás teljes funkcionalitása csak ebbe a csoportba tartozó felhasználók számára érhető el.

Profil adatok: Super-group: Sub-group: Kapcsolódó usecase:

oid, userName, password, email User Nincs Login, Bemutató megtekintés, Keresés, Bemutató információk lekérése, Új bemutató, Kép feltöltés, Bemutató szerkesztése, Kép törlése, Bemutató törlése, Kedvencnek jelöl Bemutato, Kep

Objektumok – olvasási joggal Objektumok – módosítási joggal

Bemutato, Kep

Ezt követően a követelmények alapján össze kell szedni a használati eseteket, szcenáriókat, melyeket az áttekinthetőség kedvéért szokás ún. használati eset (use case) diagramon ábrázolni:

Az egyes használati esetek részletes folyamatait is le kell írni, erre is több lehetőség van. Jelen példánkban az UML Activity Diagramot (egyéb ajánlott leírási formátum lehet például az ún. Business Process Modeling Notation) és a táblázatos formát használjuk. Példa: Új bemutató készítése:

Cím Cél Előfeltétel Utófeltétel Folyamat leírása

Új bemutató készítése Új bemutató album készítése. Csak regisztrált felhasználó (RegisztráltUser) tud új bemutatót készíteni. A bemutató mentése sikeres. Az alábbi lépések végrehajtása szükséges: 1. Az alábbi adatokat kell a felhasználónak kötelezően megadnia egy új bemutató készítésekor: cím, leírás, szerzo (automatikus). 2. Opcionális adatok: nincs 3. Bemutató mentése

Oldalfunkciók Az alkalmazás általános leírását ebben a részben váltjuk aprópénzre. Meghatározzuk, hogy az alkalmazás nagyjából milyen oldalakból áll, és ezeken körülbelül milyen adattartalom jelenik meg és milyen funkciókat képzelünk el. Ezek természetesen később finomodhatnak és változhatnak. 

Főoldal o Az alkalmazás nyitóképernyője, általában ez fogadja a látogatókat. Alapvető szerepe, hogy bemutassa, miről szól ez az alkalmazás, mit várhat tőle a felhasználó. A szöveges információn túl ízelítőt kell







adnia a működésről, valamint a legjobb vagy legaktuálisabb, magyarán szólva a legcsalogatóbb tartalmakat is meg kell jelenítenie. Ezek mellett lehetőséget kell adnia a tartalmak különböző szempontú keresésére, böngészésére, valamint a bejelentkezésre, regisztrálásra. Ennek megfelelően a következő funkciók, elemek jelennek meg az oldalon: o Hivatkozás a bejelentkezésre és regisztrálásra o 10 legnépszerűbb bemutató listája  Bemutató adatai  indexkép  címe  leírása  megtekintések száma  hányan jelölték be kedvencnek  készítője  címkék  Funkciók  megtekintésre kattintva a bemutató elindul  készítő adataira kattintva a készítő bemutatói jönnek be  címkére kattintva címkék szerinti keresés o 10 legutoljára feltöltött bemutató listája  Adatok ugyanazok o Címkefelhő kiírása népszerűség szerinti méretben  Funkciók  címkékre kattintva a címkék szerinti keresés jön be Bemutató megtekintése o Az alkalmazás központi, kulcsfontosságú része, hiszen az oldal fényképbemutatókat hirdet. Ennek megfelelően kellően attraktívnak és könnyen használhatónak kell lennie. o Csak publikus bemutató jeleníthető meg! o A bemutató adatai o A kép adatai o A bemutató diái bélyegképekben o A megjelenő nagy kép o Funkció  Kedvencnek jelöl (csak bejelentkezett felhasználóknak)  Vissza a főoldalra Címke szerinti keresés o Címke felirata o Adott címkéjű publikus bemutatók listája  Funkciók: ld. főoldali listák Készítő adatai o Felhasználó adatai  azonosító  publikus bemutatók száma

Publikus bemutatóinak listája Saját bemutatók o Bejelentkezett felhasználó érheti csak el a saját bemutatóit. o Saját bemutatók listája  Funkciók  Megtekintés → ld. Bemutató megtekintése  Törlés  Szerkesztés o Funkciók  Új bemutató létrehozása Új bemutató létrehozása o Csak bejelentkezett felhasználó érheti el o Adatok bekérése  Cím  Leírás o Funkció  Mentés: sikeres mentés után a szerkesztés oldalra jutunk Bemutató szerkesztése o Csak bejelentkezett felhasználó érheti el, csak saját bemutatót. o Bemutató adatainak megjelenítése  cím  leírás  publikus  címkék vesszővel felsorolt listája o Funkció  Visszatérés a listához  Bemutató vetítése  Új kép feltöltése  Bemutató adatainak szerkesztése  Törlés o A bemutatóhoz tartozó képek listája  Kép  Cím  Funkciók  Előre  Hátra  Töröl  Elrejt/Aktivál (ajax)  Szerkeszt Új kép feltöltése o Saját kép feltöltése  Filetallózó  Funkció  Feltölt, visszatérés a szerkesztésre o Képek keresése o









Szolgáltató (Picasa, Flickr)  Címke  Geoadat  Keresés  Képlista  Funkciók  Kiválasztott képek hozzáadása, visszatérés a szerkesztésre Bemutató adatainak szerkesztése o Csak bejelentkezett felhasználó érheti el, csak saját bemutatót. o Bemutató adatainak szerkesztése  cím  leírás  publikus  címkék vesszővel felsorolt listája  Funkció  Mentés, visszatérés a szerkesztésre Kép szerkesztése o Adatok bekérése  Cím  Leírás  Helyszín  Geoadatok  Funkció  Mentés, visszatérés a szerkesztésre Bemutató törlése o Csak bejelentkezett felhasználó, csak saját bemutatót o Törlés vagy lejáratás, inaktívvá tétel? o Megerősítés után törlés, irány a lista oldal Kedvenc bemutatók listája o Bemutatólista o Funkciók  Megtekintés  Eltávolítás a kedvencek közül Profil szerkesztése o email cím o jelszó módosítása 











Oldalvázlatok készítése Az oldalak funkcióinak összeírásával párhuzamosan elkezdhetjük az egyes oldalak körülbelüli elrendezéseit megrajzolni. E két feladat nagyon gyakran hatással van egymásra. Az összeírt adattartalom és funkcionalitás ugyanis sokszor meghatározza az elrendezést, és fordítva, az oldalvázlatok rajzolása közben új funkciók kerülhetnek az alkalmazásba.

Az oldalak elrendezésének előzetes tervezését drótvázkészítésnek hívják, az eredménye pedig az oldal drótváz rajza, vagy másképp angolul mockup-nak is hívják. A tervezést általában papíron végezzük el. Természetesen vannak a tervezés ezen fázisát segítő szoftverek is, az ún. mockup editorok vagy drótvázkészítő eszközök (wireframing tools). Ezek működése nagyon hasonlít a prezentációkészítő alkalmazásokra (pl. Powerpoint). Általában sok, speciálisan a webes alkalmazásoknál előforduló komponensekkel rendelkeznek, amelyeket az oldalon elhelyezve készíthetjük el a vázlatot. Sokszor ezen komponensek megjelenése szándékosan hasonlít a ceruzarajzra. Ennek az a célja, hogy hangsúlyozza a készítő vagy a megrendelő felé: a mockup nem a végleges design, hanem az oldal körülbelüli elrendezését tartalmazza, amely azonban már figyelembe veszi a megjelenő tartalmat és funkciókat. A mockup lesz majd az alapja a designnak. Sokféle Mockup szerkesztő található, sok ingyenes is nagyon jól használható:    

Pencil Balsamiq http://www.badlanguage.net/seven-website-mockup-tools http://speckyboy.com/2011/02/23/10-completely-free-wireframing-andmockup-tools/

Az oldalfunkciókat figyelembe véve az alábbi oldalakhoz érdemes elkészíteni a drótváz rajzokat: 

főoldal

   

bemutató címke szerinti keresés saját bemutatók listája bemutató szerkesztése és a hozzá kapcsolódó aloldalak

Oldaltérkép, site struktúra Bár az oldalak és funkciók összeírásakor már jelezzük az oldalak kapcsolatait, az oldaltérkép kifejezetten azt a célt szolgálja, hogy az egyes oldalak egymáshoz viszonyított kapcsolatait bemutassa. A site struktúra ábrázolásakor nem az a lényeges, hogy az egyes oldalakon milyen tartalom jelenik meg, hanem az, hogy az alkalmazásunk oldalaira és kapcsolataira madártávlatból tekintsünk. A példaalkalmazás oldaltérképéből jól kiviláglik a publikus és a bejelentkezéshez kötött oldalak kapcsolatrendszere.

Adatbázis tervezése A fejlesztés viszonylag korai szakaszában szükséges az adatok tárolásához szükséges struktúrát megtervezni. Példaalkalmazásunk relációs adatmodellbe szánt normalizált terve a következő:

Adatbázis Táblák Név Szinonimák Leírás Attribútumok

felhasznalo Felhasználó, user A felhasználó adatai ebben a táblában kerülnek tárolásra.  id (egész) – felhasználó azonosítója (adatbázisban)  azonosito (szöveg(30)) – felhasználó látható azonosító neve, belépési neve, beceneve  jelszo (szöveg(20)) – a felhasználó jelszava (kódolt)  email (szöveg(60)) – e-mail címe  utolso_belepes (dátum/idő) – utolsó belépés időpontja  belepes_db (egész) – bejelentkezések száma

Kapcsolatok

Név

bemutato

Szinonimák Leírás

Bemutató, album, fényképalbum, A felhasználók által készített bemutatók adatai ebben a táblában kerülnek tárolásra. Attribútumok  id (egész) – a bemutató azonosítója (adatbázisban)  cim (szöveg(100)) – a bemutató címe  leiras (szöveg(300)) – a bemutató szöveges leírása  indexkep (blob) – indexkép, a fő kép kicsinyített, bélyegkép változata, ez látszik áttekintő nézetben  indexfajl (szöveg(100)) – az indexkép fájlneve  megtekintes (egész) – megtekintések száma  felhasznalo_id (egész) – a készítő/tulajdonos felhasználó adatbázis oldali azonosítója  publikus (logikai) – publikus-e a bemutató  letrehozas_datuma (dátum/idő) – létrehozás dátuma, ideje Kapcsolatok  BemutatoToFelhasznalo – a bemutatók kapcsolása a létrehozó felhasználóhoz. Tulajdonos leírása

Név Szinonimák Leírás Attribútumok

cimke Címke, tags, A rögzített címkék listája található ebben a táblában.  id (egész) – a címke azonosítója (adatbázisban)  cimke (szöveg(30)) – a tag szövege

Kapcsolatok

Név Szinonimák Leírás Attribútumok Kapcsolatok

Név Szinonimák Leírás

bemutato_cimke Bemutató-címke, Az egyes bemutatókhoz hozzákapcsolt címkék  bemutato_id (egész) – a bemutató azonosítója  cimke_id (egész) – a címke azonosítója  Bemutato_cimkeToBemutato – a címkék kapcsolása bemutatóhoz (bemutató irány)  Bemutato_cimkeToCimke - a címkék kapcsolása bemutatóhoz (címke irány)

kedvenc Kedvencek, favorits A felhasználó által kedvenceknek jelölt albumok.

Attribútumok  felhasznalo_id (egész) – a felhasználó azonosítója, aki a bemutatót kedvencének jelölte  bemutato_id (egész) – a kedvencnek jelölt bemutató azonosítója Kapcsolatok  KedvencToBemutato – a kedvencek kapcsolása bemutatóhoz (bemutató irány)  KedvencToFelhasznalo – a kedvencek kapcsolása felhasználóhoz (felhasználó irány)

Név Szinonimák Leírás Attribútumok

Kapcsolatok

kep kép, képek, fotók, photo Az egyes albumokban szereplő képeket tartalmazó tábla  id (egész) – a kép azonosítója (adatbázisban)  kep (blob) – képfájl  kepfajl (szöveg(100)) – képfájl neve  belyegkep (blob) – bélyegképfájl  belyegkepfajl (szöveg(100)) – bélyegképfájl neve  kepurl (szöveg(100)) – a kép url címe  cim (szöveg(100)) – a kép címe  leiras (szöveg(300)) – szöveges leírás a képhez  hely (szöveg(100)) – a kép készítésének helye  lat (valós(10,6)) – szélességi koordináta  lng (valós(10,6)) – hosszúsági koordináta  sorszam (egész – bemutatóbeli sorszáma a képnek  aktiv (logikai) – aktív-e a kép a bemutatóban  bemutato_id (egész) – bemutató azonosítója, melybe a kép tartozik  mime_tipus (szöveg(30)) – mime típus  KepToBemutato – a kép bemutatóhoz történő hozzárendelése

Tárolt eljárások sp_bemutato_torlese: a bemutatóhoz kapcsolódó összes adatot törli: kedvencek, bemutató, képek, címkék. Nézetek v_legnepszerubb_bemutatok: A nézet visszaadja a legnépszerűbb publikus bemutatók listáját, megtekintések számát, valamint, hogy hány felhasználónál szerepel kedvencként.

v_legfrissebb_bemutatok: A nézet segítségével lekérdezhetjük a legújabb publikus bemutatókat, megtekintéseik számát, és azt, hogy hány felhasználónál szerepelnek kedvencként. v_cimkek_szam: a view adja vissza a tag-ek listáját, valamint azt, hogy az adott címkét hány publikus bemutatónál szerepel.

Adatokkal kapcsolatos műveletek előkészítése Bár az oldalak összeírásánál megjelentek az adattartalommal kapcsolatos követelmények is, a fejlesztést nagy mértékben elősegítheti, ha összeírjuk, melyik oldalon milyen jellegű adatokat várunk. Ez előrevetítheti azt, hogy hányféle adatbázis lekérdezés szükséges egy oldal megjelenítéséhez, körülhatárolhatja az egyes lekérdezések adattartalmát (pl. egy összekapcsolt lekérdezés, vagy két külön lekérdezés legyen), pontosíthatja egyes mezők vagy területek adatforrását, stb. A tervezésnek ebben a szakaszában készíthetjük elő a megfelelő lekérdezéseket, nézeteket, tárolt eljárásokat. Gyakran ezt a feladatot az egyes oldalak fejlesztése előtt végezzük el. Kisebb alkalmazásoknál ez működik is, nagyobb alkalmazásoknál azonban nehezebben ismerhetők fel különböző oldalakon ismétlődő adatigények, lekérdezési minták. Példaalkalmazásunkban a következőképpen néz ez ki pár oldal esetén: 

Főoldal o Azonosítás adatai (ez vezérli a bejelentkezési gombokat, feliratokat; sőt észrevehetjük, hogy ez az információ minden oldalon szükséges, így ezt akár globális szükségként is kezelhetjük)  bejelentkezett-e  bejelentkezett felhasználó adatai o legújabb bemutatók listája  külön lekérdezés szükséges rá, sőt ezt a lekérdezést egy adatbázis nézetben manifesztálhatjuk     

o

select b.*, f.azonosito, count(k.bemutato_id) as kedvencek_szama from bemutato b left join kedvenc k on b.id = k.bemutato_id inner join felhasznalo f on b.felhasznalo_id = f.id where b.publikus = 1 group by b.id order by b.letrehozas_datuma desc limit 10

legnépszerűbb bemutatók listája  hasonlóan az előzőhöz, ez is egy külön nézetben lesz elérhető 

select b.*, f.azonosito, count(k.bemutato_id) as kedvencek_szama

   

o

címke lista  ez is külön nézetet kap     





from bemutato b left join kedvenc k on b.id = k.bemutato_id inner join felhasznalo f on b.felhasznalo_id = f.id where b.publikus = 1 group by b.id order by kedvencek_szama desc limit 10

select c.id, c.cimke, count(bc.cimke_id) as db from bemutato_cimke bc, cimke c, bemutato b where bc.cimke_id = c.id and bc.bemutato_id = b.id and b.publikus = true group by bc.cimke_id

Bemutató o azonosítás adatai o bemutató adatai  a hozzá tartozó címkékkel együtt o bemutatóhoz tartozó képek listája o megjelenő kép adatai o bemutató tetszik-e o bemutatót kedvencek közé felvenni o bemutatót kedvencek közül törölni o következő sorszámú képre ugrani  következő sorszám meghatározása o előző sorszámú képre ugrani  előző sorszám meghatározása o tetszőleges sorszámú képre ugrani Bemutató adatainak szerkesztése o bemutató adatainak lekérdezése  címkékkel együtt o bemutató adatainak módosítása címkékkel  tranzakció keretén belül  bemutató adatainak módosítása  bemutatóhoz tartozó összes címke törlése  címkék feldolgozása  ha nincs még a cimke táblában, akkor beszúrni oda  bemutatóhoz felvinni a címkét, beszúrva bemutato_cimke táblába

Designtervek készítése A drótvázrajzok alapján elkészíthetjük az oldal designtervét. Ebben mindent definiálunk, ami az oldal megjelenéséhez szükséges: háttérképeket, elrendezéseket, színeket, stb. A designterv egy kép, amely általában megfelelő képszerkesztő

program segítségével áll elő (Photoshop vagy GIMP). A folyamat ezen szakaszában történik az egyeztetés a megrendelővel, akinek ezen a ponton van lehetősége a kinézeti elemekhez javaslatokat tenni. A kép alapján készülnek el az oldalsablonok, amik nem mások, mint a designterv alapján készült statikus oldalvázak. Ezek már definiálják az oldalaink HTML kereteit, kijelölve azokat a részeket ahova a dinamikus tartalom kerülhet, a megjelenésről pedig külön állományban elhelyezett stíluslap gondoskodik, amely ugyancsak fel van készítve arra, hogy az alkalmazásban előforduló különböző elemek (űrlapelemek, hibaüzenetek, oldalpanelek, stb) megjelenítését kezelje. Példaalkalmazásunkban az alábbi oldalak designtervét készítettük el: 

Főoldal

o



A többi oldaltól eltérő kinézetű és elrendezésű oldal, ezért külön szükséges a definiálása

Címkelista o Hozzá hasonló lesz a felhasználói lista, valamint a bejelentkezési és regisztrációs felületek, így elég csak ezt

megrajzolni.



Bemutató

o



Megint csak egy egyedi oldal, az alkalmazás legfontosabb felülete

Bejelentkezett felhasználó bemutatólistája

o



A bejelentkezett felhasználónál kicsit másabb az oldal elrendezése a bal menü miatt.

Bemutató szerkesztése

o



A szerkesztéseknél megint csak egy egyedi oldal.

Kép szerkesztése

o

Hozzá hasonló lesz a bemutató szerkesztése, új kép feltöltése

A designtervek alapján az alábbi statikus oldalak készültek el (mindegyik oldal a dyss.css és a keplista.css stíluslapok valamelyikét használja):  

Főoldal aloldal.html

      

belepes.html regisztracio.html bemutato.html lista.html keplista.html bemadatszerk.html kepszerkeszt.html

Dinamikus tartalmak jelölése Az elkészült statikus oldalsablonokban érdemes a dinamikus tartalomnak megfelelő részeket HTML megjegyzésekkel jelölni. A saját bemutatók listájában például az alábbi képen jelzett régió lesz dinamikusan töltve, amelyet a következőképpen jelezhetünk az oldal HTML kódjában:

Dinamikus tartalom jelölése

... ...