Webes képgaléria tervezése és implementációja

Átírás

1 Miskolci Egyetem Gépészmérnöki és Informatikai Kar Általános Informatikai Intézeti Tanszék Webes képgaléria tervezése és implementációja SZAKDOLGOZAT KÉSZÍTETTE: Vajóczki Erika HD7W3N 3943 Bodrogolaszi, Kossuth Lajos út 4.

2 Tartalomjegyzék 1. Bevezetés A weboldalak építőkövei A HTTP protokoll A HTML leíró nyelv A dinamikus tartalom HTML formok A HTML 5 újdonságai A CSS CSS attribútumok Szelektorok A Java EE- és a.net környezet összehasonlítása A JAVA EE környezet A Java nyelv rövid története A Java EE alkalmazásszerver és az n rétegű architektúra A megjelenítési réteg Az adatréteg Az alkalmazásszerver (Glassfish) A.Net környezet A.Net framework története röviden Megjelenítési réteg Az adatréteg Összehasonlítás Az ASP.Net A klasszikus ASP Webes fejlesztés I

3 4.3 ASP.Net fejlődése HTML kód és végrehajtható kód együtt Szerver oldali végrehajtható blokkok Az ASP.Net architektúrája Kódolási lehetőségek Az ASP.Net 1.x stílusa A modern ASP.Net stílusa Az alkalmazás tervezése és implementációja Az alkalmazás funkcióinak tervezése Regisztráció Bejelentkezés Új galéria létrehozása Galériák törlése Képek feltöltése Képek törlése Hozzászólások készítése Hozzászólások törlése Címkék készítése Címkék törlése Galériák megosztása Megosztott galériák megtekintése Keresés a képek között Admin felület Az adatbázis tervezése ER modell Relációs modell II

4 5.2.3 Az adatbázis megvalósítása Az alkalmazás implementációja Regisztráció folyamata A bejelentkezés folyamata Új galéria létrehozása Galériák megjelenítése Képek feltöltése a galériákba Galériákban található képek előnézete Galériákban található képek megjelenítése Komment írása egy adott képhez Kommentek megjelenítése Tagek hozzáadása a képekhez A megosztás beállítás menüjének felépítése A megosztás állapotának megjelenítése A megosztás típusának megváltoztatása és beállítása Galéria törlése Kép törlése galériából Tag törlése Hozzászólás törlése Megosztott tartalmak elérése Keresés a képek között Admin felület Tesztelés Továbbfejlesztési lehetőségek Összegzés Summary III

5 8. Köszönetnyilvánítás Irodalomjegyzék Mellékletek melléklet: Use case diagram melléklet: Adatbázis tábláit létrehozó SQL parancsok melléklet: Osztálydiagram melléklet: A CD melléklet tartalma IV

6 1. Bevezetés A fénykép készítés alapja egészen az ókorig vezethető vissza, ahol a görögök a camera obscura nevű eszközzel a valósághoz hű képeket tudtak előállítani. A szerkezet elején kivájtak egy lyukat, melyen keresztül fénysugarak törtek át egészen a sötét dobozig. A doboz belsejében fordított állású, kicsinyített kép keletkezett. A kapott képet kezdetben szabadkézi rajzzal örökítették meg az utókor számára. Később, a XVI. században egy lencsét helyeztek a lyuk elé, így jelentősen élesebb képet kaptak. Kezdetben csak tájképek körvonalairól készítettek alkotásokat. A világ első fényképét Nicéphore Niépce, francia feltaláló készítette 1826-ban. Az exponálási idő 8 óra volt, fekete- fehér képet kapva. A világ fejlődése a fénykép készítés folyamatát két részre osztotta. Az első részben magát a képrögzítést, a második részben pedig a képelőhívást valósították meg egy sötétkamrában. Az előhívást só oldat segítségével vitték véghez. A Kodak gyárban kidolgozták, hogy hogyan lehet a képeket tekercsen rögzíteni. A XX. század elején a Lumiérre testvérek feltalálták a színes celluloid filmet. Az első sorozatban gyártott fényképezőgép, melynek a neve a Leica volt, 1925-ben lehetővé tette, hogy a fényképezés elterjedjen a világ minden részén. A II. Világháború és a számítógépek megjelenése lehetővé tették, hogy a készített képek digitalizálásával továbbíthatóak legyenek analóg jeleken keresztül. Az 1960-as években a NASA dolgozta ki az első digitális jeltovábbítási módszert. Kezdetben az űrkutatásban és a különböző kémműholdak megjelenésében játszott nagy szerepet. Hiába kezdett elterjedni a képek digitalizálása, a fényképeket még mindig hagyományos fényképezőgépekkel készítették. Az első digitális fényképezőgép prototípusát a Kodak mérnökei 1975-ben fejlesztették ki. Az eszköz a képeket egy mágneses kazettára rögzítette. Akkoriban a számítógépek nem tudták kezelni a képeknek megfelelő adatmennyiséget, ezért használtak kazettákat. A Fuji mérnökeinek 1988-ban sikerült megtervezni az első olyan digitális fényképezőgépet, ami már a képeket a saját 16MB-os belső memóriájában tudta tárolni ben jelent meg az első LCD kijelzős fényképezőgép. Napjainkra már a mobiltelefonokba is beépítették a digitális fényképezőt. 1

7 A hordozható digitális eszközök elterjedése lehetővé tették, hogy a képeinket már nem kell magunknál hordani egy nehéz fotóalbumban, hanem bárhol, bármikor megkereshetjük és megoszthatjuk azokat másokkal. Az internet és a rohamosan elterjedő közösségi oldalak lehetővé tették, hogy a képeinket nem csak a barátainkkal és ismerőseinkkel oszthatjuk meg, hanem ha úgy akarjuk, akkor az egész világgal. A digitalizált emlékképeket szerkeszthetjük különböző képszerkesztő programokkal, olykor a valóságot is meghazudtolva, kedvünk szerint. [1] Feladatomban egy olyan képfeltöltő és megosztó rendszert szeretnék tervezni és megvalósítani, amely könnyebbé teszi képek megosztását, továbbá kényelmessé teszi ezek rendezését és tárolását egy online felhasználói felületen keresztül. Az alkalmazást webes alkalmazásként fogom megvalósítani a Microsoft ASP.Net technológiáját használva. A felhasználók az alkalmazás oldalán regisztrálhatnak és bejelentkezhetnek. A bejelentkezés után létrehozhatnak saját galériákat és ezen galériákba képeket tölthetnek fel. A galériákból képeket törölhetnek. A feltöltött képnek címet adhatnak és különböző címkéket fűzhetnek hozzá. A felhasználó galériáit megoszthatja bizonyos felhasználókkal vagy minden felhasználóval. A saját és a vele megosztott képek között a felhasználó tud keresni különböző tulajdonságok alapján. A felhasználók kommenteket írhatnak a saját és a velük megosztott galériák képeihez. Az adminisztrátorok minden felhasználó galériáját elérik, saját maguk is hozhatnak létre galériákat és azokba képeket tölthetnek fel. Az adminisztrátorok is végezhetnek keresést a képek között. Az adminisztrátorok különböző grafikonokat láthatnak. Ilyen grafikon lehet a feltöltött képek száma az idő folyamán és az adott felbontású képek száma. 2

8 2. A weboldalak építőkövei 2.1 A HTTP protokoll A HTTP (Hypertext Transfer Protocol) az a kommunikációs mechanizmus, amelynek segítségével a böngészők és a webszerverek kommunikálnak egymással. Az ISO OSI modelljének alkalmazási rétegében helyezkedik el, a TCP/IP protokollra támaszkodva. A HTTP kezdeti verziói egy egyszeri GET kérést támogattak, egy nevesített erőforrás elérésére. A kérés hatására a szerver feladata volt, hogy a fájlt szövegfolyamként elküldje. A HTTP protokoll első hivatalos specifikációja (HTTP 1.0) az 1990-es évek közepén került kiadásra, ami már összetettebb üzenet áramlást tett lehetővé. Napjainkban a HTTP 1.1 verzióját használjuk. A HTTP több egyszerű parancsra épül. A két legfontosabb a GET és a POST, de hasonlóan fontos a HEAD és a PUT parancs. A GET parancs lekéri a kérésben egy URI által azonosított információt. A HEAD parancs csak a fejléc információt kéri le, a válasznak nincs törzse. A POST metódus olyan információt tartalmaz, amelyet szeretnénk, hogy a szerver feldolgozzon. A PUT szintén információ küldésére használatos. Az alábbiakban egy GET kérés látható, amit egy böngésző küldött a helloworld.htm lekérésére. A böngésző a kérést a Host HTTP header mezőben szereplő szerverre küldi. A header tartalmaz még részleteket a böngésző típusáról, az operációs rendszerről, a beállított nyelvről, stb. Amikor a szerver megkapja ezt a kérést, a kért erőforrást szövegfolyamként küldi vissza. A böngésző ezt értelmezi és formázva jeleníti meg a tartalmat. GET /aspnet4sbs/helloworld.htm HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,..., */* Accept-Language: en-us Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1;....NET CLR ) Host: localhost:80 Connection: Keep-Alive A következő kód a szerver által küldött választ mutatja. A válasz egyszerű HTML tartalmat is magába foglal. A böngészőben a válaszban szereplő header információkat nem látjuk. Az első sor a protokoll verziót és a visszatérési kódot mutatja. A 200-as kód azt jelenti, hogy OK. A válasz tartalmazza még a kérés idejét, a kért fájl utolsó módosításának idejét és hogy milyen típusú tartalom kerül küldésre. Ezen információk a cachelés során hasznosak. A válasz további része a tényleges HTML fájl szövegtartalma a szerverről. [2] 3

9 HTTP/ OK Server: Microsoft-IIS/5.1 X-Powered-By: ASP.NET Date: Thu, 01 Nov :44:04 GMT Content-Type: text/html Accept-Ranges: bytes Last-Modified: Mon, 22 Oct :54:20 GMT ETag: "04e9ace185fc51:bb6" Content-Length: 130 <html> <body> <h1> Hello World </h1> Nothing really showing here yet, except some HTML... </body> </html> 2.2 A HTML leíró nyelv A HTML (Hypertext Markup Language), olyan egységes leíró nyelv, melyet minden böngésző támogat. A HTML fájlok szöveges állományok, amiket a legegyszerűbb szövegszerkesztővel is szerkeszthetünk. Ebben a fájlban találhatóak a nyers szövegek és a szimbólumok, amelyek leírják a böngészőnek, hogy jelenítse meg és hogyan dolgozza fel a fájl tartalmát. Valójában egy HTTP kérés végrehajtásakor egy formázott szövegtartalmat kapunk eredményül. A HTML 1.0-ás verziójában alakult ki az alapvető szerkezet, a nyitó és záró tagek "<html> </html>", a fejléc <head> </head>, és a törzs, azaz a "<body> </body>". Ezeknek az elemeknek a zárótagje nem volt elhagyható. A tartalom a dokumentum törzsében helyezkedik el, létre lehet hozni bekezdéseket, hivatkozásokat, felsorolásokat. A HTML 2.0- ás verzió, mindazon által, hogy magába foglalja az előző verzió tulajdonságait, ezen felül elkülönül még a böngésző által szabályozott és a dokumentum szerkezetében létrehozott formázás. A következő kiadott verzióba kerültek bele az űrlapok, az ezen belüli többsoros szövegbevitel, és a kiválasztható opciók. Később a HTML 3.2 verziót 1996-ban fogadta el a W3C, ami jelentős változásokat hozott. Innentől van lehetőségünk Java appletek beágyazására, és scripteket is innentől használhatunk. Lehetőségünk van táblázat készítésre, és betűtípust állítani. A HTML 4.0 igazából egy SGML (Standard Generalized Markup Language) alkalmazás. Fejlesztésekor szem előtt tartották a csökkent képességűek érdekeit, a nemzetközi karakter készleteket, a jobbról balra olvasás támogatását. Tovább fejlesztették az űrlapok és táblázatok használhatóságát, a keretek (frame-ek) használata hivatalossá vált. Az XHTML 1.0-ás verzió magába foglalja a HTML 4-et, és az XML-t is. XML alapokon 4

10 nyugszik, mivel együtt kell működniük az XML alapú böngészőkkel. Az XHTML a HTML 4 három dokumentumtípusának XML alapú továbbfejlesztése. Ez kompatibilis az XML és a HTML4-es böngészőkkel is. Számos előnye van a használatának. Megfelel az XML előírásainak, szerkeszthetők alap XML eszközökkel is, és régebbi szerkesztő programmal is. Hasznosíthatják az alkalmazásokat (Java appleteket, scripteket), aminek futtatásához szükséges vagy a HTML DOM (Document Object Modell), vagy XML DOM. Az XML-ben viszonylag könnyű új elemet bevezetni. Az XHTML család úgy lett megtervezve, hogy ezeket a kiterjesztéseket hozzáillessze az XHTML technikákon keresztül az újonnan kifejlesztendő XHTML modulokhoz. Úgy lett kifejlesztve, hogy rugalmasan működjön együtt a különböző böngészőkkel. [2] A dinamikus tartalom Kezdetben a weboldalak statikus HTML lapok használatával épültek fel, melyek akkoriban elegendőek voltak, ám a későbbiekben igényt tartottak a dinamikus tartalmakra. A HTML tartalmaz olyan tageket, mint például a <select> </select>, ezt a böngésző úgy értelmezi, mint egy legördülő listát. A <select> tagen belül az egyes opciókat az <option> </option> taggel jelöljük. A tageknek lehetnek attribútumaik, amelyek módosíthatják vagy alakíthatják a tag viselkedését. Az <input> </input> tag használatával beviteli mezőket és gombokat adhatunk meg a különböző attribútumok használatával. A HTML biztosít egy speciális taget, a <form> </form> taget, amely csoportosít beviteli tageket és az a célja, hogy a kinyert információt feldolgozásra küldje a szervernek. [2] HTML formok A <form> </form> nyitó és záró tag használatakor a böngésző ezen elemek által magába foglalt beviteli vezérlők tartalmát küldi el a szervernek feldolgozásra. Ezt a tartalmat fogja feldolgozni a szerver és visszaküldi a kliensnek a kapott eredményt. Ezt a folyamatot postbacknek hívjuk. Ez az oka annak is, hogy HTTP használata során, az a HTML dokumentum lekérése a GET metódussal történik, az adatok visszaküldése a szerverre pedig a POST metódussal (vagy a GET egy speciális változatával). A <form> tag action attribútumával beállítható, hogy milyen URL-re történjen a küldés. Ha nincs beállítva az action értéke, akkor az oldal jelenlegi URL-je kapja meg a feldolgozó szerepet. A method nevű attribútummal azt adjuk meg, hogy milyen HTTP metódust használjon a form elküldésére a szervernek a böngésző. A lentebbi példában a GET metódus van beállítva. Ebben az esetben az űrlapon beállított értékek az URL-hez történnek hozzáfűzésre és ezen 5

11 URL kerül elküldésre a szervernek A POST metódus a form tartalmát a HTTP csomag törzsében küldi vissza. <html> <body> <form action= method="get"> <h2>hello there. What's your favorite.net feature?</h2> <select name='feature'> <option> Type-Safety</option> <option> Garbage collection</option> <option> Multiple syntaxes</option> <option> Code Access Security</option> <option> Simpler threading</option> <option> Versioning purgatory</option> </select> <br/> <input type=submit name='lookup' value='lookup'></input> <br/> </form> </body> </html> Tehát a <form> taget hozzáadva az oldal törzséhez lehetővé tesszük, hogy egy HTTP alkalmazás interakcióba lépjen a felhasználóval, így kiküszöbölve a HTTP protokoll állapotmentességét. A postback feldolgozása különböző módon történhet a szerver oldalán. A legkorábbi szabvány webes alkalmazások készítésére, amelyek ilyen postbacket dolgoznak fel a CGI (Common Gateway Interface) volt. A CGI lehetővé tette, hogy egy szerveren futó program valós időben változtassa a kimenetét annak függvényében, hogy milyen paramétereket kapott egy postback során. Minden beérkező kérés a program egy külön példányának indítását váltotta ki a szerveren. Manapság a webes alkalmazások írása php, Java vagy Microsoft ASP.Net technológiákat használva történik. [2] A HTML 5 újdonságai A HTML 5 a modern igényekhez igazodva elavult tageket kivezet és új hasznos tageket vezet be. Bevezet új szemantikai elemeket, mint például az <article>, amely cikk vagy bejegyzés jelölésére alkalmazható, a <section>, amellyel a tartalom szekciókra bontható és a <footer>, ami láblécet jelöl. Bevezet új űrlapvezérlőket, mint a dátum és az idő kiválasztás és a naptár. Bevezet multimédia elemeket, mint az <audio> és a <video> tagek, amelyek hang- és videótartalom beágyazására szolgálnak. Bevezeti még a <canvas> elemet, ami rajzterületnek használható és a rajzolás Javascriptből történik. A HTML 5 ezeken kívül lehetőséget ad a drag and drop használatára, így a böngészőbe húzott elemet felhasználhatjuk. A HTML 5 web storage adat tárolására biztosít lehetőséget a felhasználó böngészőjében a cookie kiváltására. [3] 6

12 2.3 A CSS A CSS (Cascading Style Sheets) stíluslapok segítségével az elkészített HTML nyelven írt oldalakhoz különböző formázási eljárásokkal tetszőleges arculatot tudunk adni. Ez azt jelenti, hogy nemcsak strukturálni szeretnénk a tartalmat, hanem azt is, hogy az egyes részletek, címek, bekezdések, képek hol és hogyan jelenjenek meg. A lentebb található HTML kódrészletben láthatjuk, hogy szerepelnek az elemekhez tartozó olyan attribútumok, melyek segítségével befolyásolni tudtuk az elem megjelenését. Ilyen attribútum például az align, mely az igazításban játszik szerepet, vagy a <font> </font> tag, amellyel betűtípust, betűméretet és színt adhatunk meg. <p align="center"> <img src="logo.jpg" border="1" /> <font size="10" color="red"> Ez itt egy nagy piros szöveg középre igazítva. </font> </p> Ezen kódok használatával az a baj, hogy a tartalom és a megjelenés keveredik egymással, amely például a kód olvashatóságát ronthatja, vagy minden oldalon újra és újra kell definiálnunk ugyanazt az arculati beállítást. A probléma megoldására szolgál, hogy a HTML oldalból ki kell emelni a megjelenésért felelős elemeket és attribútumokat, amelyeket egy külön fájlba definiálunk, majd ezen fájl tartalmára elegendő a HTML forrásban hivatkozni. Ezt az eljárást valósítja meg a CSS technológia. [4] CSS attribútumok A HTML attribútumokra nincs szükség, helyettük a CSS saját attribútumokkal dolgozik. Az attribútumok beállítását név-attribútum érték páros formájában adjuk meg, melyek rögzítettek és az összes megjelenéssel kapcsolatos területet, például: méretek, távolságok, színek, pozíciók stb. lefedik. Léteznek olyan HTML és CSS attribútum nevek, melyek teljesen megegyeznek, vagy hasonlóak. A fent szereplő HTML kódban található a color attribútum, mely megtalálható a CSS-ben is, annyi kikötéssel, hogy az értéke megadásakor nem használunk idézőjeleket és az értékadás után pontosvesszőt teszünk. Az align helyett CSS attribútumként pedig a text-align név-attribútumot használjuk, ahogy ezt a lentebbi kódban is láthatjuk. [4] text-align: center; color: red; 7

13 2.3.2 Szelektorok A CSS szelektorok (CSS selectors) megadják, hogy az adott stíluslapok melyik HTML elemre vagy elemekre hivatkozzanak. Ha egy adott arculatot akarunk az összes HTML elemre érvényesíteni, akkor a * (csillag) szelektort kell alkalmaznunk. A * karakter után kapcsos zárójelek közé rakjuk a rá vonatkozó stílusbeállításokat. Hivatkozhatunk még továbbá adott HTML elem nevére, ebben az esetben az összes helyen, ahol ezt az elemet használjuk, ugyanolyan lesz a stíluskinézet. Hivatkozhatunk egy konkrét elemre is, de ahhoz, hogy ezt meg tudjuk tenni, az adott elemnek létre kell hozni a HTML kódban egy id nevű azonosítót, amelyre a # karakter megadása során hivatkozva tudunk stílusformát beállítani. Ha csak néhány kitüntetett helyen akarunk alkalmazni egy stílust, akkor célszerű létrehozni egy saját stílus osztályt tetszőleges névvel,. (pont) karakterrel az osztály neve előtt. Ezután azon a helyen, ahol ezt használni akarjuk, a HTML elem class attribútumában tudunk rá hivatkozni. Ez a négy leggyakrabban használt szelektor. Léteznek még pszeudo-osztályok (pseudo-class), melyek lehetővé teszik a speciális tulajdonságokkal rendelkező elemek kiválasztását és ahhoz stílus definiálását. Ilyen pszeudo-osztály például a hiperhivatkozás az a szelektor felhasználásával, a hover, amely ha az adott elem fölé visszük a kurzort, akkor változik meg az állapota, a visited, azaz hogy meglátogattuk-e már a hivatkozott oldalt. [4] 8

14 3 A Java EE- és a.net környezet összehasonlítása 3.1 A JAVA EE környezet A Java nyelv rövid története Az 1990-es évek elején a SUN, James Gosling vezetésével egy olyan belső projektet dolgoztak ki, amelyben szükség volt egy olyan programozási nyelvre, amely platformfüggetlen. Elsőnek a set top boxoknál alkalmazták. Mivel nem volt eléggé tökéletes, maga a projekt és vele együtt a nyelv is feledésbe merült. Az 1990-es évek közepére az internet elterjedése lehetővé tette, hogy ezt a projektet újra elővegyék, melynek eredménye a Java nyelv első verziója lett. A Java egyszerre programozási nyelv és platform is. A nyelv tulajdonságai még egyértelműen a platform- függetlenség, objektum orientáltság, egyszerűség, elosztottság, általános célja van, interpretáltság, robosztusság, biztonságosság, hordozhatóság, többszálúság. A Java platformnak három kiadása jelent meg, melyek a következők: Java Standard Edition (Java SE): hagyományos desktop alkalmazások, appletek készítése. Java Micro Edition (Java ME): korlátozott erőforrásokkal rendelkező, jellemzően mobil eszközökre való fejlesztés. Java Enterprise Edition (Java EE): elosztott, sok felhasználóval rendelkező, vállalati méretű szoftverrendszerek kialakítása, az Enterprise technológiák mellett a Java EE-ben rendelkezésre áll a Standard Java API is. Azok a követelmények, melyeket egy Java EE platformon fejlesztett alkalmazásnak biztosítania kell, azokat nevezzük middleware szolgáltatásoknak. Ilyen szolgáltatások például a rendszer biztonságossá tétele, az adatok perzisztens kezelése, a rendszer távoli elérése, többszálúság biztosítása, skálázhatóság, névszolgáltatás és az aszinkron üzenetküldés támogatása. [5] A Java EE alkalmazásszerver és az n rétegű architektúra Az architektúrában szorosan egymásra épülő rétegeket különböztetünk meg, melyeknek feladatuk, hogy jól definiált szolgáltatásokat nyújtsanak a felettük lévő rétegeknek. (1. ábra) 9

15 1. ábra: Az n rétegű architektúra Kliensréteg: biztosítja az alkalmazás felhasználói felületét. Két fajtáját különböztetünk meg. Vastag kliens, mely hagyományos desktop alkalmazás. Vékony kliens pedig a böngésző, amely biztosítja az oldalak megjelenését. Webréteg: a böngészőből érkező HTTP kéréseket értelmezi, meghívja a megfelelő üzleti logikát és előállítja a megfelelő választ. Üzleti logikai réteg: biztosítja a konkrét alkalmazási terület igényeinek megfelelő funkcionalitását úgy, hogy az üzleti szabályok figyelembe vételével hívja meg az adatbázis szolgáltatásait. Adatréteg: az adatok perzisztens tárolása és azokon végezhető műveletek támogatása a feladata. Akkor beszélünk három-rétegű architektúráról, ha az alkalmazásunkat adatrétegre, logikai rétegre és kliensrétegre osztjuk fel. A Java környezetben fejleszthető szoftverkomponensek konténerben futnak. A konténer biztosítja futási időben a middleware szolgáltatásokat. Magát az alkalmazásszervert web- és Enterprise JavaBean (EJB) konténerre osztjuk fel. A komponensek lazán kapcsolódnak egymáshoz, újrafelhasználhatók. [5] A megjelenítési réteg Kezdetben a webes tartalmak előállításához statikus HTML oldalakban jelentek meg, melyeket linkek kötöttek össze. Ahogy az internet rohamosan elterjedt, szükség volt arra, hogy dinamikus elemeket is tartalmazzanak ezen oldalak. Ezért előtérbe kerültek a felhasználók kényelmességét kiszolgáló dinamikus linkek és űrlapok. A későbbiekben 10

16 megjelentek a script nyelvek, melyek HTML oldalakat állítottak elő. Egyre inkább elterjedtek az olyan technológiák, melyekkel HTML oldalakat lehetett előállítani. A Java EE egy olyan platform, mely már egy lefordított kódot futtat és áttekinthető, szabványos struktúrájú alkalmazások előkészítését teszik lehetővé. A szervlet, mint az első szerveroldali webes Java technológia megjelenésével tetszőleges protokoll szerinti kérésekre generálhatunk választ, de vannak olyan szervletek is, amelyek csak HTTP kérések feldolgozására és megváltoztatására alkalmazhatóak. A szervletek életciklusát egy szervletkomponens kezeli. Ez a szervlet konténer a webszerverrel együttműködve biztosítja a kérések eljutását a szervletekhez, majd a kérés feldolgozása után a választ generál és visszajuttatja azt. Magáról a szálkezelésről is a webkonténer rendelkezik. A szervleteknek három életciklusát ismerjük: inicializáció, kiszolgálás és eltávolítás. Mivel az előállított Java forráskód tartalmazni fogja a HTML részleteket is, ezért megjelent egy olyan technológia, mely egyszerű szövegfájlként, statikus jelölőelemekkel képes dinamikus tartalmat generálni. A JavaServer Pages, azaz a JSP lehetővé tette a fejlesztői szerepek különválasztását is. A JSP oldalak szervletekké fordulnak le, és ha módosítunk egy JSP oldalt, akkor automatikusan megtörténik az újrafordítás. [5] Az adatréteg Az adatbázis hozzáférés támogatója a Java Database Connectivity (JDBC) API. A JDBC magába foglalja a lekérdezésekhez és az adatbázist módosító osztályokat és metódusokat. A relációs modellhez igazodik. A Driver Manager-en keresztül az API biztosít egy mechanizmust a Java csomagok betöltésére. Ez a driver, egy kliensoldalon fut. [5] Az alkalmazásszerver (Glassfish) A Glassfish egy olyan Java EE specifikációval kompatibilis alkalmazásszerver, mely biztosítja a megírt alkalmazás futtatását és elérését, illetve az adatréteggel való kommunikációt. [5] 3.2 A.Net környezet Ahogyan a Java EE is használja az n rétegű architektúrát, úgy a.net keretrendszer is támogatja annyi eltéréssel, hogy az egyes rétegekben a Microsoft eszközei vannak jelen (2. ábra). Ez a keretrendszer egy olyan szoftver komponens, melyet maga a Windows operációs rendszer tartalmaz. Maga a.net platform a CLI (Common Language Infrastucure) 11

17 implementációja. A CLI a Microsoft, Hewlett Packard, az Intel és sokan mások közreműködésével megfogalmazott szabályrendszer, mely három részre oszlik. Ez a három rész: a CTS (Common Type System), mely az adatok kezelését, a memóriában való megjelenést, az egymással való interakciót írja le, aztán a CLS (Common Language Specification), ami a CLI kompatibilis nyelvekkel kapcsolatos elvárásokat tartalmazza, és végül a VES (Virtual Execution System), azaz a futási környezet specifikációja, amit CLRnek is neveznek. A.Net keretrendszerre írt alkalmazások egy CLR (Common Language Runtime) futtatási környezetben hajtódnak végre. A keretrendszert az osztálykönyvtár és a CLR együtt alkotja. 2. ábra: Az n rétegű architektúra.net esetén Webkiszolgáló: A Microsoft webes platformjának alapja az Internet Information Services (IIS). A kiszolgáló dolga, hogy értelmes módon válaszoljon a kérésre. Az IIS saját könyvtár egészét kezelhető darabokra, virtuális könyvtárakra bontja. Egy-egy virtuális könyvtár, egy alkalmazásra hivatkozik. A Microsoft architektúra Dinamic Link Library (DLL) segítségével válaszol a kérésekre. A virtuális könyvtárfájlokat mind leképezik egy-egy DLL-re, így ezek szabják meg az IIS-nek, hogy az adott kérést melyik DLL-nek kell kezelnie. [5],[6] A.Net framework története röviden Amikor a 90-es évek közepén a SUN kiadta a Java platform első nyilvános változatát, a többi programnyelvek és platformok nem tudták felvenni vele a versenyt. Válaszképp a 90- es évek vége felé elindult a Microsoft által egy olyan projekt, melynek eredményeképpen megszületett a.net. A.Net a COM platformot váltotta le. A COM ma is létezik, számos.net könyvtár épít rá. A.Net mára olyannyira elterjedté vált, hogy minden Microsoft fejlesztői platformon használják, többek között a hagyományos asztali alkalmazásokban, mint például 12

18 a Windows Forms, a WPF, a weben ASP.Net, ASP.Net MVC, Silverlight és az okostelefonokon is, azaz a Windows Phone platformon. [6] Megjelenítési réteg Annak érdekében, hogy a webfejlesztés elérhető legyen Microsoft platformon is, a Microsoft megalkotta az Active Server Pages-t (ASP). Az ASP széles körben használt programozási nyelveket biztosít, mint például a Visual Basic. Ebben a fejlesztői környezetben a webes kéréskezelő keretrendszer osztályokból épül fel. Egy oldal életciklusa az a folyamat, mely meghatározza, hogy az egyes objektumai mikor születnek, mikor hajtódnak végre az eseményeik, és mikor szűnnek meg az objektumok majd lefutnak a hozzájuk rendelt események. Az események lehetnek változást követőek vagy akciót követőek. Az események után végrehajtódik a kinézet kialakítása, majd végül megszűnnek az objektumok. A postback egy esemény, amely automatikusan akkor hajtódik végre, amikor egy akció generálódik a kliens oldalon. Ennek az eseménynek az a feladata, hogy küldjön egy újabb kérést a szervernek megadva azt is, hogy mely esemény váltotta ki a postbacket. [5] Az adatréteg A.Net-ben kétfajta adatbázist különböztetünk meg. Az egyik a hagyományos mód, a másik pedig a LINQ. A hagyományos módban az adatbázisunkat úgynevezett Data Provider-eken keresztül érjük el. A lekérdezett adatokat pedig a DataSet objektumban tároljuk. Ez lehetővé teszi, hogy nincs szükség folyamatos kapcsolatra az adatbázisszerverrel. Ha nincs kapcsolatunk a szerverrel, akár létrehozhatunk egy másolatot (DataSet) az adatbázisunkról, majd ha elvégeztük a módosításokat, visszavezethetjük az adatbázis szerverünkre. A szinkronizációt DataAdapter- nek hívjuk. [5] 3.3 Összehasonlítás A két fejlesztő környezetben sok hasonló működési funkciót fedezhetünk fel, ám vannak egyedi, csak az adott fejlesztésre jellemző viselkedések is. Minden Java EE szereplő implementálja a saját termékeit a specifikációnak megfelelően. A Java-nak megtalálható sok ingyenes, nyílt forráskódú eszköze. Így az egyes specifikációk kompatibilitása megkérdőjelezhető. Ezzel szemben a.net esetében nemcsak specifikáció, hanem konkrét termékek állnak rendelkezésre, melyek fejlesztését kizárólag a Microsoft végezte. 13

19 4. Az ASP.Net 4.1 A klasszikus ASP A Microsoft eredetileg azért fejlesztette az ASP-t (Active Server Pages), mert bővíteni szerette volna azon felhasználók körét, akik C++ programozási nyelven szeretnének webalkalmazásokat készíteni. Amikor az IIS (Internet Information Services) elérhetővé vált, egy alkalmas környezetet biztosított a Microsoftos technológiákkal készült weboldalak számára maga mögött hagyva más programozási környezeteket. Valójában még a mai nap is találni olyan weboldalakat, amelyeket tiszta ISAPI DLL technológiákkal készítettek. Ezt onnan ismerhetjük fel, hogy úgynevezett query stringek épülnek be a böngésző és a szerver közé. Például találhatunk egy fájl nevében egy olyan ACMEISAPI.DLL-t, ami beágyazódott a query string-be. Mindazonáltal létrehozni egy olyan weboldalt, ami teljes egészében az ISAPI DLL-t használja, nagyon elrettentő lehet. A C vagy C++ nyelven írt ISAPI DLL teljes irányítást nyújt afelett, hogy az elkészített weboldal hogyan fog működni. Azonban nagy kihívást jelent C vagy C++ nyelven fejleszteni. Tehát az ASP rendelkezésre bocsát egy olyan Microsoft által létrehozott ISAPI DLL-t, melyet szimplán ASP DLL-nek neveztek el. Az ASP webfejlesztők a kódjaikat az.asp kiterjesztéssel látták el. Ezek az.asp kiterjesztésű fájlok gyakran tartalmaznak statikus HTML-t és végrehajtó szekciók keverékét, melyek futási időben eredményeznek kimenetet. A lentebb található ASP kódrészlet egy HelloWorld oldalt jelenít meg, amely statikus HTMLt és generált szövegrészt is tartalmaz, amit futási időben kerül generálásra. <%@ Language="javascript" %> <html> <body> <form> <h3>hello world!!! This is an ASP page.</h3> <% Response.Write("This content was generated ");%> <% Response.Write("as part of an execution block");%> </form> </body> </html> Az IIS a kéréseket a 80-as porton ellenőrzi. Ha a HelloWorld.asp fájltól érkezik egy kérés, akkor azt az IIS megvizsgálja, hogy mi a kiterjesztése. Ha.asp a kiterjesztése, akkor továbbküldi az ASP.DLL-nek a kiszolgálást. Az ASP.DLL egyszerűen kiolvassa a statikus 14

20 HTML kódot, ami most a Hello world!!! This is an ASP page. Majd amikor odaér a <% %> tagekhez, akkor az ezen tagok közötti tartalmat úgy futtatja le, hogy átnézi egy JavaScript elemzővel. [2] 4.2 Webes fejlesztés A webalkalmazások fejlesztése során két jelentős dolgot kell figyelembe vennünk. A felhasználói felület (UI) megvalósítása a HTML használatával, ami nem egy folyamatos kapcsolatot lehetővé tevő protokoll és az alkalmazás állapotának menedzselése. Ezek az alapvető tevékenységek elkülönítik a webes fejlesztést a többi alkalmazás fejlesztéstől. Sok szempontból a programozási modell visszatért ahhoz a formájához, amely az 1970-es évek közepén uralkodott, amikor még nagy mainframe-ek szolgálták ki terminálokon keresztül a felhasználókat. A felhasználók munkájukat ezeken a terminálokon végezték. Mára ez a terminál sokkal különlegesebb, hiszen ez egy nagy teljesítményű számítógép, melyen egy böngésző fut, ami értelmezi a HTML kódot. Az a végpont, amihez a böngésző csatlakozik, egy web szerver (vagy talán egy szerverfarm). Valamint az egész kommunikáció egy olyan protokollon keresztül valósul meg, ami a felhasználó és a szerver között közvetett kapcsolatot teremt, a kérés és a válasz akár az egész Földön keresztülmehet. A webes alkalmazás fejlesztésben a program elsődleges feladata, hogy a kapott kérésekre válaszoljon. Ez gyakran bonyolult HTML kód generálását jelenti, ami a felhasználók böngészőjében olvasható formában jelenik meg. Ez magában foglalja akár adatbázis műveletek végrehajtását, a felhasználó autentikációját és rendelésének követését. A keretrendszerek, ahogy a klasszikus ASP is jó úton haladt afelé, hogy a webes fejlesztést egyszerűbbé tegyék, a fejlesztőknek még mindig maradtak olyan funkciók, amelyek saját maguknak kell létrehozni. Például klasszikus ASP-ben felépíteni egy biztos, kezelhető oldalt azt jelentette, hogy hozzá kellett írni egy biztonsági alrendszert, vagy éppen meg kellett vásárolni azt. Viszont ennek az alrendszernek a kezelése szintén nem volt egyszerű feladat. [2] 4.3 ASP.Net fejlődése Ezzel el is jutunk az ASP.Net-hez. Egy bevett szokás, hogy az ASP.Net keretrendszerbe bekerülnek olyan funkciók, amelyeket fejlesztők gyakran implementálnak, így lerövidítve a későbbi szoftverek fejlesztési idejét. Az ASP.Net az első kiadását követően folyamatosan fejlődik. Az ASP.Net 1.0-ás verzióban bemutattak egy jól definiált csővezetéket (pipeline), 15

21 egy továbbfejleszthető modellt és egy olyan szerveroldali vezérlő renderelési modellt, amelyek segítségével könnyebben implementálhatóvá tették a webes alkalmazásokat. Az ASP.Net 2.0-ás verziója az 1.x-es verziókat felhasználva magasabb szintre emelte a keretrendszert. Többek között integrálta az autentikációs és az autorizációs szolgáltatásokat. Több, mint 2 éve használták a 2.0-ás verziót, viszont még mindig volt fejleszteni való. Az ASP.Net 3.5-ös verzió számos jelentős újdonságot hozott. Többek között támogatott lett az AJAX (Asynchronous JavaScript and XML). Másik fő jellemzője, hogy támogatja a Windows Communication Foundation alkalmazás hostolását IIS, illetve ASP.NET-en keresztül. A következő kiadott verzió az ASP.Net 4, amiben az AJAX támogatása tovább fejlődött, támogatja a dinamikus adatot, implementálja a Modell-View-Controller tervezési mintát és támogatja a Microsoft Silverlight-ot. [2] 4.4 HTML kód és végrehajtható kód együtt A klasszikus ASP-ben az oldalon belül a végrehajtható kódszegmenseket meg lehetett jelölni. Az ASP támogatta a klasszikus script tageket, <script> </script> tag és az ezen tagek közötti tartalmat végrehajtható kódként értelmezte. Azonban a klasszikus ASP-ben a script blokkok a böngészőnek kerültek elküldésre, az ő feladata volt a végrehajtás. Ezeken a kliensoldalon végrahajtandó szkripteken kívül a klasszikus ASP weblapon szerveroldalon végrehajtandó szkript blokkokot is lehetett definiálni. Ezek a módszerek gyakran hajtottak végre olyan feladatokat, mint például az adatbázis műveletek. A lenti kódsorban a kacsacsőrök és a százalékjelek közötti kód a szerveren hajtódik végre: <% ExecuteMe() %> Az ASP.Net szintén támogatja a szerver oldali kód végrehajtását is. Ahhoz, hogy az ilyen kódot megjelöljük, ugyanúgy a <% %> jeleket használjuk. Amikor az ASP elemzi a fájlt, elkészíti azt az osztályt, ami futásidőben reprezentálja az oldalt. Az osztályt a tagek közötti kódsorokból állítja elő. Az egyetlen kritérium az, hogy a végrehajtó tagek között értelmes C# kódok szerepeljenek (illetve olyan nyelvű kód, ami a Page diraktívában meg lett jelölve). Az alábbi kódrészlet szinte teljesen megegyezik egy klasszikus ASP-ben létrehozott alkalmazással, beleértve a Response objektumra való hivatkozásokat. A Response objektum a klasszikus ASP-ben tulajdonképpen egy COM objektum volt. Az ASP.Net-ben szereplő Response objektum az ASP.Net által kezelt HttpContext része és semmi köze a klasszikus ASP objektumához, csupán csak a nevük egyezik meg. [2] 16

22 Page Language="C#" Debug="true" %> <html> <body> <h1>hello World!!!</h1> <% // This block will execute in the Render_Control method Response.Write("Check out the family tree: <br/> <br/>"); Response.Write(this.GetType().ToString()); Response.Write("which derives from: <br/> "); Response.Write(this.GetType().BaseType.ToString()); Response.Write("which derives from: <br/> "); Response.Write(this.GetType().BaseType.BaseType.ToString()); Response.Write("which derives from: <br/> "); Response.Write(this.GetType().BaseType.BaseType.BaseType.ToString()); Response.Write("which derives from: <br/> "); Response.Write(this.GetType().BaseType.BaseType.BaseType.BaseType.ToString()); %> </body> </html> 4.5 Szerver oldali végrehajtható blokkok Az ASP.Net támogatja a szerver oldali végrehajtó blokkokat is. Biztosít egy olyan új runat nevű attribútumot, ami azt mondja meg az ASP.Net-nek, hogy hajtsa végre szerveroldalon az adott kódblokkot. Ezt szemlélteti a lentebbi kód is. Fontos a beállított Page direktívában megadott nyelv, ilyen nyelvű kódot írhatunk. A ShowLineage() metódust az oldalon belül meghívják. A <script> tagek közötti kód tartalmazza a ShowLineage() metódust a runat attribútummal együtt. Ezek együttes használatával azt érjük el, hogy az ASP.NET végrehajtja a kódot a szerveren. 17

23 Page Language="C#" Debug="true" %> <script runat="server"> void ShowLineage() { Response.Write("Check out the family tree: <br/> <br/>"); Response.Write(this.GetType().ToString()); Response.Write("which derives from: <br/> "); Response.Write(this.GetType().BaseType.ToString()); Response.Write("which derives from: <br/> "); Response.Write(this.GetType().BaseType.BaseType.ToString()); Response.Write("which derives from: <br/> "); Response.Write(this.GetType().BaseType.BaseType.BaseType.ToString()); Response.Write("which derives from: <br/> "); Response.Write(this.GetType().BaseType.BaseType.BaseType.BaseType.ToString()); } </script> <html> <body> <h1>hello World!!!</h1> <% ShowLineage(); %> </body> </html> A klasszikus ASP értelmezi a script blokkot a megadott script nyelv segítségével. Az ASP.Net egy teljesen különböző végrehajtási modellel rendelkezik, amely az egész oldalból egy osztály állít elő, ami a Common Language Runtime (CLR) alatt fut. [2] 4.6 Az ASP.Net architektúrája Amikor webszerverről beszélünk, akkor a HTTP kérések/válaszok sok szerveroldali objektumon keresztülmenve kerülnek feldolgozásra. Egy kérés végigfutásának útját a szerveren, az IIS/ASP.NET csővezeték (pipeline) határozza meg. A legjobb módja, hogy megértsük a HTTP kérés útját az ASP.Net-ben, ahhoz követnünk kell a kérést, ami a böngészőből származik és az IIS fogadja. Amikor egy felhasználó megnyomja az enter gombot miután begépelt egy URL-t, a böngésző egy HTTP GET kérést küld a kijelölt oldalnak. A kérés keresztülhalad routerek sorozatán, míg végül eléri a kiszolgálót a 80-as porton. Ha a kiszolgálón van olyan szoftver, ami a 80-as portot figyeli, akkor képes kezelni a kérést. A Microsoft platformon a 80-as portot legtöbb esetben az IIS figyeli. Az ASP.Net működéséhez jelenleg három IIS verzió megfelelő: az 5.x-es verzió (Windows XP Professional operációs rendszer esetén), a 6.x-es verzió (Windows Server 2003 operációs rendszernél) és a 7.x-es verzió (Windows Vista, Windows 7, vagy Windows Server 2008 operációs rendszereknél). 18

24 A kérések általános útja nem függ az IIS verzióitól. Az IIS tartalmazza a leképzéseket a fájlok kiterjesztései és a programok között, ami képes értelmezni a kéréseket. Amikor egy kérés érkezik, akkor az IIS beolvassa a fájl nevét, ami a kérésben szerepel, és átirányítja a kérést a megfelelő komponenshez. Amint az IIS fogadja a kérést és hozzárendeli a megfelelő feldolgozó process-hez, a kérés egy nagyon speciális utat követ a csővezetéken keresztül. Az alábbi lépésekben láthatjuk a csővezeték szakaszait részletesebben. Az IIS korábbi verzióiban, tehát a 7.x-estől korábbi verzióban is ezek a szakaszok jellemzőek: 1. Egy kérés érkezik az IIS-hez. 2. Az IIS átirányítja a kérést az aspnet_isapi.dll-nek. a. ha az IIS 5.x-es verziója fut, akkor az IIS aspnet_isapi.dll átirányítja a kérést egy csövezetéken keresztül az aspnet_wp.exe-hez (3. ábra) b. ha az IIS 6.x-es verziója fut, akkor a kérés már a megfelelő feldolgozó process-nél van (4. ábra) 3. Az ASP.Net becsomagolja a kérés kontextusát a HttpContext egy példányába. 4. Az ASP.Net elvezeti a kérést a HttpApplication objektum egy példányához. (vagy egy HttpApplication-ből származtatott objektum példányához) 5. Ha az alkalmazás objektuma érdeklődik aziránt, hogy megkapja a kérés bármely előfeldolgozó eseményét, a HttpApplication meghívja az eseményeket az alkalmazás objektumában. Valamennyi HttpModule ami feliratkozott ezekre az eseményekre, értesítést kapnak. 6. Futásidőben létrehoz egy kezelőt, ami kezeli a kérést. [2] 19

25 3. ábra: IIS 5.x működése az ASP.Net-tel 4. ábra: IIS6.x működése az ASP.Net-tel 20

26 Ezzel szemben, az IIS 7.x-es verziójánál (5. ábra) kicsit máshogy történnek ezen szakaszok. A következő szakaszokon megy keresztül a kérés: 1. A böngésző egy kérést küld egy erőforráshoz a webszerveren. 2. A HTTP.SYS kapja meg a kérést a szerveren. 3. A HTTP.SYS használja a WAS-t, hogy konfigurálási információkat találva azokat továbbjuttassa a WWW szolgáltatásnak. 4. A WAS továbbadja a konfigurálási információkat a WWW Service-nek, amely beállítja a HTTP.SYS-t. 5. A WAS elindít egy feldolgozó process-t az alkalmazás pool-ban a kérés számára. 6. A process feldolgozza a kérést és visszaadja a választ a HTTP.SYS-nek. 7. A HTTP.SYS elküldi a választ a kliensnek. [2] 5. ábra: IIS7.x működése az ASP.Net-tel 21

27 4.7 Kódolási lehetőségek Mindamellett, hogy az ASP támogatja az inline kódot (vagyis beilleszthetünk végrehajtható kódot közvetlenül egy szerver oldali script blokkba), a modern ASP.Net két különböző lehetőséget kínál a kód kezelésére. Az egyik az ASP.Net 1.x code behind, a másik pedig a modern ASP.Net code beside. Az ASP.Net visszafelé kompatibilis a code behind használata esetén. A Visual Studio 2010 a code beside stílust használja. [2] Az ASP.Net 1.x stílusa Az ASP.Net 1.x a code behind stílust támogatja. Fontos lehet, hogy megértsük, ha valaha is futtatunk egy örökölt kódot ebből a korból. A code behind direktívákat használva, az.aspx kiterjesztésű fájlokban azt jelenti, hogy a kód futtatásához szükség van egy külön osztályra, amely a Page direktíva használatával mutatja meg az ASP.Net-nek, hogy melyik osztály hivatkozik az oldalra. A fájl nevét kell megadni, ami tartalmazza az osztály forráskódját. A lenti példában megfigyelhetjük ezt: using System.Web; public class HelloWorld4Code : System.Web.UI.Page { public void ShowLineage() { Response.Write("Check out the family tree: <br/> <br/>"); Response.Write(this.GetType().ToString()); Response.Write(" which derives from: <br/> "); Response.Write(this.GetType().BaseType.ToString()); Response.Write(" which derives from: <br/> "); Response.Write(this.GetType().BaseType.BaseType.ToString()); Response.Write(" which derives from: <br/> "); Response.Write(this.GetType().BaseType.BaseType.BaseType.ToString()); Response.Write(" which derives from: <br/> "); Response.Write(this.GetType().BaseType.BaseType.BaseType.BaseType.ToString()); } } 22

28 Ha egy ASP.Net oldal fel akarja használni ezt a kódot, akkor a következő módon tud rá hivatkozni: <%@ Page Language="C#" Inherits="HelloWorld4Code" Src="HelloWorld4Code.cs" Debug="true" %> <html> <body> <h1>hello World!!!</h1> <% this.showlineage(); %> </body> </html> A code behind ASP.Net 1.x stílusával az ASP.Net megkeresi az Src nevű attribútumot a Page direktívában és lefordítja az abban megadott fájlt. Az ASP.Net beolvassa az Inherits attribútumot, hogy megtudja az osztály típusát az oldal kódjának példányosításához. Az előző példakódban az ASP.Net a Helloword4Code nevű osztályt használja az oldal irányításához. Az Src attribútumot használva, azt mondjuk meg az ASP.Net-nek, hogy fordítsa a megadott nevű fájlt. Az ASP.Net egy ideiglenes mappába fordítja a kódot Akár előre fordítani is lehet a fájlt egy szerelvénnyé (assembly), mely a HelloWorld4Code nevű osztályt tartalmazza. Ahhoz, hogy ez működjön, az előfordított szerelvényt a virtuális könyvtár bin mappájában kell elhelyezni. Ha az előfordítjuk az oldalhoz tartozó osztályt és ezt beletesszük a bin könyvtárba, akkor nem szükséges az Src attribútum megadása. Az Src attribútum hiányában az ASP.Net futási időben fogja megkeresni a szerelvényeket a bin könyvtárban és olyan osztályt fog keresni, ami szerepel az Inherits attribútum értékében. [2] A modern ASP.Net stílusa Egy másik kódolási lehetőség az ASP.Net 2.0-ás verziójától kezdett elterjedni. Ezt a kódolási módszert nevezik code beside stílusnak. Tekintsük a következő ASP.Net oldalt: <%@ Page Language="C#" CodeFile="HelloWorld5Code.cs" Inherits="HelloWorld5Code" %> <html> <body> <h1>hello World!!!</h1> <% // This block will execute in the RenderControl method ShowLineage(); %> </body> </html> 23

29 Erre hivatkozik a HelloWorld5Code.cs fájl: using System.Web; public partial class HelloWorld5Code : System.Web.UI.Page { public void ShowLineage() { Response.Write("Check out the family tree: <br/> <br/>"); Response.Write(this.GetType().ToString()); Response.Write(" which derives from: <br/> "); Response.Write(this.GetType().BaseType.ToString()); Response.Write(" which derives from: <br/> "); Response.Write(this.GetType().BaseType.BaseType.ToString()); Response.Write(" which derives from: <br/> "); Response.Write(this.GetType().BaseType.BaseType.BaseType.ToString()); Response.Write(" which derives from: <br/> "); Response.Write(this.GetType().BaseType.BaseType.BaseType.BaseType.ToString()); } } Ebben az esetben az ASP.Net megkeresi a CodeFile direktívát, hogy segítségével megtudja, hogy milyen kódot kell lefordítania. Az ASP.Net arra számít, hogy egy parciális osztály valósítja meg az oldal logikáját. A parciális osztályok lehetővé teszik, hogy egy típus (osztály, struktúra vagy interfész) definícióját külön darabokra szét lehessen választani több forrásfájlba. A forrásfájlokat lefordítva teljes osztályt kapunk. Ez különösen akkor hasznos, amikor generált kóddal dolgozunk, mint például a Visual Studio által előállított. Ki lehet egészíteni egy osztályt anélkül, hogy megváltoztassuk az eredeti kódot. A Visual Studio.Net 2010 támogatja a code beside/ parciális osztályú kód megvalósítását. [2] 24

30 5. Az alkalmazás tervezése és implementációja Elképzelésem szerint egy olyan képfeltöltő, képmegosztó alkalmazást szeretnék megtervezni, majd implementálni, amely könnyen kezelhető és felhasználóbarát. Webes felületen keresztül a rendszerbe csak regisztrált felhasználók tölthetnek fel képeket. A feltöltött képeiket albumokba rendezhetik és közzétehetik a szintén ezen oldalra regisztrált felhasználók számára. A képek lehetnek publikusak, vagy privát albumokba is szervezhetők. A feltöltés során a képekhez egyedi elnevezést is megadhatnak. A feltöltés után kiválaszthatják, hogy az adott képhez milyen címkéket, azaz úgynevezett tageket rendelnek hozzá, amelyek láthatóak lesznek a képnél és keresésnél is felhasználhatók. A funkciókat összefoglalja és grafikusan megjeleníti a Use case diagram, amely az 1. mellékletben található. 5.1 Az alkalmazás funkcióinak tervezése Regisztráció Az alkalmazás használatához regisztráció szükséges. Ahhoz, hogy a felhasználó regisztráljon, a kezdőoldalon a menüsorból ki kell választania a Regisztráció nevezetű menüpontot. Ilyenkor a webszerver átirányítja a regisztrációs oldalra, amely három beviteli mezőt tartalmaz. Az első mezőbe a felhasználói nevet kell írni. A második mező tartalma maga a jelszó. A jelszó a felhasználói felületen egyértelműen rejtett. Az utolsó beviteli mező a jelszó ismételt beírása. Az implementáció során figyelnünk kell arra, hogy a felhasználó minden mezőt kitöltött, és hogy a jelszó ismételt beírása megegyezik az eredetivel. Ha a felhasználó kitöltötte a mezőket, akkor a Regisztráció feliratú gombra való kattintással befejezheti a regisztrációt. Hibaüzenetet kap, ha már létezik a megadott nevű felhasználó. Az implementációnál fontos, hogy a jelszót kódolva tároljuk le az adatbázisba Bejelentkezés Csak azon felhasználók léphetnek be a rendszerbe, akik már egyszer regisztrálták magukat. Ha ez nem történt meg, akkor nem kapnak jogot a rendszer használatához. Viszont sikeres regisztráció után a Bejelentkezés menüpontra kattintva lehetőséget kapnak belépni a rendszerbe. A kattintás után a webszerver átirányítja a felhasználót a bejelentkezési oldalra. Az oldalon két beviteli mező van, egy checkbox és egy Bejelentkezés feliratú gomb. Az első beviteli mezőbe a felhasználói nevet, a második beviteli mezőbe a jelszót kell írni. A 25

31 checkbox az úgynevezett maradjon bejelentkezve funkciót valósítja meg, amely valójában hosszabb élettartamú cookie-t hoz létre. A beviteli mezőket kitöltve és a gombra kattinva a bejelentkezés sikeres, hogyha az adatbázisban létezik a felhasználó a megadott jelszóval Új galéria létrehozása Miután a frissen regisztrált felhasználó belép a rendszerbe, kihasználva az alkalmazás funkcióit, lehetősége van saját galériát létrehozni. Az Új galéria létrehozása feliratú gombra való kattintás esemény eredményéül megjelenik egy beviteli mező és egy Létrehozás feliratú gomb. A felhasználó a beviteli mező kitöltésével nevet ad a galériának, majd a gombra való kattintással létre is hozza azt. A galéria nevének a megadása kötelező Galériák törlése A felhasználó az eddig létrehozott galériáit törölheti. A kezdőoldalon minden egyes galéria alatt található egy piros színű X formájú ikon. Ha kiválasztotta, melyik galériát szeretné kitörölni, akkor rá kell kattintania az ikonra. A kattintás hatására megjelenik egy párbeszéd ablak, melyben megerősítést kér a rendszer, hogy valóban eltávolítsa-e a galériát. Két lehetőséget kínál fel a párbeszédablak. Az első az egy Ok feliratú gomb, a másik pedig a Mégse. Ha a felhasználó az Ok gombra kattint, akkor törlődik a kiválasztott galéria véglegesen. A galériával törlődik minden benne szereplő kép, a képekhez írt kommentek, tagek, és a megosztás is. Ha a Mégse gombra kattint, bezáródik a párbeszéd ablak, nem törlődik a galéria és visszatérünk a kiindulási ponthoz Képek feltöltése Amennyiben a felhasználó létrehozott egy új galériát, az adott galériát megtöltheti képekkel. Csak és kizárólag képeket lehet feltölteni a tárhelyre a következő formátumokkal: jpg, png, gif, bmp. Annak érdekében, hogy a feltöltött fájlok csak ilyen kiterjesztésűek legyenek, a feltöltés előtt a rendszer ellenőrzi a fájl formátumát. A felhasználónak egy kép feltöltéséhez annyit kell tennie, hogy rákattint a kiválasztott galériára, ami átirányítja a galéria képeit megjelenítő oldalra. A felületen található egy Új kép feltöltése feliratú gomb, melyre kattintva megjelennek a képfeltöltéshez szükséges további opciók. A felhasználó a felületen lát egy Fájl kiválasztása nevű gombot, melyre ha rákattint, akkor egy felugró ablakban kiválaszthatja a feltöltendő képet a saját gépéről. Ha ezt megtette, akkor a gomb alatti szövegbeviteli mezőbe be kell írnia a kép nevét, majd végezetül, a Feltöltés feliratú 26

32 gombra kattintva a kép feltöltésre kerül az adott galériába. A kép nevének megadása kötelező Képek törlése A felhasználónak lehetősége van a képek törlésére az aktuálisan kiválasztott galériából. Például, ha kétszer töltötte fel ugyanazt a képet, vagy úgy gondolja, hogy még sincs keresni valója az adott galériában. Ahhoz, hogy törölni tudjon egy képet, rá kell kattintania arra a galériára a kezdőoldalon, ahol ez a kép szerepel. Ha ez megtörtént, a webszerver átirányítja a galéria oldalára, ahol a galéria képei láthatók. Minden kép alatt található egy piros X jelet ábrázoló ikon. Az adott kép törléséhez erre kell rákattintani. Amikor a felhasználó rákattint az ikonra, megjelenik egy párbeszéd ablak, mely a törlés megerősítését kéri. Két lehetőséget kínál fel ez az ablak. Az egyik az a Törlés feliratú gomb, amely ténylegesen kitörli a képet a tagekkel és a hozzászólásokkal együtt, illetve a másik lehetőség a Mégse feliratú gomb, ami visszairányít a kiinduló helyzetre, és változatlanul hagyja a képet Hozzászólások készítése A felhasználó a saját képeihez, illetve a vele megosztott képekhez kedve szerint közzéteheti a véleményét. Az adott kép kiválasztása után az oldalon megjelenik a kiválasztott kép neve, a kép adatai, alatta a kiválasztott kép egy kicsinyített mása, majd a kép alatt egy gomb Szólj hozzá felirattal. Erre a gombra, ha rákattint a felhasználó, elérhetővé válik egy HTML szövegszerkesztő modul, melyet kedve szerint felhasználhat, hogy látványossá és észrevehetőbbé tegye a hozzászólását. A hozzászólása megírása és szerkesztése után a Küldés feliratú gombra kattintva közzéteheti a hozzászólását. Ha meggondolta magát, és nem szeretne post-olni semmi hozzászólást, akkor a Mégse gombra való kattintással visszatérhet az adott képhez Hozzászólások törlése A felhasználónak lehetőségében áll hozzászólásokat törölni, egy megkötéssel, ha az a hozzászólás, amit törölni akar, azt ő készítette. Az oldalon az aktuálisan kiválasztott kép alatt szerepelnek egymás alatt a hozzászólások. Amelyiket ő írta, a hozzászólás mellett található egy piros X jelet ábrázoló ikon, melyre ha rákattint, felugrik egy párbeszéd ablak. A párbeszéd ablak megerősítést kér a komment törlésével kapcsolatban. Két lehetőséget kínál fel, két gomb személyében. Az egyik gomb felirata a Törlés. Ha erre rákattint a felhasználó, azzal megerősítette a törlési szándékát. Viszont ha a Mégse feliratú gombra kattint, azzal 27

33 meggondolta magát, nem törlődik a hozzászólás és bezáródik a felbukkanó ablak is, visszatérve ezzel a kiindulási állapotba Címkék készítése A címkék, azaz a tagek, valójában olyan kulcsszavak, melyek a hozzájuk kapcsolódó képre leginkább jellemzőek. Nem egy leírásról van szó, hanem csupán csak egy-egy szóról. Manapság sok helyen használnak címkézést. Segítségükkel hatékonyabban és gyorsabban kereshetünk a képekre. Ezek a kulcsszavak egyfajta önmagát építő kategóriarendszerként viselkednek. A tagek az adott képet megjelenítő oldalon jelennek meg, az aktuális kép felett. Ha a felhasználó a Tag hozzáadása feliratú gombra kattint, akkor megjelenik egy beviteli mező és két gomb. A beviteli mezőbe beírhat újabb taget, és a Hozzáadás feliratú gombra való kattintással a tag hozzákerül a képhez, és megjelenik felette. Ha a felhasználó meggondolta magát és nem akar újabb taget hozzáfűzni a képhez, akkor a Mégse gombra való kattintással visszatérhet az aktuális képhez és ekkor eltűnik a szerkesztő felület is Címkék törlése A képet megjelenítő oldalon az aktuálisan kiválasztott kép fölött szerepelnek a tagek. Ha úgy gondolja, az a tag nem igazán illik az adott képhez, kitörölheti azt. A tagek abc sorrendbe vannak rendezve. Minden egyes tag mellett szerepel egy piros X jelet ábrázoló ikon. A felhasználó úgy törölheti az adott taget, hogy rákattint a mellette lévő ikonra. Amint rákattintott, megjelenik egy felbukkanó párbeszédablak, ami megerősítést kér a törléssel kapcsolatban. Itt is két választási lehetősége van a felhasználónak. A megerősítő kérdés alatt helyezkedik el két gomb. Az egyik Törlés felirattal, mely véglegesíti a tag törlését, a másik pedig Mégse felirattal. Az utóbbi nem törli a taget, és visszatér a kiindulási állapotba, bezárja a párbeszéd ablakot Galériák megosztása A felhasználó a feltöltött galériáit megoszthatja más kiválasztott felhasználókkal, vagy minden felhasználóval. A megosztást úgy lehet aktivizálni, hogy a felhasználó a galériái közül kiválaszt egyet, amit meg szeretne osztani és a felfele fordított tenyér ikonra kattint. Ilyenkor egy felugró ablakban láthatja a megosztási lehetőségeket. Az első lehetőség a Ne legyen megosztva, a második a Publikus, a harmadik pedig a Megosztás a következő felhasználókkal. A három lehetőség közül egyszerre csak egyet lehet kiválasztani. Az utolsó funkció kiválasztása esetén megjelenik a felhasználók listája. Ezek azok a felhasználók, akik 28

34 a rendszer felhasználói. Mindegyik felhasználó neve előtt található egy checkbox, melyeket aktiválva beállítható, hogy az album mely felhasználókkal legyen megosztva. Ha elvégezte a beállításokat, az Ok feliratú gombra való kattintással mentheti a változásokat a galériához, viszont ha meggondolta volna magát, akkor a Mégse feliratú gombra való kattintással visszatérhet a galériákhoz, mindenféle beállítás hiánya nélkül. Ha egy galéria már meg van osztva bizonyos felhasználókkal, akkor azon felhasználók neve előtti checkbox már be lesz pipálva a felugró ablakban Megosztott galériák megtekintése A felhasználóknak lehetőségük van a velük megosztott galériákat a saját profiljukon megtekinteni. A megosztott galériákat egy külön menüpontból érhetik el, melynek Megosztott galériák a neve. Ha kiválasztják ezt a menüpontot, akkor megtekinthetik a velük megosztott és a publikus galériákat is. A galériák ugyanúgy néznek ki, mintha a saját galériájukat látnák, viszont nem érnek el bizonyos funkciókat, amelyeket a saját galériájuknál használhatnak. Például nem hozhatnak létre galériákat, nem törölhetik ezen galériákat, és nem adhatnak ki megosztást mások számára. Ha a felhasználó meg akar tekinteni egy képet a megosztott galériából, akkor ugyanúgy megteheti, mint a saját galériájában, viszont nem törölheti az adott képeket. Hozzászólást viszont bármelyik képhez írhat, ám nem törölheti mindegyik hozzászólást, csak kizárólag azt, amit ő írt. Tageket nem vihet fel képekhez, és nem is törölheti a más felhasználó által felvitt tageket Keresés a képek között A felhasználónak lehetősége van a saját és a vele megosztott galériákban található képek között keresni. A Kép keresése menüpontra kattintva, a webszerver átirányítja a felhasználót a keresés oldalra. A felhasználó négy feltétel alapján tud keresni. Lehetséges a kép nevét tartalmazó szórészlet alapján, a kép tagjei között szórészlet alapján keresni, valamint a kezdő és végdátum megadásával behatárolni a kép keletkezésének időpontját. Ha több mezőt is kitölt, akkor a beírt tulajdonságok mindegyike illeni fog a keresett képre. A gombra való kattintással pedig elindítja a keresést. Az eredmény azonnal megjelenik az oldalon, a képpel és a kép nevével együtt (ha van találat). Ha a képekre rákattint a felhasználó, megtekintheti azokat nagyobb méretben. Ha a saját képe, akkor írhat hozzá tageket, és hozzászólásokat, viszont ha nem, akkor csak hozzászólást írhat, illetve törölheti a saját hozzászólásait. 29

35 Admin felület A rendszerben egy vagy több felhasználó admin lehet, mely nem csak a felhasználónak nyújtott szolgáltatásokat tudja kihasználni, hanem ezeken felül grafikonokat láthat. Számukra megtalálható a menüsorban egy újabb menüpont, melynek Statisztika a neve. Ezt az oldalt csakis az admin joggal rendelkező felhasználó éri el. Más esetben, a kezdő oldalra irányít a webszerver. A menüpontra kattintva az admin két diagramot lát. Az egyik diagram a rendszerben található képekből egy kördiagramban meghatározza a képek felbontása szerinti százalékos eloszlást. A másik diagram pedig a felhasználók képeinek a számát szemlélteti egy oszlopdiagramon. 5.2 Az adatbázis tervezése ER modell A tervezés során a rendszert négy egyed alkotja. A users nevű egyed magában foglalja mindazon felhasználókat, akik használni akarják a rendszert. Ennek az egyednek négy tulajdonságát tartottam fontosnak. Az első tulajdonság az id, amely egy-egy felhasználót azonosít és egyben elsődleges kulcs. A következő tulajdonsága a username, amely a falhasználó a regisztrációs folyamat végrehajtása utáni felhasználói nevét tárolja. A users isadmin nevű tulajdonságát azért tartottam fontosnak, hogy ezt felhasználva el tudjuk majd dönteni, hogy az adott felhasználó rendelkezik-e admin jogokkal, vagy sem. Végezetül a felhasználó utolsó tulajdonsága a password. Ezen tulajdonság az adatbázisba titkosítva kerül tárolásra. A második egyed a rendszerben a galleries. A galleries valójában egy gyűjtő hely, mely magában foglalja a képeket. Az galleries-nek három tulajdonságát különböztetem meg. Az első tulajdonsága az id, ami maga az elsődleges kulcs is. Ez a tulajdonság azonosít egy-egy albumot. A második tulajdonsága a name. Nevet akkor kap az album, amikor a felhasználó létrehozza azt, vagy ha módosításra kerül. Az ispublic tulajdonsága segítségével pedig el tudjuk dönteni, hogy az adott album minden regisztrált felhasználó számára elérhető legyen, vagy csak a tulajdonosa számára legyen látható. A users és a galleries egyedet összeköti egy egy-több kapcsolat, mely azt jelenti, hogy egy felhasználó több albummal is rendelkezhet. Továbbá egy több-több share nevű kapcsolat is összeköti, ami szerint egy felhasználónak megoszthatnak több albumot más felhasználók és egy albumot több felhasználóval is megoszthatnak tulajdonosaik. 30

36 Az következő egyed az images nevet birtokolja. Az images a felhasználó által feltöltött albumokba rendezett képek összessége. Az images egyednek nyolc tulajdonságát különböztetem meg, melyek a következők. Az id nevű tulajdonság itt is elsődleges kulcsot jelöl, és segítségével meg tudjuk különböztetni a képeket. A következő tulajdonság a name. A kép nevét is, ahogyan az album nevét is, a felhasználó hozhatja létre, és a későbbiekben szerkesztheti. A size tulajdonság az adott kép méretét fogja tárolni, a width tulajdonság a szélességét, a height tulajdonság a kép magasságát, az url nevű tulajdonság fogja tartalmazni az adott kép elérési útvonalát a szerveren, a creation_date pedig a kép készítésének idejét. Utolsó tulajdonságként a tag nevű tulajdonság szerepel, mely többértékű tulajdonság. A tag segítségével kereshetünk rá egyszerűen a képekre. Azért többértékű tulajdonságnak, mert egy kép több tag nevet is birtokolhat. Az galleries és az images egyedeket is szintén egy egy-több kapcsolat köti össze, miszerint egyetlen albumba több kép is szerepelhet, viszont ez a tulajdonság azt is magában foglalja, hogy egy kép csakis egyetlen egy albumban fordulhat elő. Az utolsó egyed a comments. A comments-nek három tulajdonsága van. Az első, a már jól ismert id, mely az adott kommentet azonosítja. A text tulajdonság tartalmazza a kommentek szöveges tartalmát. Legutolsó sorban a time, amely pedig a komment létrehozásának az idejét tárolja. A users és a comments egyedet egy egy-több kapcsolat köti össze, amely azt jelenti, hogy egy felhasználó írhat több kommentet is, viszont egy kommentet csak egy felhasználó hozhat létre. Az images és a comments között is található szintén egy egy-több kapcsolat, miszerint egy képhez tartozhat több komment is, viszont egy komment csak egy bizonyos képhez tartozhat. (6. ábra) 6. ábra: ER- modell 31

37 5.2.2 Relációs modell Az elkészült ER modellünket átkonvertáljuk relációs modellé. Miden egyes egyedből egy tábla jön létre. Illetve volt egy olyan tulajdonsága az images nevű egyednek, amely többértékű volt- ebből is egy táblát hozunk létre. Továbbá létezett egy olyan kapcsolat a users és a galleries között, mely nevesített volt, így ebből is egy külön tábla fog létrejönni. A tulajdonságokból mezők lesznek. Minden egyes mezőnek meg kell adni azt, hogy milyen típusú az adott mező. Minden elsődleges kulcsból ugyanúgy elsődleges kulcs marad itt is. A kapcsolatokat úgy ábrázoljuk a táblák között, hogy mindig az ER modellben lévő több oldalon lévő egyedből kapott táblában létrejön egy úgynevezett idegen kulcs típusú mező, mely az egy oldalon lévő egyedből alkotott tábla elsődleges kulcsára mutat. A users tábla mezői a következőek: amint már írtam, az elsődleges kulcs, az id, aztán egy username, egy password, és egy isadmin nevű mezők. Az id típusa number(n) azaz szám. A username és a password mező típusa char(c) azaz karakter. Az isadmin típusa pedig boolean(b) azaz két értéket vehet fel, melyek a true és a false. A galleries tábla mezői rendre a következők: id, name, ispublic, user_id. Az id és a user_id number(n) típusuak, a name char(c) típusú, az ispublic pedig boolean(b) típusú mező. A galleries tábla user_id mezőjéből kiinduló nyíl mutat a users tábla id elsődleges kulcs mezőjére lehetővé téve ezzel a két tábla kapcsolatát. A share nevű kapcsolatból létrejött egy külön tábla, a shares, melynek tartalma két idegen kulcs, melyek összekötik a users és a galleries táblával és olyan típusúak, mint az adott táblák elsődleges kulcsai, azaz ebben az esetben number(n). Az images tábla mezői az id (N), name (C), url (C), height (N), width (N), size (N), creation_date Date(D), gallery_id (N). A id elsődleges kulcs szerepet tölt be, a gallery_id pedig idegenkulcs szerepet. Ezen tábla idegen kulcsa a galleries tábla elsődleges kulcsára mutat, összekötve ezzel a két táblát. A tag többértékű tulajdonságból is létrejön egy külön tábla, mely a tags nevet kapta. Rendelkezik id, tag (C) mezőkkel. Jobban belegondolva a tags és az images tábla kapcsolatába, valójában a megvalósításban ez egy több- több kapcsolat. Azért is jobb a többtöbb kapcsolat, mert ezáltal elkerüljük azt a pazarlást, hogy a tags táblába az adatbázisunk feltöltése során ne kerüljenek ismételten ugyanazon értékű tagek. Ezért használnunk kell egy kapcsolótáblát, melynek a neve images_tags. Szerepe, hogy összekösse az images és a tags táblát. Ezen tábla tartalma csupán két idegen kulcs a két táblára, melyek típusa megegyezik 32

38 az egyes táblák elsődleges kulcsának a típusával, azaz number(n). A comments egyedből létrejövő tábla mezői: id (N), text (C), time (D), image_id (N), author_id (N). Az id a tábla elsődleges kulcsa. Két idegen kulcsot is tartalmaz. Az image_id az images tábla id mezőjére mutat, az author_ id pedig a users táblával köti össze a comments táblát. (7. ábra) 7. ábra: Relációs modell Az adatbázis megvalósítása Az elérhető adatbáziskezelő rendszerek közül a megvalósításhoz az SQL Server Express változatát választottam, amely ingyenesen használható bizonyos korlátozások mellett. Az ER- és a relációs modell megtervezése után az adatbázisomat a Microsoft SQL Server Management Studio segítségével hozom létre. Létrehoztam egy új adatbázist a táblák tárolására, amelynek a Gallery nevet adtam. Készítettem egy új adatbázis felhasználót, amely használatával fog az alkalmazás hozzáférni az adatbázishoz. A felhasználónak megadtam a szükséges adatbázis jogokat a Gallery adatbázishoz a lekérdezéshez és a felvitelhez. A Gallery adatbáz tábláinak létrehozásához a parancsok a 2. mellékletben találhatóak. 33

39 5.3 Az alkalmazás implementációja Az alkalmazást a Microsoft Visual Studio fejlesztőkörnyezet segítségével készítettem el. Létrehoztam egy KepGaleria nevű Solutiont, mely magába foglalja a megvalósított projekteket. Azért hoztam létre több projektet is, hogy ezáltal szétválasszam az adatbázis műveleteket, az üzleti logikát és a megjelenítés réteget. A Dao nevű projekt tartalmaz minden adatbázissal kapcsolatos műveleteket. Magába foglal egy olyan XML típusú App.config nevű konfigurációs fájlt, aminek <connectionstrings> tag gyerekeként létrehozott add tag connectionstring nevű tulajdonságának beállítjuk az értékét, amely a korábban létrehozott adatbázis helyét, gallery_master értékű azonosítóját és jelszavát tartalmazza. Az adatbázishoz való csatlakozást a DbConnector static osztályban valósítom meg. Az osztály konstruktorában valósul meg az adatbázishoz való csatlakozás felhasználva a connectionstring értékét. Egyetlen egy metódusa van, mely az adatbázissal való kapcsolat megszűntetését biztosítja. A Dao további projektjei azon C# nyelven írt osztályok, amelyek az adatbázisban lévő táblákat reprezentálják. A Logic projekt tartalmazza az olyan C# osztályok összességét, amelyek a háttérműveleteket hajtják végre. Ilyen osztály például a GalleryLogic.cs, PasswordHash.cs és a UserLogic.cs. A KepGaleriaWeb projekt tartalmazza a megjelenéssel kapcsolatos osztályokat és stíluslapokat. Pontosabban itt található a MasterPage, azaz a mester oldal, ami vázát adja a Register.aspx. Login.aspx, Default.aspx, Gallery.aspx, Search.aspx, Admin.aspx és az Image.aspx oldalaknak. Tartalma még szintén egy Web.config XML típusú konfigurációs fájl, melyben beállítottam, hogy a mindig megjelenő oldal, a Default.aspx legyen. A regisztráció és a bejelentkezés oldalán kívül az összes többi oldal védett, a nem bejelentkezett felhasználók számára nem érhető el. Az alkalmazás szerkezetét és az osztályok kapcsolatát a 3. mellékletben található osztálydiagram mutatja be Regisztráció folyamata A Default.aspx oldal menüsorában szereplő Regisztráció menüpontra kattintva a webszerver átirányít minket a Register.aspx oldalra (8. ábra). A mester oldal stílusát örökölve láthatunk három beviteli mezőt és egy gombot. A regisztrációhoz ezen mezők 34

40 kitöltése szükséges. Amint ezek a mezők kitöltésre kerülnek, egy RequiredFieldValidator ellenőrzi, hogy ténylegesen is ki vannak-e töltve a mezők, ha nem, akkor a beviteli mezők mellett megjelenik egy * karakter figyelmeztetve a felhasználót, hogy töltse ki a hiányos részeket. Amíg nincs kitöltve valamely mező, addig nem lehet létrehozni felhasználót. A mezők kitöltésével egy CompareValidator pedig azt ellenőrzi, hogy a jelszó és az ismételt jelszó beviteli mezőiben ugyanaz az érték szerepel-e. Ha nem, akkor ugyanezen az ASP oldalon egy A jelszavak nem egyeznek! figyelmeztető szöveget kapunk, mely felhívja a figyelmünket a jelszó ismételt helyes begépelésére. Amíg nem egyeznek meg a mezők, természetesen nem lehet létrehozni felhasználót. Záró lépésben, ha minden mező megfelel a kritériumoknak, akkor a Regisztráció nevű gombra kattintással egy esemény keletkezik, melynek hatására meghívódik a gomb eseménykezelője, amelyben a UserLogic osztály RegisterUser nevű boolean visszatérési értékű metódusát használjuk, mely ellenőrzi, hogy létezik-e már ugyanolyan nevű felhasználó az adatbázisban. Ha igen, akkor kapunk egy A regisztráció nem sikerült, már létezik ilyen nevű felhasználó. figyelmeztetést ugyanazon oldalon. Viszont ha nincs ilyen nevű felhasználó, akkor egy A regisztráció sikeres. üzenetet kapunk és ezzel egyidejűleg a felhasználó bekerül az adatbázisba egy egyedi azonosítóval, a nevével és a kódolt jelszavával együtt. A jelszó kódolását a PasswordHash osztály végzi, amely a jelszót hasheli és saltot (random karaktereket) tesz a jelszó végéhez. 8. ábra: Regisztráció A bejelentkezés folyamata Sikeres regisztráció után a Bejelentkezés nevű menüpontra kattintva a webszerver átirányít minket a Login.aspx oldalra, mely szintén a mester oldal tulajdonságait örökli. Az 35

41 oldalon találhatunk két beviteli mezőt, egy checkbox-ot és egy gombot (9. ábra). Az egyik beviteli mező értéke a felhasználói név, a másik pedig a jelszó. Egy validátor itt is ellenőrzi, hogy ki vannak-e töltve a mezők. Ha valamelyik nincs kitöltve, egy * tartalommal rendelkező hibaüzenet jelenik meg a beviteli mezők mellett, jelezve a felhasználónak, hogy üres a mező tartalma. Ha mind a két mező ki van töltve és rákattintunk a Bejelentkezés nevű gombra, meghívódik a BtnLogin_Click metódus. A metódusban használunk a UserLogic osztály Login nevű boolean visszatérési értékű metódusát, melyben megvizsgáljuk, hogy az adott nevű felhasználó titkosított jelszava megegyezik-e az adatbázisban tárolt titkosított jelszóval. Ha ez nem egyezik meg, vagy egyáltalán nem is létezik ilyen nevű felhasználó, kapunk egy A felhasználónév/jelszó nem megfelelő! hibaüzenetet. Viszont ha megegyezik, akkor a webszerver átirányít minket a Default.aspx oldalra és hozzáférhetünk az alkalmazás által nyújtott funkciókhoz. Mielőtt létrejönne a click esemény, és a Maradjon bejelentkezve: címkéjű checkbox tartalmát true értékűre állítjuk, azaz bepipáljuk, eredményül azt érjük el, hogy a böngésző hosszabb élettartamú cookie-t hozzon létre. 9. ábra: Bejelentkezés Új galéria létrehozása A galéria létrehozásához a Default.aspx oldalhoz hozzáadtam egy Új galéria létrehozása feliratú gombot és egy panel elemet. A panelhez hozzáadtam egy textboxot és egy Létrehozás nevű gombot. A Default.aspx.cs C# kódjában a Page_Load nevű metódusban beállítom, hogy kezdetben a panel ne látszódjon, viszont az Új galéria létrehozása feliratú gomb az igen. Ha a felhasználó rákattint az Új galéria létrehozása feliratú gombra, akkor viszont megcserélem az értékeket, így a panel fog látszani, és a gomb 36

42 eltűnni. A textboxra létrehozok egy RequiredFieldValidator típusú validátort, ami azt ellenőrzi, hogy üres-e a textbox tartalma. Ha üres, akkor a textbox elem után megjelenik egy * karakter, ami figyelmezteti a felhasználót, hogy üres a mező. Ha üres, akkor nem lehet galériát létrehozni. Viszont, ha a textboxnak van értéke (10. ábra), akkor a Létrehozás nevű gombra kattintva meghívódik a Default.aspx BtnCreateGellery_Click nevű metódusa, melyben meghívjuk a GalleryLogic osztály CreateGalleries nevű metódusát. Ebben a metódusban a GalleryDao CreateGallery nevű metódusát hívjuk meg azért, mert a galéria létrehozása az adatbázis művelet. A tényleges funkciója ennek a metódusnak, hogy beszúrjon egy rekordot a galleries nevű táblába. Ehhez nincs szükségünk semmi másra, csak a felhasználó azonosítójára és a galéria nevére. A felhasználó azonosítóját a session-ből tudjuk kiszedni a galéria nevét, pedig a kitöltött textboxból. 10. ábra: Galéria létrehozása Galériák megjelenítése A felhasználói felületen a galériák megjelenítését (11. ábra) a Default.aspx C# kódjában egy DisplayGalleries nevű metódus valósítja meg. A felhasználó galériáit egy táblázatban jelenítettem meg. Ezt a táblázatot valósítja meg ez az eljárás. A táblázat megrajzoltatását úgy valósítottam meg, hogy létrehoztam egy int típusú konstans adattagot, melynek értékéül a hármas számot adtam. Ez a konstans a táblázat oszlopainak a számát mondja meg. A táblázat sorait egy Ceiling nevű metódus segítségével határozom meg. A metódus értéke egy olyan double típusú szám, ami a paraméterében kapott szintén double típusú szám felfelé kerekített, azaz a következő egész szám értéke. A táblázat felépítését pedig for ciklusok segítségével valósítottam meg. A táblázatot belülről kifele haladva építettem fel, azaz cella, sor, táblázat sorrendben. 37

43 11. ábra: Galériák megjelenítése Képek feltöltése a galériákba A felhasználó, amikor bejelentkezik az oldalon, a saját galériáit láthatja, persze ha már van neki. Ha nincs, akkor amint létrehoz egy galériát, azt egyből látni fogja. A galériákat úgy tudja feltölteni képekkel, hogy kiválasztja egy egér kattintással, melyik galériába szeretné a feltölteni azokat. Ha ez megtörtént, akkor a felhasználót a webszerver átirányítja a Gallery.aspx oldalra. Az oldal felépítéséhez készítettem design kódban egy labelt, melyet középre igazítottam. Ennek a labelnek az értéke az aktuális galéria neve lesz. Létrehoztam egy gombot Új kép feltöltése felirattal, alatta pedig egy panelt. A panel tartalma egy táblázat, mely két oszlopból és három sorból áll. Az első és az utolsó sor celláit összevontam. Az első sor tartalma egy FileUpload típusú ASP elem, a második sor tartalma egy label és egy textbox, az utolsó sor tartalma pedig egy Feltöltés nevű gomb. Az oldal betöltődésekor a panel láthatóságát false-ra, az Új kép feltöltése feliratú gomb láthatóságát pedig true-ra állítom. A gomb megnyomását követően keletkezik egy esemény, melynek eredményeként a panel láthatóságát true-ra és az előbb használatba vett gomb láthatóságát pedig false-ra állítom, illetve a kép nevét tartalmazó textbox értékét itt törlöm ki. A Fájl kiválasztása feliratú gombra való kattintással megjelenik egy fájl kiválasztó ablak. Erre az elemre két validátort írtam. Az egyik validátor típusa a RequiredFieldValidator, ami ellenőrzi, hogy van e kiválasztva valamilyen fájl. Ha van, akkor a felhasználói felületen a gomb mellett megjelenik a kiválasztott fájl neve a kiterjesztésével együtt. Viszont ha nincs, akkor egy Nincs fájl kiválasztva kiírással figyelmezteti a felhasználót. A másik validátor típusa pedig a RegularExpressionValidator, amelynek ValidationExpression nevű argumentumában megadott kiterjesztéseteket, akár mint egy fehér listát felhasználva megvizsgálja, hogy a kiválasztott fájl formátuma megegyezik-e a listában szereplő 38

44 kiterjesztések valamelyikével. Ha nem, akkor egy hibaüzenet jelenik meg, melynek a tartalma: A kiválasztott fájl nem kép! Ha megegyezik, tovább léphetünk a kép nevének beírásához. Ezt egy textbox teszi lehetővé. Erre a textboxra is készítettem egy validátort, mely azt ellenőrzi, hogy ki van-e töltve a beviteli mező. Ha nincs kitöltve, a textbox mellett egy * karakter jelenik meg. Ha megfelelően kitöltöttük a beviteli mezők értékét (12. ábra), akkor a Feltöltés feliratú gombra való kattintással meghívódik egy esemény, amelynek lekezelésekor a GalleryLogic osztály SaveImage metódusát hívjuk meg. A metódus logikája, hogy a kép adatait az adatbázisban tárolja, magát a képet pedig a szerveren. Az adatbázisban a kép elérési útvonala lesz, mely megmondja, hogy az adott kép hol található a szerveren. Ha jpg formátumú képről van szó, akkor pedig pontosan meg tudjuk mondani a kép tulajdonságait, többek között a kép készítésének a dátumát az exif adatok alapján, amennyiben fényképről van szó. Ha nem jpg-ről van szó, akkor sajnos nem tudjuk ezt a dátumot, helyette a feltöltési dátumot fogja beállítani. 12. ábra: Képfeltöltés Galériákban található képek előnézete A SaveImage metódus olyan funkciót valósít meg, hogy a feltöltendő képet nem csak az eredeti méretében őrzi meg, hanem három méretarányos képet is lement az eredeti képről. Ez azért szükséges, mert amikor a felhasználó megtekinti az albumait, akkor ne az eredeti kép kerüljön a galéria előnézetéhez átméretezve, hanem egy kisebb méretű kép, hiszen így rövidebb idő alatt betölt az oldal. A kis képek létrehozását a CreateThumbnail metódus valósítja meg, melynek paramétere az eredeti kép és két int típusú felsőhatárt jelentő viszonyítási szám. Ezt a kis képet png formátumban mentem el és a neve az eredeti kép idja és egy _thumb_small.png toldalék lesz. Ugyanígy a közepes méretű képet is létrehozom és elmentem. Ennek a neve pedig az eredeti kép id-ja és a _thumb.png toldalék lesz. Végezetül egy nagyobb méretű képet is ugyanígy létrehozok és elmentek. Ez a kép pedig a _thumb_big.png utótagot fogja kapni. 39

45 A korábban létrehozott galériák megjelenítéshez készült táblázat minden egyes cellájában létrehoztam for ciklusok segítségével egy két oszlopos, három soros táblázatot. Az első két sorba kirajzoltattam az aktuális galériában szereplő első négy kép _thumb_small.png toldalékkal ellátott nevű kisképeit. Az utolsó sorba pedig egy cella összevonás után, a galéria neve került. A képek pontos elhelyezkedését az oldalon css segítségével igazítottam. (13. ábra) 13. ábra: Galériában található képek előnézete Galériákban található képek megjelenítése A galériákban található képek megjelenítéséért a Gallery.aspx C# kódjában található DisplayImages metódus felelős. Ebben a metódusban is táblázatot használok a képek dinamikus elhelyezése érdekében. Egy előre beállított int típusú konstans értékkel pontosan meghatározom, hogy a táblázat hány oszlopból álljon. A sorok számát viszont ezzel a technikával nem tudom beállítani, hiszen nem tudom pontosan, hogy az adott albumba hány kép van feltöltve, ami meghatározza a sorok számát. Ahhoz hogy a sorok számát megtudjam, szükségem van ismét egy Ceiling metódusra, ahogy ezt már a galériák megjelenítésénél is használtam. Az oldalon való pontosabb elhelyezkedését pedig css kódból állítottam be. Az elmentett képek közül pedig azokat a képeket szúrom a táblázat celláiba, amelyek nevének a végződése _thumb.png. Ezek a képek nagyobbak az előnézeti képektől, de még mindig nem a kép eredeti méretével egyeznek meg. A könnyű átlátást támogatva mielőtt létrehoznám a táblázatot, kiírattatom az aktuálisan kiválasztott galéria nevét egy asp label elembe, melyet szintén css segítségével formázok. Lehetővé tettem azt is, hogy a felhasználó ki tudjon választani a galériában szereplő képek közül egyet-egyet, hogy az megjelenjen egy nagyobb felbontásban és a későbbiekben lehetővé tegyen további funkciókat. Ezt úgy éri el, hogy a kiválasztott képre kattint. Ilyenkor egy onclick esemény jön létre, melynek eredményeként a szerver átirányít minket a Gallery.aspx-ről az Image.aspx oldalra. Az Image.aspx oldalt egy label és több panel építi fel. A label értéke a kiválasztott kép neve. Az 40

46 első panel neve a PanelImage, melyen az aktuális kép jelenik meg, majd a PanelComments, ahol a képhez tartozó kommentek fognak megjelenni, és végül a PanelPost, amelyen pedig a kommentezéshez szükséges funkciók fognak megjelenni. A kiválasztott kép az elmentett képek közül a _thumb_big.png toldalékkal rendelkező másolt képek. (14. ábra) A kép felett megjelennek továbbá a képhez hozzáadott tagek, és a kép adatai. Elérhetővé tettem továbbá a képek teljes méretben való megtekintését is azzal, hogy ha rákattintunk ezen oldalon szereplő képre, akkor meghívódik egy JavaScript függvény, amely ténylegesen is megjeleníti az eredeti feltöltött képet, valódi értékeivel egy új oldalon. 14. ábra: Galériában található képek megjelenítése Komment írása egy adott képhez Az Image.aspx felhasználói felületén található egy Szólj hozzá feliratú gomb. Erre a gombra való kattintással aktivizálódik egy olyan JavaScript függvény, mely láthatóvá teszi a gomb alatt található eddig láthatatlan PanelPost id-jű panelt és annak a tartalmát, valamint láthatatlanná teszi a Szólj hozzá gombot. A panelen található a CKEditor és két további gomb. A CKEditor egy nyílt forráskódú, ingyen letölthető, teljesen testre szabható, szövegszerkesztő komponens, melynek segítségével a begépelt szövegünket kedvünk szerint formázhatjuk. (15. ábra) Ezeket a formázásokat a szerkesztő Html forrásként használja fel az oldalon belül, és így is menti le az adatbázisban. Ha mégse akarunk kommentet írni, akkor lehetőségünk van a Mégse feliratú gombra kattintani, amely hatására ismét meghívódik egy JavaScript függvény, ami elrejti a panelt. Ha elkészült a hozzászólás, akkor Küldés feliratú gombra kattintva aktiválódik egy click esemény, melyet az Image.aspx C# kódjában található ButtonPost_Click metódus valósít meg. A metódus lényege, hogy meghívja a GalleryLogic InsertComment metódusát, ami beszúrja a kommentet a comments táblába. 41

47 15. ábra: Hozzászólás írása Kommentek megjelenítése A kommentek megjelenítéséért (16. ábra) az Image.aspx osztály DisplayComments metódusa a felelős. A metódusban táblázat segítségével jelenítem meg a kommenteket. A táblázat két sorból áll. Az első sor pedig két cellából. Az egyik cella tartalmazza a szerző nevét, a másik pedig a komment létrehozásának az időpontját. A második sor is két cellából áll, de ezeket összevontam, így azon komment szövegét tartalmazza, amit a CKEditor segítségével megformázott a felhasználó. Minden egyes komment egy külön táblázatot alkot. Így annyi táblázatunk lesz, mint amennyi kommentünk van az adott képhez. A táblázatot css segítségével felhasználóbaráttá formáztam. 16. ábra: Hozzászólások megjelenítése Tagek hozzáadása a képekhez A felhasználó szemszögéből nézve a tagek az Image.aspx oldalon jelennek meg az aktuálisan kiválasztott kép fölött. Programozás szempontjából ezt úgy oldottam meg, hogy az Image.aspx oldalra source nézetben beillesztettem két panelt. Az egyik panel a PanelTags id-t kapta, a másik pedig a PanelAddTag azonosítót. A két panel közé pedig egy BtnTag id- 42

48 jű, Tag hozzáadása... feliratú gombot szúrtam be. Ez a gomb lesz felelős a PanelAddTag panel megjelenítésért. A PanelTags panelen fognak megjelenni a tagek. Alap állapotban az előbb említett panel és a tartalma látszik, a tag felvitele panel viszont nem. A láthatóságot JavaScript kód szabályozza. A képhez csatlakozó tagek megjelenítéséért az Image.aspx C# osztály DisplayTags nevű metódusa felelős. A metódusban felhasználom a GalleryLogic GetTags metódusát, ami a GalleryDao-ban lévő GetTags metódust hívja meg. A metódus lekérdezi az adatbázisból a tags tábla tartalmát, és egy tag listaként adja vissza. A lista elemeiből a DisplayTags metódus egy táblázatot épít fel. A táblázatot pontosan nem lehet tudni, hogy az hány sorból fog állni, ezért létrehoztam egy int típusú konstanst, melynek értékéül a tízet adtam. Ez a tízes érték jelenti az oszlopok számát. A sorokat pedig a Ceiling metódus segítségével számolom ki, ahogyan ezt a galériák képeivel is tettem. Taget hozzáadni az adott képhez a Tag hozzáadása... feliratú gombra való kattintással lehet véghez vinni. A kattintás létrejöttekor a PanelAddTag panel és a tartalma elérhetővé válik, a Tag hozzáadása... gomb pedig eltűnik. Ezt az eseménykezelést egy JavaScript függvény valósítja meg. A panelen található egy táblázat, mely egy sorból áll. (17. ábra) Az első cellában található egy label, melynek értéke Tag:. A következő cellában egy textbox található, melynek a tartalmát egy RequiredFieldValidator típusú validátor ellenőrzi. Ha üres a tartalma, akkor nem engedi használni a harmadik cellában található Hozzáadás feliratú gomb funkcióját. Az utolsó cellában pedig egy Mégse feliratú gomb található. A Mégse gombra való kattintással egy JavaScript függvény összecsukja a panelt, azaz láthatatlanná válik a felhasználó számára és ha kitöltve maradt volna a textbox tartalma, akkor ezt törli. Azért jó törölni a tartalmat, mert ha ismét szeretne felvinni a felhasználó valamilyen taget, akkor ne kelljen kitörölnie az imént beírt szöveget kényelmesség szempontjából. A textbox kitöltése után a Hozzáadás gombra kattintva meghívódik egy BtnAddTag_Click nevű metódus, melynek célja, hogy beszúrjon egy rekordot a tags táblába. Ezt úgy valósítja meg, hogy a GalleryLogic InsertTag metódusát hívja meg, amely tovább hívja a GalleryDao InsertTag metódusát. A metódus pedig a kiválasztott kép id-ja és a tag értéke alapján felviszi a rekordot a táblába. Ha már létezik ilyen tag, egyértelműen nem viszi fel még egyszer, csak a kapcsolótáblába illeszti be a szükséges id-ket. 43

49 17. ábra: Tag hozzáadása A megosztás beállítás menüjének felépítése Az AjaxControlToolkit elemei közül kiválasztottam és létrehoztam a Default.aspx oldalon egy ModalPopupExtender típusú felugró ablakot (18. ábra). Ha a felhasználó rákattint a Default.aspx oldalon egy adott galéria alatt található felfele fordított tenyeret ábrázoló képre, ez a popup ablak fog megjelenni. Az irányítást JavaScript kód működteti. A popup ablakot panelek építik fel. Az a panel, amely összefogja a popup tartalmát, az a PanelShare, ezen található egy div elem, melyben újabb három div foglal helyet. Az első div, az a PopupHeader, itt található a popup címe. A második div az a body, amiben két újabb panel található. Az első panel neve PanelShareBody. Ez a panel egy táblázatot tartalmaz, melynek eleme egy radio button list, ami három radio button típusú választási opciót tartalmaz. Az elemek értéke rendre a következő: Ne legyen megosztva, Publikus, Megosztás a következő felhasználókkal:. Ezen lehetőségek közül egyszerre csak egy lehet kiválasztva. A másik panel pedig a PanelUserNames, ami pedig check box list-et tartalmaz, check box elemekkel. Ezen elemek közül egyszerre többet is ki tudunk választani. Az utolsó div, pedig a footer, amely két gombot tartalmaz. Az egyik gomb felirata az Ok, a másiké pedig a Mégse. 18. ábra: Megosztás menüjének felépítése 44

50 A megosztás állapotának megjelenítése Amikor a felhasználó rákattint a megosztás ikonra, a felbukkanó popup ablak vezérlését JavaScript kód irányítja. Szükség van egy GetGalleryShare nevű [WebMethod] metódusra, mely elküldi a JavaScript kódnak azt a string típusú adatot, amely tartalmazza a mappa eddig beállított megosztási tulajdonságait, ami három fajta lehet: public, azaz minden felhasználó számára elérhető, noshare, azaz nincs megosztva egyetlen felhasználóval sem, és végül azon felhasználók neve, akikkel meg van osztva az az adott galéria. A public érték visszaadásához a GalleryLogic IsGalleryPublic metódusát használtam fel, mely tovább hívja a GalleryDao IsGalleryPublic nevű metódusát. A metódus egy boolean értéket ad vissza, mely megmondja a kapott galéria azonosítója alapján, hogy az a galéria publikus-e. A noshare érték visszaadásához a GalleryLogic GetUsersSharedGalleryWith metódusát használtam fel, mely továbbhívja a GalleryDao GetUsersSharedGalleryWith nevű metódusát. A metódus visszaadja azon felhasználók listáját, akikkel meg van osztva az adott galéria. Ha ennek a visszatérési érték számossága nulla, azaz senkivel nincs megosztva a galéria, akkor adja vissza a noshare értéket, ha viszont van tartalma, akkor a felhasználók listáját adja tovább a JavaScript kódnak. A JavaScript kód a kapott érték alapján aktiválja a megfelelő radio button-t. Így a felületen láthatjuk, hogy az adott galéria milyen módon van megosztva. A radio button elemek a következők: Ne legyen megosztva, Publikus, Megosztás a következő felhasználókkal:. Ezen elemek a PanelShareBody nevű panelen találhatók. Az utolsó érték aktiválása során nem csak annyit látunk, hogy be van pipálva az értéke, hanem láthatóvá válik a PanelUserNames nevű panel is, ami a rendszerben szereplő összes felhasználó nevét tartalmazza checkbox típusú elemenként, és azon boxok értéke is meg van jelölve, akikkel meg van osztva az adott galéria A megosztás típusának megváltoztatása és beállítása Ha meg szeretnénk változtatni a megosztás típusát, akkor a három radio button közül kiválasztunk egy, a régitől különbözőt, és rákattintunk az Ok feliratú gombra. A gomb megnyomását követően aktivizálódik egy onclick esemény, melyet a Default.aspx BtnOk_Click metódusa kezel le. A metódus a session-ből megkapott galéria id-ja alapján tudja, hogy melyik galériának a beállításait kell módosítania. Mielőtt bármihez is hozzákezdene, meghívja a GalleryLogic UnShareGallery metódusát, amely tovább hívja a GalleryDao UnShareGallery nevű metódust. A metódus annyit csinál, hogy a kapott galéria id alapján kitörli a shares táblából a feltételnek megfelelő rekordot, azaz a galéria nem lesz megosztva senkivel. Ezután három esetet kell vizsgálnia: 45

51 1. eset: ha az első radio button van kiválasztva, azaz a Ne legyen megosztva értékű, akkor meghívja a GalleryLogic SetGalleryToNonPublic metódusát, ami továbbhívja a GalleryDao ugyanezen nevű metódusát. A metódus beállítja a galleries tábla ispublic mezőjét hamis értékre. 2. eset: ha a második radio button van kiválasztva, azaz a Publikus értékű, akkor meghívja a GalleryLogic SetGalleryToPublic metódusát, ami továbbhívja a GalleryDao ugyanezen nevű metódusát. A metódus beállítja a galleries tábla ispublic mezőjét igaz értékre. 3. eset: ha a harmadik radio button van kiválasztva, azaz a Megosztás a következő felhasználókkal: értékű, akkor először meghívja a SetGalleryToNonPublic metódust, ami beállítja a galéria publikusságát nem publikusra, majd végigfut egy foreach ciklussal a checkbox elemeken, megnézi melyik van bejelölve, és ezekre meghívja a GalleryLogic ShareGallery metódusát, ami továbbhívja a GalleryDao ugyanezen nevű metódusát. A metódus pedig beállítja a kijelölt felhasználókkal való megosztást. Ha a Mégse feliratú gombra kattintunk, akkor a JavaScript mindegyik checkbox értékét hamisra állítja, bezárja a PanelUserNames panelt, továbbá eltűnteti a popup ablakot is Galéria törlése Ha a felhasználó rákattint a galéria alatt található törlés ikonra, akkor a keletkezett esemény eredményeként egy popup ablak jelenik meg, amit JavaScript kódból vezérlek. A popup ablakot az AjaxControlToolkit palettában található ModalPopupExtender modullal hozok létre, melynek az id-ja ModalPopupDelete. A modulnak létrehozok egy PanelDelete panelt. Ez a panel fog megjelenni a kattintáskor (19. ábra). A panel egy nagy div-ből áll, amit három kisebb div épít fel. A div-ek a következő neveket kapták: header, body, footer. A header div-ben található a modul elnevezése, ebben az esetben: Galéria törlése. A bodyban található a megerősítő kérdés, ami: Biztosan törlöd a galériát? Végül a footer div-ben pedig két gomb, melyeknek a feliratai: Törlés, Mégse. Ha a felhasználó a Törlés gombra kattint, akkor meghívódik egy BtnDeleteOk_Click metódus, amelyben a session-ből megkapott galéria id-ját felhasználva meghívódik a GalleryLogic DeleteGallery nevű metódusa, majd a Response.Redirect metódus, ami visszairányít az Default.aspx oldalra a törlés végrehajtása után. A DeleteGallery metódusban először lekérdezzük azon képek idját, amelyek az aktuális galériában vannak. Ezeket az id-ket egy imageids nevű listába gyűjtjük. Ezen a listán egy ForEach metódussal végigmenve mindegyik elemre meghívjuk a DeleteImage metódust. Ezáltal kitörlődnek a képek, kommentjeik és tagjeik. Majd ezek 46

52 után meghívódik az UnShareGallery metódus, ami a galériától elveszi a megoszthatóság jogát. Utolsó lépésben pedig kitörölhetjük magát a galériát a galleries táblából. A Mégse feliratú gombra való kattintással a JavaScript kód segítségével bezárja a popup ablakot, és visszairányít a Default.aspx oldalra. 19. ábra: Galéria törlése Kép törlése galériából A Gallery.aspx oldalon az AjaxControlToolkit eszköztárból kiválasztottam a ModalPopupExtender modult, melynek a ModalPopupDelete id-t adtam. A modulnak létrehozok egy PanelDelete panelt. Ezen a panelen fog megjelenni a modul (20. ábra). A modul egy nagy div-ből áll, amit három kisebb div épít fel. A div-ek a következő neveket kapták: header, body, footer. A header div-ben található a modul elnevezése, ebben az esetben: Kép törlése. A body-ban található a megerősítő kérdés, ami: Biztosan törlöd a képet? Végül a footer div-ben pedig két gomb, melyeknek a feliratai: Törlés, Mégse. Ha a felhasználó az Törlés gombra kattint, akkor meghívódik egy BtnDeleteOk_Click metódus, amelyben a session-ből megkapott kép id-ját felhasználva meghívódik a GalleryLogic DeleteImage nevű metódusa, majd a Response.Redirect metódus, ami visszairányít az Gallery.aspx oldalra a törlés végrehajtása után. A DeleteImages metódus első lépésében a kapott kép id-ja alapján töröljük a táblában szereplő ugyanolyan id-jű képet. Második lépésben lekérdezzük azon tagek id-ját az images_tags kapcsoló táblából, ahol a tag_id számossága egy, és a kép id-ja megegyezik a kapcsoló táblában szereplő image_id-vel. A lekérdezett id-ket egy listába rakjuk. Ezen a listán végig megyünk egy foreach metódussal és töröljük azon rekordokat az images_tags kapcsoló táblából, ahol a tag_id megegyezik a listában szereplő tag id-jável. A ciklusban még töröljük azon rekordokat a tags táblából, ahol a tag id megegyezik szintén a listában szereplő tag id-jável. A ciklus végén pedig töröljük még azon rekordokat az images_tags táblából, ahol az image_id megegyezik a törlendő kép id-jával. Utolsó lépésben pedig töröljük azon rekordokat az images táblából, ahol az image 47

53 id megegyezik a törlendő kép azonosítójával. A Mégse feliratú gombra való kattintással a JavaScript kód segítségével bezárja a popup ablakot, és visszairányít a Gallery.aspx oldalra. 20. ábra: Kép törlése Tag törlése Az Image.aspx oldalon az AjaxControlToolkit eszköztárból kiválasztottam a ModalPopupExtender modult, melynek a ModalPopupDelete id-t adtam. A modulnak létrehozok egy PanelDelete panelt. Ezen a panelen fog megjelenni a modul (21. ábra). A modul egy nagy div-ből áll, amit három kisebb div épít fel. A div-ek a következő neveket kapták: header, body, footer. A header div-ben található a modul elnevezése, ebben az esetben: Tag törlése. A body-ban található a megerősítő kérdés, ami: Biztosan törlöd a taget? Végül a footer div-ben pedig két gomb, melyeknek a feliratai: Törlés, Mégse. Ha a felhasználó az Törlés gombra kattint, akkor meghívódik egy BtnDeleteOk_Click metódus, amelyben a session-ből megkapott tag id-ját és a kiválasztott kép id-ját felhasználva meghívódik a GalleryLogic DeleteTag nevű metódusa, majd a Response.Redirect metódus, ami visszairányít az Image.aspx oldalra a törlés végrehajtása után. A Delete Tag metódus első lépésében megszámolja az images_tags kapcsolótáblában található azon rekordok számát, ahol a tag_id megegyezik a kapott tag id-jával és az image_id és megegyezik a kapott kép id-jával. Második lépésben törli az images_tags táblában található olyan rekordokat, amiknek a tag_id-jük megegyezik a kapott tag azonosítójával, és az image_id is megegyezik a kapott kép azonosítójával. Végezetül, ha az első lépésben megszámolt a rekordokból csak egy van, akkor törli a tags táblából azon rekordokat, ahol az id megegyezik a kapott tag azonosítójával. 21. ábra: Tag törlése 48

54 Hozzászólás törlése Csak olyan hozzászólást lehet törölni, amit az adott felhasználó készített. Más felhasználó hozzászólását nem lehet törölni. A hozzászólás törlésénél ugyanazon logikai lépéseket használom fel, mint a kép és a tag törlésénél is. Azaz létrehozok az Image.aspx oldalon egy ModalPopupExtender modult, melynek a ModalPopupDeleteComment azonosítót adtam. A modulnak létrehozok egy PanelDeleteComment panelt. Ezen a panelen fog megjelenni a modul (22. ábra). A modul egy nagy div-ből áll, amit három kisebb div épít fel. A div-ek a következő neveket kapták: DeleteCommentHeader, body, footer. A DeleteCommentHeader div-ben található a modul elnevezése, ebben az esetben: Hozzászólás törlése. A body-ban található a megerősítő kérdés, ami: Biztosan törlöd a hozzászólást? Végül a footer div-ben pedig két gomb, melyeknek a feliratai: Törlés, Mégse. Ha a felhasználó az Törlés gombra kattint, akkor meghívódik egy BtnDeleteCommentOk_Click metódus, melyben a sessionből kiszedett komment azonosítója segítségével meghívja a Gallery.Logic DeleteComment nevű metódusát. Utolsó lépésben pedig visszairányít az Image.aspx oldalra. A DeleteComment metódusban, aminek a GalleryDao osztályban található a kifejtése, töröljük azon rekordokat a comments nevű táblából, ahol a hozzászólás azonosítója megegyezik a kapott hozzászólás azonosítójával. 22. ábra: Hozzászólás törlése Megosztott tartalmak elérése A megosztott galériák láthatóságát úgy valósítottam meg, hogy először is a mester oldalon létrehoztam egy új menüpontot, melynek a Megosztott galériák nevet adtam. Ezek után, hogy ne kelljen megint az elejétől felépíteni egy mester oldalt felhasználó aloldalt, a mester oldal C# kódjában létrehoztam egy Menu_MenuItemClick metódust, ami az oldalak betöltődését befolyásolja a switch-case szerkezet használatával. Annak érdekében, hogy ne hozzak létre új oldalt, query stringeket hoztam létre. Tehát ha a felhasználó a saját galériáit 49

55 szeretné elérni, akkor a webszerver valójában a Default.aspx?galleries=own oldalra irányítja, és ha a vele megosztott galériákat szeretné látni, akkor pedig a Default.aspx?galleries=shared oldalra. Minden egyes oldal Page_Load metódusában megvizsgálom, hogy történt-e postback esemény. Ha nem, akkor lekérem a request-től a galleria nevű attribútum értékét, amit elmentek egy string típusú változóba. Ha a mentett változónak shared az értéke, akkor minden olyan metódust meghívok, ami a megosztott objektumokra igaz. Ha own az értéke, akkor pedig az olyan metódusokat hívom meg, ami a saját objektumokhoz nyújtanak valamilyen funkciót. A mindkettőben közös funkciókat a feltételen kívül hívom meg és hajtom végre. Az oldalakon megjelenő gombok és beviteli mezők láthatóságát JavaScript kódból befolyásolom. Például a megosztott galériák menüpont alatt található galériáknál nem lehet létrehozni új galériákat, nem lehet törölni azokat és nem lehet tovább megosztási beállításokat szabni rájuk. Vagy egy kiválasztott képnél nem lehet törölni a képet, nem lehet feltölteni újabb képeket, nem lehet más szerzők által írt hozzászólást kitörölni, és nem lehet tageket felvinni illetve törölni a már meglévőket Keresés a képek között A keresés megvalósításához létrehoztam a mester oldalon egy újabb menüpontot, melynek a neve Kép keresése. Egy külön aspx oldalt hoztam létre a KepGaleriaWeb projekten belül, mely a Search.aspx nevet kapta. Az oldalon található egy panel, mely a PanelSearch id-t kapta. A panelon egy táblázat foglal helyet, melynek öt sora és két oszlopa van (23. ábra). Az első sor első oszlopában található egy label, melynek a tartalma A kép neve tartalmazza: szöveg. A második oszlopban pedig egy textbox található. Ugyanígy néz ki a második sora is, a labellel, melynek az értéke: A tag tartalmazza: szöveg, és a textbox. A harmadik sor első oszlopában egy label, melynek az értéke: Kezdődátum: a második oszlopban pedig létrehoztam az AjaxControlToolkit eszköztárból egy CalendarExtender típusú elemet. A negyedik sor is olyan, mint a harmadik, kivéve hogy a label értéke Végdátum: lett. Az utolsó sor celláit összevontam, és a cella tartalmának egy Keresés feliratú gombot tettem. Ha a felhasználó rákattint erre a gombra, létrejön egy esemény, amelyet a BtnSearch_Click metódus kezel le. A metódusban lekérdeztem a textboxok értékét, és eltároltam őket string illetve DateTime típusú változókba. A session segítségével lekérdeztem a bejelentkezett felhasználó galériáit és a vele megosztott galériákat. Majd a kapott galériákon egy ForEach ciklussal végigmenve lekérdeztem az összes képet, ami bennük szerepel. A kigyűjtött képeken pedig egy LINQ lekérdezés segítségével a textboxok értékét és a Contains nevű függvényt felhasználva leszűkítettem a keresés feltételének eleget 50

56 téve. Az eredmény megjelenítését pedig egy DisplayImages nevű metódus végzi, mely ugyanúgy táblázat felépítésével dolgozik, mint a galériák és képek megtekintésénél. Az oldal kinézetét most is css kód segítségével formáztam. Ha a felhasználó az eredmények között rákattint egy képre, az esemény lekezelésére egy RaisePostBackEvent metódus aktivizálódik, mely meghívja az OnImageClick metódust. A metódus kiolvassa a sessionből a kiválasztott kép azonosítóját, és átirányítja a felhasználót az Image.aspx oldalra. Ezen az oldalon viszont nem minden esetben használhatóak ki az oldal által nyújtott szolgáltatások. Ha a keresett kép, nem a felhasználó képei közé tartozik, akkor nem törölhet és nem is vihet fel tageket az adott képhez. Hozzászólást írhat és törölheti is az általa megírt hozzászólásokat. Viszont ha a kép nem a sajátja, akkor nem fér hozzá a tag kezeléshez, csak kommentet tud írni, illetve törölni. Az oldalon található még egy Vissza a keresési eredményekhez feliratú gomb. Ha erre rákattint a felhasználó, a webszerver visszairányítja a Search.aspx oldalra, amely a session-ben eltárolt paraméterekből kitölti a megfelelő beviteli mezőket és a talált képeket megjeleníti. 23. ábra: Keresés Admin felület Az admin egy olyan kitüntetett felhasználó, aki rendelkezik minden olyan funkcióval, amivel a többi felhasználói is és ezen felül a rendszerben végbemenő folyamatokról egy statisztikai összegzést is megtekinthet. Létrehoztam a KepGaleriaWeb projektben egy külön oldalt, melyen ezek a statisztikák elérhetővé válnak számára. Az adatbázisba létrehoztam egy új felhasználót, melynek az isadmin mezőjét igazra állítottam. Ezzel felruháztam őt admin jogokkal. Letiltottam az Admin.aspx oldalt, hogy csakis az admin joggal rendelkező felhasználó érhesse el. Ha valamely más felhasználó szeretné elérni az Admin.aspx oldalt, a webszerver átirányítja őt a Default.aspx oldalra. A mester oldalon az eddigi menüsorba beszúrtam egy újabb menüpontot, ahol elérheti ezt az oldalt az admin. Az oldalon két 51

57 diagram található. Az első diagram egy kördiagram (24. ábra), mely százalékos arányba mutatja a feltöltött képek felbontását. Ezt úgy valósítottam meg, hogy létrehoztam egy PieChart azonosítójú Chart típusú elemet. A tartalmát úgy töltöttem fel, hogy A GalleryLogic osztályban létrehoztam egy Dictionary visszatérésű értékű GetPieChartData nevű metódust, mely a GalleryDao-ban található GetAllImages metódust felhasználva kiszűri ebbe a Dictinoary-be a képek szélességét és magasságát egy beállított formátumban. Az Admin.aspx C# kódjában pedig ezt a metódust felhasználva felrajzoltatom az értékeket a diagramra. Ugyanígy hoztam létre a másik diagramot is, ami oszlopdiagram (25. ábra). Az oszlopdiagram értékei a felhasználók, és az adott felhasználóhoz tartozó képek száma. 24. ábra: Kördiagram a képek felbontásáról 25. ábra: Oszlopdiagram a felhasználók képeinek számáról 52

58 5.4 Tesztelés Az alkalmazás tesztelését három részre bontottam. A három réteg alapján: az adatbázis elérésének tesztelése, az üzleti logika tesztelése, illetve a webes alkalmazás tesztelése. Az adatbázist elérő osztályok tesztelésére egységteszteket írtam. Ezek ellenőrzik, hogy az egyes lekérdezések, módosítások, beszúrások és törlések helyesen hajtódnak végre az adatbázisban, illetve helyes eredmény jön vissza az adatbázistól. Az üzleti logika tesztelése során a jelszó titkosítását, illetve a jelszó ellenőrzését teszteltem egységteszttel. Ellenőriztem továbbá, hogy a feltöltött kép ténylegesen mentésre kerül a fájlrendszerbe. A webes alkalmazás működését manuális tesztekkel vizsgáltam, végigjátszva az egyes felhasználói forgatókönyveket. Így kiderültek a felület esetleges hibái, következetlenségei, amelyeket javítottam. 5.5 Továbbfejlesztési lehetőségek Az alkalmazás jelen formájában is használható, de kibővíthető bizonyos kényelmi funkciókkal. Ilyen például a felhasználó jelszavának módosíthatósága, a komment módosítása, a galéria és a kép nevének módosítása, illetve a keresési lehetőségek bővítése. Az alkalmazás esetlegesen úgynevezett single page application működésre is átalakítható, ilyen esetben az alkalmazás működése egyetlen Html oldalon történne, JavaScript vezérlésével a böngésző töltése nélkül valósulna meg az oldal tartalmának dinamikus módosítása az egyes funkciók kiválasztásakor. 53

59 6. Összegzés Szakdolgozatom elkészítése során ismertettem a webes alkalmazások építőelemeit, összehasonlítottam a Java és a.net technológiákat és részletesen megismerkedtem a Microsoft ASP.Net technológiával. Manapság gyakoriak a webes képgalériák, amelyekben albumokba rendezve tölthetünk fel képeket. Szerettem volna én is egy ilyen képgalériát implementálni, hogy megismerhessem működését. Az implementációhoz a Microsoft ASP.Net technológiáját használtam, továbbá felhasználtam egy javascript keretrendszert, a JQuery-t és az egyes oldalak formázását css stíluslapok használatával végeztem. Az alkalmazásomban egy ingyenes és nyílt forráskódú komponenst, a CKEditort is felhasználtam, amely segítségével a felhasználók formázva készíthetik a hozzászólásukat. A felhasználók képesek galériákat létrehozni és törölni, ezekbe képeket feltölteni, a képeket kommentálni, elnevezni és törölni. A megvalósítás során használtam úgynevezett tageket is, amelyeket a felhasználók rendelhetnek képeikhez és felhasználhatóak keresésnél. A felhasználók galériáikat megoszthatják más felhasználókkal, vagy publikussá tehetik. Az alkalmazás bővíthető további funkciókkal, amelyek lehetnek kényelmi funkciók, mint például a galéria vagy a kép nevének módosítása, illetve a hozzászólás módosítása. Az alkalmazás esetlegesen úgynevezett egy oldalas alkalmazássá alakítható, ahol minden funkció egyetlen oldalon, a böngésző töltése nélkül hajtható végre. 54

60 7. Summary In the course of making my thesis I have reviewed the elements of web applications, I have compared Java technology with.net technology and I have got acquainted with the Microsoft ASP.Net techology. Nowadays image galleries are common on the web, which can store images uploaded by the users in albums. I would have also liked to implement such a gallery in order to see how it works. I have implemented the application using the Microsoft ASP.Net technology. I have used JQuery which is a javascript framework. I have used css stylesheets to design the pages in the web application. I have also used CKEditor, which is a free and open source component. By the help of CKEditor the users can design their comments. The users can create and delete galleries, upload, name, comment and delete pictures. In the course of the implementation I used so-called tags, which can be assigned to pictures and can be used for searching. The users can share their galleries with other users or make them public. The application can be improved by further features, which can be ease of use features, such as modifying the name of the gallery or the picture or edit the comment. The application can be transformed into a single page application which consists only one page where every feature is available without the refreshing of the browser. 55

61 8. Köszönetnyilvánítás Köszönetet szeretnék mondani tervezésvezetőmnek, Szűcs Miklós Tanár Úrnak a munka menetének felügyeletéért és a hasznos tanácsokért. Továbbá szeretném megköszönni családomnak a dolgozatom megírásához alkalmas környezetet, türelmet és bíztatást, valamint páromnak a megértő türelmét és szakmai segítségét. 56

62 9. Irodalomjegyzék [1] A digitális fotózás története Forrás: [2] George Shepherd: Microsoft ASP.NET 4 Step by Step ISBN: [3] HTML5 Introduction Forrás: [4] Honlapépítés a XXI. században ISBN: [5] Antal Margit: Java alapú webtechnológiák ISBN: [6] Reiter István: C# programozás lépésről lépésre ISBN: Linkek utoljára ellenőrizve: november

63 10. Mellékletek 1. melléklet: Use case diagram 58

64 2. melléklet: Adatbázis tábláit létrehozó SQL parancsok CREATE TABLE dbo.users ( id INT PRIMARY KEY IDENTITY(1,1), username NVARCHAR(50), password NVARCHAR(MAX), isadmin BIT ); CREATE TABLE dbo.galleries ( id INT PRIMARY KEY IDENTITY(1,1), name NVARCHAR(50), ispublic BIT, user_id INT, FOREIGN KEY(user_id) REFERENCES users(id) ); CREATE TABLE dbo.images ( id INT PRIMARY KEY IDENTITY(1,1), name NVARCHAR(50), url NVARCHAR(100), height INT, width INT, size INT, creation_date DATETIME, gallery_id INT, FOREIGN KEY(gallery_id) REFERENCES galleries(id) ); CREATE TABLE dbo.tags ( id INT PRIMARY KEY IDENTITY(1,1), tag NVARCHAR(50) ); CREATE TABLE dbo.comments ( id INT PRIMARY KEY IDENTITY(1,1), text NTEXT, author_id INT, time DATETIME, FOREIGN KEY(author_id) REFERENCES users(id), image_id INT, FOREIGN KEY(image_id) REFERENCES images(id) ); CREATE TABLE dbo.shares ( id INT PRIMARY KEY IDENTITY(1,1), user_id INT, FOREIGN KEY(user_id) REFERENCES users(id), gallery_id INT, FOREIGN KEY(gallery_id) REFERENCES galleries(id) ); CREATE TABLE dbo.images_tags ( image_id INT, FOREIGN KEY(image_id) REFERENCES images(id), tag_id INT, FOREIGN KEY(tag_id) REFERENCES tags(id) ); 59

65 3. melléklet: Osztálydiagram 60