Pentaschool Oktatási Központ Számítástechnikai programozó
ZSÍROS TIBOR ELEKTRONIKUS KERESKEDELMI PORTÁL FEJLESZTÉSE
Kolman Nándor Szaktanár konzulens
TARTALOMJEGYZÉK
1.
Bevezetés.................................................................................................... 2
2.
Internetes kereskedelem ............................................................................. 3
3.
Feladatspecifikáció..................................................................................... 4
4.
Tervezés...................................................................................................... 6
5.
4.1.
Adatbázis megtervezése...................................................................... 6
4.2.
Felülettervezés .................................................................................. 18
4.2.1.
A tervezésben használt technikák.............................................. 18
4.2.2.
Adminisztrációs felület.............................................................. 22
4.2.3.
Felhasználói felület.................................................................... 23
Megvalósítás............................................................................................. 24 5.1.
A megvalósításban felhasznált technológiák .................................... 25
5.2.
A rendszer logikai működése............................................................ 33
5.3.
Osztályok .......................................................................................... 34
5.4.
Adminisztrátori felület megvalósítása .............................................. 37
5.5.
Felhasználói felület megvalósítása ................................................... 38
6.
Üzembe helyezés...................................................................................... 39
7.
Tesztelés ................................................................................................... 40
8.
Összefoglalás............................................................................................ 41
9.
Felhasznált irodalom ................................................................................ 43
10. Az elektronikus kereskedelmi portál elérhetősége................................... 44
1
1. Bevezetés Napjaink egyre gyorsuló világa megköveteli a fejlődés ütemének gyorsulását is. A fejlődő országokban szinte minden háztartás rendelkezik vagy hamarosan rendelkezni fog internet hozzáféréssel. Hazánkban a tavalyi évben mintegy másfél millió háztartás rendelkezett számítógéppel és megközelítőleg 800 000 háztartásban volt internet kapcsolat. Életünkben az internet használat olyan hétköznapi eszközzé válik, mint az elektromos áram, vagy a tömegközlekedés. Megkönnyítheti mindennapi életünket, például a banki tranzakciók otthonról történő ügyintézésével, vagy akár egy jó könyv kölcsönzésével, hírek böngészésével, elektronikus levelezéssel, egyszóval az információ gyors és hatékony továbbításával. A nagyvállalatok, és a kisebb cégek számára is lehetőség nyílik a gyors adatcserére partnereikkel, így lehetővé vált üzleti tevékenységek kiadása, kiszervezése, másik cég megbízása bizonyos feladatok elvégzésével, legyen az bárhol a világon. Ezek a tevékenységek (outsourcing) bevett gyakorlat például az amerikai vállalatok, és India vagy Japán és Kína között, de hazánkban is egyre nagyobb szerepet kap a költséghatékonysága miatt. Akár szoftverfejlesztéseket, könyveléseket és orvosi látleletek véleményezésének folyamatát, munkamenetét is ki lehet adni, köszönhetően a gyors és biztonságos adattovábbításnak, és az adatok digitalizálásának. Mindezt figyelembe véve a világ ma már nem lenne képes működni az internet nélkül, így a hétköznapok tevékenységeink, folyamataink is áttevődnek az elektronikus birodalomba. Az egyik interneten keresztüli tipikus tevékenység a vásárlás. A termékek és azokat kínáló úgynevezett webáruházak széles választéka megtalálható akár több nyelven is. Az egyik legnépszerűbb böngésző a google a webáruház szóra kevesebb, mint egy másodperc alatt talál körülbelül kettőmillió bejegyzést. Ez persze nem konkrétan a webáruházak számosságát jelenti, de azt mindenképpen, hogy mennyire elterjedt maga a fogalom és a mögötte található elektronikus kereskedelmi rendszerek. Mindezek miatt döntöttem
úgy,
hogy
a
szakdolgozatom
témájául
az
elektronikus
kereskedelmet választom. A középponti témám a szakdolgozatban egy 2
webáruház megtervezése, felépítése. Egy fejlesztési projekt során mutatom be egy általános alapokra épülő webáruház alapvető funkcióit és azok működését. A szakdolgozat végigvezet a fejlesztés szakaszain, bemutatva ezzel egy fejlesztési projekt lépéseit. Ezen felül bemutatom azokat a mai webes technológiákat, tervezési koncepciókat és irányokat, amelyek segítségével életre keltettem a webes áruházat. A dolgozat elolvasása után egyértelművé válik az olvasó számára egy webes áruház funkcionalitása, működése, és a mögötte álló technológiák alapja. 2. Internetes kereskedelem Az internet elterjedésével hazánkban is egyre keresettebbek az internetes vásárlást biztosító ún. webáruházak. Hazánkban a 2006-os év legnépszerűbb internetes áruháza a Bookline könyváruház lett, melynek éves forgalma ugyan ebben az évben 1 418 Millió Ft lett. Ez is azt mutatja, hogy a felhasználók körében egyre jobban elterjed az elektronikus kereskedelem, egyre nagyobb bizalmat szentelnek az emberek a karosszékből történő vásárlásnak. Évekkel ezelőtt még a bizalom hiánya miatt kevésbé használták az emberek az internet eme funkcióját, viszont napjainkban a vásárlás egyre inkább elterjed, a bizalmatlanság csak a fizetési szokásokban jelentkezik. A vásárlók többsége a megbízható utánvételes fizetési módot választja, pedig rendelkezésre áll a bankok által biztosított portálokon keresztül bankkártyás fizetések, illetve a nemzetközi webshopok-on keresztüli vásárlás esetén az online fizetési megoldások, mint a Moneybookers, vagy a Paypal. A Szonda Ipsos és a Gfk Hungária kutatóintézetek Internet Audience Research (IAR) kutatásának 2006. októberében publikált eredményei alapján a legalább havi rendszerességgel internetezők 14%-a használja az internetet vásárlásra, a vásárlásokat megelőzően pedig 53% keres információt az interneten (akár online, akár hagyományos). A GKI által az online áruházakról készített kutatás alapján elmondható, hogy 2005-ben az internetes kiskereskedelmi forgalom 19 milliárd forint volt. Azóta ez a szám csak emelkedett, a legtöbb feltételezés szerint 2006-os forgalom 253
30 milliárd Ft.-ot is elérheti. A pontos értékről még nincs publikus információ. Jelenleg is tapasztalható, hogy az internetes áruházak többsége különböző kedvezményekkel próbálja meg vásárlásra buzdítani a vásárlókat. A boltok többsége 1-10%, de előfordul, hogy 20-25% kedvezményt is adnak. Nagyon sok áruház felismerte a vásárlók bizalmatlanságát a fizetési módokat illetően, ezért aki megteheti, az személyes átvételt is lehetővé tesz. Így a webáruházban csak kifejezetten a termék kikeresése és megrendelése történik, a konkrét fizetés és átvétel pedig az áruház által megadott cím(ek)en lehetséges. 3. Feladatspecifikáció A cél egy olyan általános szabályokon működő webáruház elkészítése volt számomra, amelynek feladata az ügyfelek elektronikus úton történő kiszolgálása. Minden olyan alapvető funkció biztosítása, amely egy vásárlás során megszokott és egyértelmű. Lehetőséget kellett biztosítanom az oldalon található termékek közötti böngészésre, azok bizonyos kritériumok alapján való keresésére és a kíván termék árának, egyéb adatainak feltüntetése mellett annak megvásárlására. Amennyiben vásárlásra kerül a sor, akkor a webáruházban regisztrálni kell a postázáshoz és a számlázáshoz szükséges adatokat. Ezt az alkalmazás regisztrációs oldalán található űrlap megfelelő kitöltésével lehet megtenni. A regisztráció során meghatároztam a kötelezően megadandó információkat is, ezek megadásának biztosítását mind kliens oldalon (javascript) mind szerveroldalon (PHP) biztosítani kell. Az oldalra való belépés után lehet elküldeni a vásárlási igényt. A belépés egy felhasználói név és egy jelszó megadását jelenti, amelyet a rendszer ellenőriz, majd helyes adatok esetén beléptet. A webáruház üzemeltetése szempontjából szükség van egy adminisztrátori felületre. Ez teszi lehetővé a regisztrált felhasználók adatainak ellenőrzését, azok szükség esetén történő manipulációját. Ugyanitt lehet a webáruházban található termékek adatait módosítani és új terméket regisztrálni. Ezen kívül itt lehet majd a leadott vásárlási igényeket kezelni. A végrehajtás során két felületet hoztam létre. Egyet a webáruháznak és egy másikat az adminisztrációs felületnek. Ez lehetővé teszi, a felhasználói és
4
az adminisztrációs folyamatok teljes elkülönítését. Biztonsági szempontból is előnyösebbnek látom, ha ezek a feladatok nem illeszkednek bele a felhasználói felületbe. Mind a két felületet azonos stíluselemek alkotják így az adminisztrátor számára az átjárás a két felület között nem okoz semmilyen nehézséget. A felületek főbb alkotó elemei menüelemek, tartalmi blokkok is azonos elhelyezkedéssel rendelkeznek. A vásárláshoz a regisztrációt egy regisztrációs űrlap kitöltésével és annak a felhasználó által történő továbbküldésével biztosítottam. A vásárláshoz és a számlázáshoz megadandó kötelező információk biztosítását úgynevezett kötelező mezők kitöltésével biztosítottam. Ezek megadása nélkül nem lehetséges a regisztráció és a vásárlás sem. A munkafolyamatok részfeladatokra bontásával biztosítani tudtam, hogy egy előre megtervezett tematika alapján építsem fel a fejlesztés menetét. Így láthattam, hogy mi az, ami már elkészült, és mennyi időt kell még fordítanom a hátralévő fejlesztési munka. Ez a fejlesztési projekt felépítésében és menedzselésében segített. A fejlesztési munka során előzetesen a következő alapvető feladatok tervezését tartottam szükségszerűnek: A rendszer általános működése Egy magas szintű működési folyamat felvázolása eltekintve a ténylegesen felhasznált szintaktikai elemek bemutatásától. Így láthatom a webáruház, átfogó általános szinten elvárt működési irányait, folyamatait. Adatbázis megtervezése Egy jól átgondolt és strukturált adatbázis gyors és biztos működést alapoz meg. Mivel ez a tervezett rendszer egy komoly, több táblás adatbázisra épül, ezért mondhatjuk, hogy ez a részfeladat egyike a legfontosabbaknak, amit el kellett végeznem. Megtervezni az adatbázisban használt adatok tulajdonságait, az azokat magukba foglaló táblák felépítését és a táblák közötti kapcsolatot. Felhasználói felületek megtervezése Figyelembe véve az általános írott és íratlan szabályokat, amiket egy weblaptervezéskor szem előtt tartunk, létre kell hoznom egy jól strukturált
5
átlátható, az alapkoncepciót megvalósító és kellő felhasználói élményt biztosító felületet. Ebben a fejezetben ennek a felületnek a megtervezését fogom elvégezni. Felállítom az oldalak felosztását, megtervezem a használt betűkészletet, a felületeken uralkodó színvilágot. Kódolás Az előzetes tervek alapján elkezdem a tényleges kódolást, a webáruház működését biztosító, a felhasználó és az adatbázis közötti kapcsolatot kiépítő rendszer kialakítását. Ha az előző részfeladatokat és azok céljait sikeresen meg tudtam határozni, akkor a tényleges kódolás a fejlesztési munka kisebbik részét fogja jelenteni a számomra, mivel már látható számomra az elvárt eredmény. Így célirányosan tudom végrehajtani a fejlesztést. Üzembe helyezés Az
elkészült
termék
használni
kívánt
háttérrendszereken
történő
elhelyezésének, üzembe állításának menetét írom le. Bemutatva az eddig ilyen tevékenységekből szerzett tapasztalataimat. Tesztelés A lefejlesztett felületek teljes körű tesztelésének leírása. A teszt során kapott eredményeket összevetem a meghatározott működési elvárásokkal. Hiba esetén elvégzem a szükséges korrekció. A felsorolt részfeladatok bővebb kifejtését a dolgozat további részében írom le. 4. Tervezés 4.1.
Adatbázis megtervezése
Az adatbázis tervezése az első lépés volt a tényleges webes alkalmazás megvalósítása során. A folyamatot két részre különítettem el, egy elméleti tervezésre és egy fizikai leképzésre, megvalósításra. Át kellett gondolnom, hogy milyen adatokat fogok tárolni az adatbázisban, és ezek az adatok hogyan fognak kapcsolódni egymáshoz. Meghatároztam az adatokat összefogó táblázatok felépítését, a bennük található mezők jellemzőit. Nagy hangsúlyt fektettem az indexelésre is, mivel a relációban tárolt adatok gyors 6
visszakeresésében nagy szerepe van. Ezeken keresztül könnyen kikereshető a kulcsot tartalmazó fizikai sor helye és így az ott tárolt adatok gyorsan, hatékonyan kinyerhetők. Első lépésben egy tagolatlan táblát hoztam létre az alapok meghatározásához. Így fel tudtam vázolni, hogy milyen adatokra, mezőkre és értékekre lesz szükség az adatbázisban. Itt még nincs szó táblák közötti kapcsolatokról, minden adatot egyetlen tagolatlan táblába zsúfoltam bele. Ez a tárolási forma nem hatékony, így ezt a formát a későbbi modellezésem során, a harmadik normálforma eléréséig próbáltam átalakítani. Általában ez a normálforma elegendő ahhoz, hogy megszüntesse a redundanciát és rugalmas, bővíthető, jól strukturált adatbázist hozzak lére. Redundanciáról akkor beszélünk, ha valamely tényt vagy a többi adatból levezethető mennyiséget ismételten (többszörösen) tároljuk az adatbázisban. A redundancia, a szükségtelen tároló terület lefoglalása mellett, komplikált adatbázis frissítési és karbantartási műveletekhez vezet, melyek könnyen az adatbázis inkonzisztenciáját okozhatják. Egy adatbázis akkor inkonzisztens, ha egymásnak ellentmondó tényeket tartalmaz. A reláció elmélet módszereket tartalmaz a redundancia megszüntetésére az úgynevezett normál formák segítségével, azaz az adatbázis táblák normalizálásával. Ennek azért láttam szükség, hogy a későbbiekben az adatok kezelhetősége és az adattáblák kapcsolatainak átláthatósága hatékonyabb legyen. Az azonos csoportokba tartozó adatokat egy táblába soroltam, és azon táblák között ahol szükséges volt ott azonosítók alapján kapcsolatot hoztam létre. Normalizálás alatt bizonyos szabályok alkalmazását értjük, melyek nagyban megkönnyítik majd számunkra az adatbázisaink fenntartását. A normalizálás voltaképpen az adatbázisok szervezésének egy módja, melynek célja, hogy a táblák mindig a megfelelő kapcsolatba kerüljenek egymással. Első normálforma szabályai - A táblák nem tartalmazhatnak ismétlődő csoportokat - A különböző fogalmakkal kapcsolatos adatokat külön táblákba kell elhelyezni Második normálforma szabályai
7
- A nem-kulcs attribútumok nem függhetnek egyetlen elsődleges kulcs valódi részhalmazától sem Harmadik normálforma szabályai - Egyetlen attribútum sem függhet más nem-kulcs attribútumoktól Ez a tervezésben annyit jelentett, hogy addig bontottam részeire az adatokat, amíg azok kezelhető, jól bővíthető és stabilan működő rendszert hoztak létre. Amint elkészült az előzetes adatmodell akkor átnéztem az alkalmazás leendő felhasználójának a szemszögéből is. Ezen a ponton kellett meghatározni az üzleti logikát és azt is meg kellett vizsgálni, hogy az adatmodell eleget tesz-e az üzleti logika által megszabott követelményeknek. A relációs adatbázisok esetében a logikai tervezés során a relációk már elnyerhetik végleges alakjukat, melyeket egyszerűen leképezhetünk az adatbázis kezelőben. A fizikai tervezés során inkább arra koncentráltam, hogy a logikai szerkezet mennyire felel meg a hatékony végrehajtás feltételeinek, illetve milyen indexeket rendeljek az egyes relációkhoz. A relációkon végrehajtott tranzakciók
műveletegyüttest gyors
tranzakciónak
végrehajtását
8
nevezik
kívánjuk
és
általában
elérni
a
vele.
Az adatbázis táblái Az OnLine Shop adatbázis jelen állapotában 10db táblát tartalmaz. A FELHASZNÁLÓK tábla tartalma: azon:
A felhasználó azonosítója (auto increment)
vezetekNev:
A felhasználó vezetékneve
keresztNev:
A felhasználó keresztneve
Email:
A felhasználó e-mail címe
cegNev:
Céges regisztráció esetén cégnév
jelszo:
A felhasználó jelszava
telefonszam:
A felhasználó telefonszáma
cimOrszag:
A felhasználó postázási címe (Ország)
cimVáros:
A felhasználó postázási címe (Város)
cimKozterulet:
A felhasználó postázási címe (Közterület)
cimHazszam:
A felhasználó postázási címe (Házszám)
cimIranyitoszam
A felhasználó postázási címe (Irányítószám)
szamlaCimOrszag
A felhasználó számlázási címe (Ország)
szamlaCimVaros
A felhasználó számlázási címe (Város)
szamlaCimKozterulet
A felhasználó számlázási címe (Közterület)
szamlaCimHazszam
A felhasználó számlázási címe (Házszám)
szamlaCimIranyitoszam A felhasználó számlázási címe (Irányítószám) Datum
A regisztráció dátuma
Ez a tábla a webáruházba látogató és ott regisztrációt végrehajtó felhasználók adatait tárolja. Ezen adatok alapján történik meg az oldalra való belépés és a vásárlás során a termék postázása a felhasználó felé, illetve a számlázás. Szintén ezen adatok alapján lehet felvenni a kapcsolatot a felhasználóval. Fontosnak tartottam a postai és a számlázási adatok külön tárolását, hiszen ezek eltérhetnek egymástól. Így nagyobb rugalmasságot ad a felhasználó felé.
9
FELHASZNÁLÓK tábla: Oszlopnév
Oszloptípus
Hossz
Azon
INTEGER
11
vezetekNev
VARCHAR
75
keresztNev
VARCHAR
75
Email
VARCHAR
155
cegNev
VARCHAR
255
Jelszo
VARCHAR
55
telefonszam
INTEGER
11
cimOrszag
VARCHAR
45
cimVaros
VARCHAR
55
cimKozterulet
VARCHAR
45
cimHazszam
INTEGER
3
cimIranyitoszam
INTEGER
4
szamlaCimOrszag
VARCHAR
45
szamlaCimVaros
VARCHAR
55
szamlaCimKozterulet
VARCHAR
45
szamlaCimHazszam
INTEGER
3
szamlaCimIranyitoszam INTEGER
4
Datum
19
DATETIME
ADMINFELHASZNALOK tábla tartalma: azon:
Adminisztrátor azonosító
felhasználóiNev: Az adminisztrátor felhasználói neve jelszo:
Az adminisztrátor jelszava
rogzitesDatuma:
A regisztráció dátuma
Ebben a táblában szerepeltetem azokat a felhasználókat, akik az adminisztrációs felületre beléphetnek. Itt találhatók a belépéshez szükséges adatok, felhasználói név, jelszó és a regisztráció dátuma.
10
ADMINFELHASZNALOK tábla: Oszlopnév
Oszloptípus Hossz
Azon
INTEGER
2
felhasznaloiNev VARCHAR
55
Jelszo
VARCHAR
55
rogzitesDatuma
DATETIME 19
TERMEKTIPUS tábla tartalma: azon:
A terméktípus azonosítója
nev:
A termektípus neve
datum: A terméktípus rögzítésének dátuma
Ebben a táblában találhatók a termékkategóriák. Ezek segítségével tudom csoportokba rendezni a termékeket (mobiltelefon, headset, akkumlátor stb.) így azokat könnyebben meg lehet találni a felületen. Ezek segítségével akár többféle termék is regisztrálható az oldalon, kellő dinamizmust adva ezzel az alkalmazásnak.
TERMEKTIPUS tábla: Oszlopnév Oszloptípus Hossz Azon
INTEGER
2
Nev
VARCHAR 95
Datum
DATE
10
11
TERMEK tábla tartalma: azon:
A termék azonosítója
Gyartó:
A termék gyártójának a neve
tipus:
A termék típusszáma
termekTipus:
A terméktipus táblában található terméktípus azonosító
kep:
A termék képét tartalmazó file címe (URL)
ar:
A termék ára
datum:
A regisztráció dátuma
saleEffectiveDate:
A termék eladhatóságának a kezdete
saleExpirationDate: A termék eladhatóságának a vége Akciós:
Egy indikátor ami megjelöli, hogy akciós-e a termék vagy sem
A táblában a webáruházban található regisztrált termékek vannak eltárolva. Itt található a gyártójuk, típusuk, áruk és rögzítési dátumuk is. Ezen kívül még két dátum is szerepel itt, ami az eladhatóságot szabályozza. Ennek azért láttam szükségét, mert így egy már létező termék megszüntetése esetén is tovább tárolhatóak annak adatai, és szükség esetén az eladhatóság manipulálásával ismét aktiválható kikerülve az ismételt regisztrációt.
TERMEK tábla: Oszlopnév
Oszloptípus Hossz
Azon
INTEGER
Gyarto
VARCHAR 55
Tipus
VARCHAR 155
termekTipus
INTEGER
Kep
VARCHAR 155
Ar
INTEGER
11
Datum
DATE
10
saleEffectiveDate
DATE
10
5
2
12
saleExpirationDate DATE
10
Akcios
1
INTEGER
TERMEKTULAJDONSAG tábla tartalma: termekAzon:
A TERMEK táblában található termékek azonosítója
rendszer900:
Indikátor, a termék adott szolgáltatását jelzi (900MHz)
rendszer1800: Indikátor, a termék adott szolgáltatását jelzi (1800MHz) rendszer1900: Indikátor, a termék adott szolgáltatását jelzi (1900MHz) meret:
A termék méretét jelzi (100x48x19.5)
akkumlator:
A termék default akkumlátorának mérete (750 mAh Li-Pol)
Kijelzo:
A termék kijelzőjének mérete, ha van (262000/176x220)
naptar:
Indikátor, a termék adott szolgáltatását jelzi (naptár)
infra:
Indikátor, a termék adott szolgáltatását jelzi (Infraport)
bluethooth:
Indikátor, a termék adott szolgáltatását jelzi (bluethooth)
wap:
Indikátor, a termék adott szolgáltatását jelzi (WAP)
mms:
Indikátor, a termék adott szolgáltatását jelzi (MMS küldés)
gprs:
Indikátor, a termék adott szolgáltatását jelzi (GPRS)
3g:
Indikátor, a termék adott szolgáltatását jelzi (3G)
edge:
Indikátor, a termék adott szolgáltatását jelzi (EDGE)
Kamera:
A terméken található kamera felbontása, ha van (640x480)
datum:
A terméktulajdonságok regisztrálásának dátuma
A táblában találhatók a termékekhez tartozó általános tulajdonságok, technikai paraméterek. A TERMEK táblában szereplő azon – nevű termékazonosító alapján hivatkoztam a TERMEK táblára és az ott azonosított termékekhez rendelt tulajdonságokra. Olyan adatok tárolását terveztem itt, amelyek segítségével egy körülbelüli képet kaphatunk a kiválasztott termék szolgáltatásairól, fizikai paramétereikről, mint a méret, vagy a kijelző felbontása.
13
TERMEKTULAJDONSAG tábla: Oszlopnév
Oszloptípus Hossz
termekAzon
INTEGER
5
rendszer900
INTEGER
1
rendszer1800 INTEGER
1
rendszer1900 INTEGER
1
Meret
VARCHAR
15
akkumlator
VARCHAR
18
Kijelzo
VARCHAR
25
Naptar
INTEGER
1
Infra
INTEGER
1
bluethooth
INTEGER
1
Wap
INTEGER
1
mms
INTEGER
1
Gprs
INTEGER
1
3g
INTEGER
1
Edge
INTEGER
1
Kamera
VARCHAR
12
Datum
DATETIME 19
HÍRLEVÉL tábla tartalma: hirlevelAzon:
Egy alap érték a hírlevél funkcióhoz
felhasznaloAzon: A regisztrált felhasználók azonosítója
A tábla azon felhasználók azonosítóját tartalmazza, akik feliratkoztak a webáruház regisztrációs folyamata során a hírlevél szolgáltatásra. Így egyértelműen látható az alkalmazást üzemeltető számára, hogy kinek kell elküldeni az aktuális hírlevelet.
14
HIRLEVEL tábla: Oszlopnév
Oszloptípus Hossz
hirlevelAzon
INTEGER
3
felhasznaloAzon INTEGER
11
BEVÁSÁRLO_KOCSI tábla tartalma: Session_id
A munkamenet azonosító
Termek_azon A TERMEK táblában található termékazonosító a kiválasztott termék egyértelmű azonosításához Termek_ar
A TERMEK táblában található termékazonosítóhoz tartozó ár. A lehetséges árváltozások miatt fontos itt is szerepeltetni a termék megvásárláskor aktuális árát.
mennyiseg
A
megadott
termékazonosító
alatt
található
termék
megvásárolni kívánt darabszáma Datum
A termék kosárba tételének dátuma
Ebben a táblában találhatók a webáruházban kiválasztott és jövőbeni megvásárlásra a kosárba helyezett termékek. Az adott termék árát itt is eltároltam, így az esetleges termékárakban történő változások során is jól nyomon követhető, hogy az adott termék milyen áron vásárolták meg, elkerülve így az esetleges reklamációkat.
BEVASARLO_KOCSI tábla: Oszlopnév
Oszloptípus Hossz
Session_id
VARCHAR
155
Termek_azon INTEGER
11
Termek_ar
INTEGER
11
mennyiseg
INTEGER
2
Datum
DATETIME 19
15
REDELES_STATUSZ tábla tartalma: azon:
A rendelés státusz azonosítója
nev:
A rendelés státusz neve
datum: A státusz regisztrálásának dátuma
Ebben a táblában található a rendelésekhez kapcsolt rendelési státusz. Ezzel különíthetők el az új és a folyamatban lévő rendelések illetve azok, amelyek már teljesítve lettek.
RENDELES_STATUSZ tábla: Oszlopnév Oszloptípus Hossz Azon
INTEGER
1
Nev
VARCHAR
15
Datum
DATETIME 19
RENDELES tábla tartalma: azon:
A megrendelés azonosítója
felhasznalo_azon: A megrendelést leadó felhasználó azonosítója Statusz:
A megrendelés státusza
datum:
A megrendelés dátuma
A tábla a ténylegesen megrendelés után a megrendelő, felhasználó azonosítóját, a megrendelés státuszát és a megrendelés dátumát tartalmazza.
RENDELES tábla: Oszlopnév
Oszloptípus Hossz
Azon
INTEGER
11
felhasznalo_azon INTEGER
11
Statusz
INTEGER
1
Datum
DATETIME 19
16
RENDELES_TERMEK tábla tartalma: rendeles_azon: A rendelés azonosítója a RENDELES táblából Termek_azon:
A megrendelt termék azonosítója a TERMEK táblából
Termek_ar:
A termek ára amit éppen a megrendelés pillanatában tartalmazott a TERMEK tábla a megadott termékazonosító alatt
mennyiseg:
Megrendelt mennyiség
A tábla a RENDELES tábla kiegészítése, ahhoz kapcsolódik a rendelés azonosítóján keresztül. Tartalmazza a megrendelt termékek azonosítóját, azok árát és a megrendelt mennyiséget. Az termek árat a fent említett indokok miatt itt is eltároltam. (bevásáró_kosár)
RENDELES_TERMEK tábla: Oszlopnév
Oszloptípus Hossz
rendeles_azon INTEGER
11
Termek_azon
INTEGER
5
Termek_ar
INTEGER
11
mennyiseg
INTEGER
2
A fizikai megvalósításhoz a MySQL adatbázis szerverét használtam fel. Ez egy többfelhasználós, többszálú, SQL-alapú relációs adatbázis-kezelő szerver. A szoftver fejlesztője a svéd MySQL AB cég, amely kettős licenceléssel teszi elérhetővé a MySQL-t; választható módon vagy a GPL, vagy egy kereskedelmi licenc érvényes a felhasználásra. Az MySQL az egyik legelterjedtebb adatbázis kezelő, aminek egyik oka lehet, hogy a teljesen nyílt forráskódú LAMP (Linux–Apache–MySQL–PHP) összeállítás részeként költség hatékony és egyszerűen beállítható megoldást ad dinamikus webhelyek szolgáltatására. A MySQL adatbázisok adminisztrációjára a mellékelt parancssori eszközöket (mysql és mysqladmin) használhatjuk. A
17
fejlesztés során én az EMS adatbázis kezelő felületét használtam és a phpMyAdmin
programot,
de
MySQL
honlapjáról
grafikus
felületű
adminisztráló eszközök is letölthetők: MySQL Administrator és MySQL Query Browser. A saját gépen történő fejlesztéshez én az EMS felületét találtam a leghasznosabbnak. Egy jól átlátható és gyorsan működő rendszerről van szó, amellyel tökéletesen épül a MySQL szervere fölé. 4.2.
Felülettervezés
Az alkalmazás fejlesztése során az adatbázisban tárolt adatok megjelenítése, azok rendezett, jól átlátható felületen való továbbítása a felhasználó felé újabb tervezési feladatot jelentett. Egy egységes felület megalkotását tűztem ki célul, szem előtt tartva a webes szabványokat. A szabványok követése lehetővé teszi, hogy az oldal a böngészők nagy részén ugyanolyan megjelenéssel, elvárt működéssel fusson. A böngészők jövőbeni változatain is stabil működő rendszerre számíthatunk. 4.2.1. A tervezésben használt technikák A HTML (Hyper Text Markup Language) nyelv helyett már az XHTML (eXtensible Hyper Text Markup Language) nyelvet használtam fel a tartalom megszerkesztésénél. Ez egy kiterjeszthető HTML nyelv. A jelölőnyelv az XML (eXtendible Markup Language) egy alkalmazása, vagyis XML eszközökkel is feldolgozható. A fejlesztés során nagy segítség, ha a tartalom egyértelműen megmutatkozik, látható hol kezdődik, és hol végződik az adott tartalmi rész. Ezt használva egy jól áttekinthető tartalmi vázat tudtam alkotni, nem több ráfordított idővel mintha nem vettem volna figyelembe a szabványokat. Érdemes megemlíteni az XHTML jelölőnyelv alapvető szabályait:
XHTML: különleges követelményei
Minden kezdőcímkének kötelezően kell egy lezáró párjának is lennie Különleges DOCTYPE meghatározására van szükség 18
Minden elemet, jellemzőt és értéket kisbetűvel kell írni Minden értéket idézőjelben kell megadni, ami lehet egyes (angolos) vagy kettes (normál) Minden jellemzőnek egyértelműen meg kell adni az értékét A XHTML tag-jei segítségével leírható a webes tartalom. Az így leírt tartalmat a böngészők már képesek megjeleníteni. Így kaptam egy vázat, amit aztán később a megrendelő igényei szerint tudok megjeleníteni, formázni. A megjelenítés a böngészők sajátossága lesz alapesetben, mivel nem szabtam meg, hogy mely tag-ek milyen formában és hol jelenhetnek meg az oldalon. Erre szolgál a CSS (Cascading Style Sheets) azaz stíluslapok, amelyek meghatározzák a tényleges megjelenést.
A mai böngészők mindegyike támogatja a CSS-t, de kisebb eltérések azért vannak az egyes böngészők között. Ezért, mivel a szabványokat szerettem volna követni és egy jól strukturált rendszer fejlesztése a cél a CSS használatával valósítottam meg a tartalom formába öntését. Általában külön állományban tároljuk a stíluslapokat css kiterjesztéssel, így én is ezt tettem. Így, ha a stílusleíró kódot külön helyezem el a tartalomtól leválasztva gyorsabb betöltési idővel számolhatok. A CSS stílusok segítségével akár eltérő megjelenítést is biztosíthatok a tartalomnak. Egy HTML tag többféle stílusleíró szabályt is kaphat, attól függetlenül, hogy hol helyezkedik el a dokumentum felépítésében. A stílusok a következő sorrendben fognak érvényesülni prioritási sorrend szerint növekvően:
CSS: stílusok szabályainak rangsora
A böngésző alapbeállítása Külső stíluslap Beágyazott stílus Szövegközi stílus
19
Az alapszintaktika három elemet különböztet meg: kiválasztó, tulajdonság, érték. Pl.:( kiválasztó { tulajdonság: érték } ). A megjeleníteni kívánt elemre többféle módon hivatkozhatunk, használhatunk többféle kijelölőt. Kiválaszthatjuk a megjelenítendő tag-et, kiválasztót és adhatunk neki egy stílust.
Ezen kívül választhatjuk még a következőket: Felsorolás Egyszerre akár több kiválasztóra is érvényesíthetjük a formázást. Ekkor a kiválasztókat egymás után vesszővel elválasztva kell felsorolni. h1, h2, h3, h4 {color: green;} Osztály kiválasztó Ennek segítségével más-más módon tudjuk megjeleníteni az egyes osztályokba sorolt elemek tartalmát. Ezt a class kulcsszó használatával érhetjük el. p.right {text-align: right} p.left {text-align: left} Azonosító alapú szétválasztás A HTML elemeknek megadhatunk egy id tulajdonságot. Így az egyedi id-vel rendelkező elemekhez speciális formázást határozhatunk meg. CSS-ben a # segítségével tudunk elemet id segítségével kiválasztani. A következő példa a kiemel elemet fogja azonosítani: #kiemel {color: red;}
Ezek használatával jól elkülöníthető blokkokra tudtam osztani a tartalmi részeket, így azok megjelenítése egyértelművé, a kódban is jól kivehetővé vált. A CSS további mélyebb áttekintésére a dolgozat keretein belül nincs lehetőség, de rengeteg kiadvány, könyv és internetes portál segít eligazodni a CSS világában.
20
Az alkalmazást két jól elkülöníthető felületre osztotam, egy felhasználói felületre és egy adminisztrátori felületre. Mind a két esetben hasonló felépítésre és stílusra törekedtem, de a tartalmak tekintetében eltérnek egymástól. Mind a két esetben a fent említett szabványokat és nyelveket használtam fel a megvalósításhoz. Nagy segítséget jelentett a fejlesztésben a FIREFOX egy beépülő modulja a Web Developer, amely egy speciális felületet és rengeteg lehetőséget biztosít a webfejlesztéshez. Ez a tool ingyenesen letölthető a mozilla – Firefox Add-ons oldaláról és telepítés után azonnal
hozzáférhetők
az
újonnan
szerzett
szolgáltatások
(https://addons.mozilla.org/firefox/60/). Az első igazán nagy segítséget a CSS szabályainak, használatának a megértése terén nyújtotta. A CSS menü alatt lehetőség van az éppen aktuális oldal stíluslapjának a megtekintésére View CSS. Így látható, hogy az oldal mögött milyen megoldásokat alkalmazott a fejlesztő. A menüpontban az Edit CSS egy szerkesztőfelület ahol élőben szerkeszthető és a képernyőn azonnal látható a stíluslapban történt változás. Ennek köszönhetően sokkal gördülékenyebb volt a felületek tervezése, fejlesztése. Az alkalmazott CSS szabályokat azonnal át tudtam vinni a tényleges css file-ba így a tervezett oldal megjelenése már egy jól megtervezett stíluslap eredménye volt.
Mind a két felület (felhasználói és admin) bővelkedik űrlapokban. Egy jó és szabványos űrlap készítése nehéz feladat, amiben a fenti tool egy másik szolgáltatása segített nekem, amely a Forms menüpont alatt található. Itt a Display Form Details funkcióval azonnal meg tudtam jeleníteni a weblapon található form-ok tulajdonságait, attribútumait. A View From Information az oldalon található űrlapok tulajdonságait egy külön felületre szedve táblázatos formában is meg tudja jeleníteni kiemelve ezeket a grafikus tartalomból, nagy segítséget biztosítva a fejlesztéshez. Ezek használatával már már otthonosan mozogtam a tervezett felületen, de az igazi nagy segítség az Outline menü alatt volt elrejtve. Az itt található kis alkalmazások arra szolgálnak, hogy segítségükkel behatárolhassuk a különböző blokk és egyéb elemek határait.
21
Bekapcsolva azonnal láthatóvá vált, hogy hol helyezkednek el a blokk-ok végei, az űrlapok határai és a cella, táblahatárok. Így már jól látható, hogy hol van esetleg tervezési hiba. Javítani tudtam az egymásba csúszó elemek értékeit, fel tudtam mérni ténylegesen mi mekkora területet foglal és pontosan hol található az oldalon. 4.2.2. Adminisztrációs felület Az első felület, amit megterveztem az adminisztrációs felület volt, hiszen ez alapján tudom feltölteni az adatbázist, és ez alapján tudom a későbbiekben manipulálni, figyelemmel kísérni a webáruház termékeit, megrendeléseit. A felület a következő alapvető területekre tagolódik: Fejléc Bal menüsáv Tartalom Lábléc
Az adminisztrátori felület belépés után a termékek menüpont alatt.
22
A felület megtervezésekor figyeltem a fontosabb menüpontok minél kontrasztosabb megjelenítésére. Ezért kerültek jól látható kiemelt helyre, a bal menüsávba. Ugyanitt kapott helyet az oldalra való belépéshez szolgáló belépés űrlap. A tartalom megjelenítése nagyobb területet kíván, így azt középre a weboldal kétharmadát kitöltő felületre helyeztem el. Így a legfontosabb információk kellő teret kapnak a megjelenítés során. A felület egyértelműen jól elkülönülő blokkokra bontott, így könnyen áttekinthető a rajta található megjelenített információ. A weboldalon jól megtervezett navigáció segít a tájékozódásban. Itt figyeltem arra, hogy minden oldalról egyszerűen és gyorsan vissza lehessen jutni a főoldalra. 4.2.3. Felhasználói felület Ez maga a webáruház felülete. Az alapstílus ugyanaz, mint az adminisztrációs oldalon bővítve egy plusz oszloppal és egyéb tartalmi elemekkel, így az adminisztrátor mindig tudja, hogy éppen hol,melyik felületen jár. Hasonló stílus leképzése segíti az eligazodást a két felült között. Itt lehet majd böngészni az áruház kínálatát képező termékek között. Szintén itt lehet regisztrálni, belépni és vásárolni is. Mivel nagy mennyiségű információt kell megjeleníteni ezért itt a fenti logikát kiegészítettem egy újabb oszloppal. A portál felülete a következő alapvető területekre tagolódik:
Főmenü Fejléc Bal menüsáv Tartalom Jobb menüsáv Lábléc Jól látható helyre került a főmenü, kihasználva a színek adta kontrasztot a sötét háttér és a világos betűszínek között. A bal menüsávba egy
23
dinamikusan változó menüt helyeztem el, ami a webáruház tartalmának megfelelően változik. Így a főmenüvel biztosítottam az alapvető funkciók folyamatos elérhetőségét és a dinamikus bal menüsáv használatával mindig az aktuális az adatbázisba regisztrált termékek megjelenítését.
A felhasználói felület, a samsung termékeinek listája
A termékkategóriákat a többi tartalomtól jól elkülönülő helyre terveztem A tartalmat táblázat formájában jelenítettem meg, így egy jól áttekinthető felületet tudtam kialakítani. 5. Megvalósítás A megvalósítás során az előre átgondolt és megtervezett rendszer tényleges kódokba való átültetését végzem. Mivel a leendő alkalmazás megtervezésekor olyan szoftvereket és technológiákat szerettem volna felhasználni, amelyek szabadon hozzáférhetőek, nyílt forráskódúak, ezért a rendszert PHP alapokra helyeztem, támogatva MySQL adatbázissal és Apache webszerverrel.
24
5.1.
A megvalósításban felhasznált technológiák
A tényleges fejlesztés előtt szükséges egy környezet kialakítása, ami támogatja és futtatja a megírt kódot. Az interneten többféle csomag található, amely szabadon hozzáférhető és egy teljes keretrendszert biztosít a fejlesztéshez. Ilyen például az Apache2Triad, ami Windows 2000/XP alá telepítve tartalmaz Apache-ot, PHP 5-öt MySQL-t és még jó néhány hasznos programot. A fejlesztés megkezdésekor és a fejlesztés során a XAMPP 1.5-ös verziót használtam. Ez szintén egy szabadon hozzáférhető telepítő csomag, amely a telepítés után egy azonnal használható fejlesztői környezetet helyez el a gépünkön, így szinte azonnal neki kezdhettem a kódolásnak a rendszer alapvető paramétereinek módosítása nélkül. Persze azért nem árt tisztában lenni a kódot futtató rendszer tudásával, tulajdonságaival.
Az Apache egy nyílt forráskódú webszerver, ami azt jelenti, hogy program teljes forráskódja szabadon hozzáférhető. A legújabb verzió letölthető a http://www.apache.org/ honlapról. A szoftver platform független, így Windows, Linux és akár OS/2 – es környezeten is futtatható. Mivel alapvetően a web-re fejlesztünk, elengedhetetlen egy webszerver megléte a gépen,
hiszen
ez
a
lefejlesztett
kód
működésének
ellenőrzésekor
nélkülözhetetlen. Nagy segítséget jelentett, hogy a fejlesztés során folyamatosan tudtam követni a kód futásának eredményét.
A PHP (Hypertext Preprocessor) egy kiszolgáló oldali parancsnyelv, amit jellemzően HTML oldalakon használnak. Népszerűsége az új verziók megjelenésével egyre inkább emelkedik. Egy felmérés szerint 1999-ben több mint 1 millió kiszolgálón használták, ez a szám 2003-ra majdnem 14 millióra nőtt. A PHP-t kifejezetten a világhálóra írták, így azokra a problémákra, amelyekkel a webprogramozók nap, mint nap szembesülnek, magában a nyelvben megtaláljuk a megoldásokat. Beépített SQL adatbáziskönyvtárat kínál, így számos adatbázisfajtát önműködően támogat. Egyaránt használják szerveroldali, parancssori és ablakozós alkalmazások megvalósítására. Ezen
25
érvek és a PHP nyelv emberközeli felépítése miatt döntöttem amellett, hogy a kódot ezen a nyelven fejlesztem le. Gyorsan és hatékonyan tudtam egy viszonylag nagy kapacitású keretrendszert építeni vele, ami a mai igényeknek megfelelő dinamikus webes alkalmazás támogatására szolgál.
A tervezéskor és a megvalósításkor is célom volt a rendszert úgy kialakítani, hogy az már az Objektum Orientált Programozási szemléletnek megfeleljen és az objektum orientáció minden jellegzetességét magába zárja. Erre kiváló lehetőséget adott a PHP 5-ös verziója, ami már hiánytalanul biztosítja az objektum központú programozáshoz szükséges alapokat, technikákat, szintaktikai elemeket. A fent említett verzió a következő újdonságokat tartalmazza, amik egy részét igénybe is vette a fejlesztés során:
Beépített XML támogatás SQLite SQL könyvtár Privát, védett tagfüggvények támogatása az osztályokban Osztályállandók támogatása A függvényeknek és tagfüggvényeknek átadott objektum hivatkozásként adódik át Statikus függvények és tulajdonságok támogatása Támogatja az elvont (abstract) osztályokat és felületeket Az OOP egy programozási, tervezési szemlélet, amelynek nagy előnye, hogy átláthatóbbá, könnyebben kezelhetővé és mobilabbá teszi a kódot. Ennek a szemléletnek az alkalmazásával olyan kódot tudtam írni, ami többször is felhasználható,
hordozható
így
a
későbbiekben
egyes
részei
akár
újrahasznosíthatóak, megspórolva ezzel többórányi újabb fejlesztési munkát.
Az alapja az objektum, ami változók és függvények egybezárt csomagja. Az objektum belső működése nagyrészt elrejtett az objektumot használók elől, úgy hogy csak hozzáférést biztosítunk, amin keresztül
26
kérelmeket küldhetünk, és információt kaphatunk az objektumtól. Ezzel egy stabil működésű kódot hozhattam létre, amelyben a fontos és mások számára hozzá nem férhető értékek, változók jól, biztonságosan kezelhetővé váltak a külvilágtól elzárva az objektumok belsejében. Ezek az úgynevezett tagváltozók, amelyekhez a tagfüggvényeken (metódusok) keresztül lehet hozzáférni. Így ki tudtam zárni, bizonyos nem kívánt működési lehetőségeket. Az objektumközpontú programok legnagyobb előnye a kód újrahasznosítása. A létrehozott osztályokat egységbe zárt objektumok létrehozására használjuk, így azokat egyszerűen át tudom vinni egyik projektből a másikba.
Lehetőség van gyermekosztályokat is létrehozni, (öröklés) amik a szülő tulajdonságait öröklik és képesek azt kiegészíteni, módosítani. Ez a módszer több alkalommal is megfordult a kódolásom során, remek alkalmat ad tagfüggvények, változók tovább adására, megkönnyítve, ezzel a fejlesztést, a későbbiekben átlátható kódot hozva létre.
Példa az öröklés megvalósítására:
class Felhasznalo extends dbKapcsolat { }
Az általam tervezett és létrehozott objektumcsaládok, szorosan egymásra épülnek, és az alaptulajdonságaik folyamatosan bővülnek. Mind szélesebb körben használható egyre több tulajdonsággal bíró, de átlátható hierarchiát hozva létre a kódban.
Ahhoz, hogy létre tudjunk hozni egy objektumot először létre kell hozni a sablont amire épül. Ezt a sablont hívjuk osztálynak (class). Ezt a következőképpen tudjuk megtenni:
27
class dbKapcsolat { public $db;
public function __construct() { $this->db = Kapcsolat::getInstance(); } }
(Részlet a megvalósított webalkalmazás kódjából (ddKapcsolat osztály))
Az osztályok létrehozásakor két különleges függvény meghívására, megírására is szükség van. Az egyiket úgy nevezik, hogy konstruktor és arra szolgál, hogy az osztály tulajdonságait beállítsuk vele. A függvény egy új objektum létrehozásakor fut le automatikusan a new kulcsszó kiadásakor. Konstruktort kétféleképpen készíthetünk a PHP 5-ös verziójában. A konstruktor neve megegyező az osztály nevével. Ebben az esetben a program tudja, hogy ez a függvény a konstruktor. Egy másik lehetőség a __construct() függvény. Itt az osztály neve helyett ezt a függvényhívást kell végrehajtanunk.
Példa a konstruktor használatára:
public function __construct($azon = null) { }
A másik függvény a destruktor. Ez arra szolgál, hogy az objektum elvégezze a hozzá kapcsolódó utófeladatokat. Ez általában akkor következik be, ha a kód egyetlen futó folyamata sem hivatkozik a már adott objektumra. Ahogy a konstruktor esetében függvényhívásra van szükség, addig a destruktort esetében azt a PHP automatikusan megteszi helyettem.
28
Példa a destruktor használatára.
public function __destruct() { $this->lezar(); }
Fontos volt számomra a tervezés során, hogy a változókat és tagfüggvényeket csak annyira engedjem láttatni és hozzáférést adni a felhasználóknak amennyire a programműködéshez szükséges, biztosítva ezzel az elvárt működést. Így a kódban folyamatosan figyelemmel kísértem a tagváltozók és tagfüggvények hozzáférésének megfelelő biztosítását. Ezt az OOP három formában biztosítja, public, protected, és privat kulcsszavak megjelölésével. Ezek biztosítják, hogy az osztályokból csak annyit fedjünk fel amennyi feltétlenül szükséges. Ezt a három korlátozást mind az osztályok mind a tagváltozók és a tagfüggvények elkészítése során alkalmaztam.
Példa a korlátozások használatára változónál:
public $lekerdezOsszAdat;
Példa a korlátozások használatára tagfüggvény esetén: public function __construct($azon = null) { parent::__construct(); //azonosító elementése $this->azon = (int)$azon;
} } A fentieken kívül az egyik legfontosabb újítás a PHP 5 –ben a statikus változók és függvények használatának lehetősége. Ez megkönnyítette a
29
munkámat olyan esetekben, amikor egy függvényhívás nem követeli feltétlenül egy objektum létrehozását. Tehát a függvény és a benne található eljárások nem kapcsolódnak közvetlenül az objektum tulajdonságaihoz. Ezeket a függvényeket static kulcsszóval megjelölve statikussá tehetjük azaz közvetlenül hivatkozhatunk rájuk. Ezek használatával meggyorsítható a kód lefutása.
Példa a statikus függvényre:
public static function kilepes() { $_SESSION['felhasznalo_azon'] = null; unset($_SESSION['felhasznalo_azon']); }
A fent leírt OOP szemléletnek köszönhetően, figyelve a szintaktikai elemek megfelelő használatára, olyan kódot sikerült alkotnom, amely bármikor felhasználható egy újabb fejlesztés során. A tervezésre és a kivitelezésre nem ment el több idő, mintha egy általános függvényalapú szemléletet követtem volna. Tapasztalataim szerint az OOP-s rendszer stabilabb, jobban átlátható működést és kódot eredményezett. Az elvárt eredmények kiszámíthatóbbak. Előre lehet tervezni a kód alapján a várható működést. A hibajavítás terén is sokat segített az előre megtervezett keretrendszer. Hibák során egyértelműen beazonosítható volt számomra a hiba forrása, így a javításukat is gyorsan el tudtam végezni. Figyelembe véve, hogy a legtöbb programozási nyelvben és a programfejlesztések során az objektum központú gondolkodást tartják szem előtt, nagy előnynek érzem, hogy a fentiek használatával alkottam meg a webes alkalmazásomat, kihasználva és elsajátítva ezzel az OOP előnyeit, tulajdonságait.
A fejlesztés során próbáltam a már meglévő –fent említett- és használt technológiák listáját szélesíteni és a ma használatban levő, úgynevezett web 2
30
-es technikák egy kis részét belecsempészni az alkalmazásba. Egyre inkább elterjedt ilyen technológia az AJAX. Ennek segítségével egy dinamikus keresőmodult építettem fel, amely igazán esztétikus és hasznos része lett a webáruháznak, nem is beszélve a mögötte álló „friss” technológia alkalmazásáról. Az AJAX egy webfejlesztési technika (Asynchronous JavaScript and XML), amelyet interaktív webalkalmazások létrehozására használnak. Ennek használata során a weblap viszonylag kevés adatot cserél a szerverrel, így annak nem kell az egész weblapot újratölteni, csak az éppen aktuális részt. Mivel ezzel a technikával egy keresőlistát készítettem, így itt is csak egy minimális adatmennyiség indul a szerver felé és onnan vissza. A technika kiválasztásával felhasználói élmény fokozása volt a célom. Az Ajax a következő technikák kombinációja: XHTML (vagy HTML) és CSS a tartalom leírására és formázására. DOM kliens oldali script nyelvekkel kezelve a dinamikus megjelenítés és a már megjelenített információ együttműködésének kialakítására. XMLHttpRequest objektum az adatok asszinkron kezelésére a kliens és a webszerver között. Néhány Ajax keretrendszer esetén és bizonyos helyzetekben IFrame-et használnak XMLHttpRequest objektum helyett. XML formátumot használnak legtöbbször az adattovábbításra a kliens és a szerver között, bár más formátumok is megfelelnek a célnak, mint a formázott HTML vagy a sima szöveg. A használat során az Ajax-os oldala viselkedése sokkal felhasználó közelibb, és dinamikusabb, mint ha egy desktop alkalmazást használnánk. Nem kell várni a teljes weboldal újratöltésére, éppen csak az aktuális blokk adatait várjuk a szervertől. Minden más változatlan marad, így csak a feltétlenül szükséges minimális adat fut keresztül a hálózaton. A technológia tényleges alkalmazásához letölthetünk úgynevezett Ajax Framework-öket , de akár meg is írhatjuk a működéséhez szükséges kódot. Saját tapasztalatszerzés céljára mind a két esetet kipróbáltam, de a mostani fejlesztés során a JQuery függvénygyűjteményt használtam, ami szintén egy ingyenesen hozzáférhető 31
javascript
könyvtár.
http://jquery.com/.
A
A
könyvtár
javascript
letölthető
könyvtárak
a
hivatalos
elsősorban
a
oldalról böngészők
inkompatibilitása miatt jöttek létre. Saját jscript tapasztalataim során sok bosszúságot és fejtörést okozott, hogy hogyan is oldjam meg a fenti problémát. A hosszadalmas kódok és elkerülő technikák helyett én is a fenti megoldást, egy sokkal tisztább és rugalmasabb rendszert választottam. Így biztosítva van a jscript kódok működése platformtól függetlenül. Az XMLHTTPrequest kezelés szintén fontos része az Ajax-nak, amit a fenti kis alkalmazás remekül elvégez. Segítségével egy perc alatt végrehajthattam asszinkron adatátvitel. Lehetőség van az adatok GET illetve POST formában való küldésére és a szervertől a választ XML vagy TEXT formátumba kaphatjuk vissza.
Példa a JQuery Ajax támogatására (GET):
url: a betöltendő oldal címét paraméterek: a szerver felé küldendő paramétereket callback: ez egy függvény, ami végrehajtásra kerül, ha sikeresen betöltődtek a kért adatok
$.get("test.cgi", { name: "John", time: "2pm" }, function(data){ alert("Data Loaded: " + data); } );
Gyakorlatilag ilyen egyszerűen tudtam én is beültetni a saját kódomba az Ajax használatát színesítve ezzel a felhasználói élményt, és gazdagabbá téve a felsorakoztatott technológiák listáját nem is beszélve a tapasztalatokról.
32
5.2.
A rendszer logikai működése
A fejlesztés során ez volt az a rész, ahol igazán nagy mennyiségű tapasztalatra tettem szert. Itt tudtam igazán belelátni a programozási nyelv szintaktikai és logikai működésébe. A tervezés során elkészült dokumentáció felhasználásával már kialakult egy kép a program felépítéséről, működéséről. A kódolásra fordított idő lerövidülése is ennek volt köszönhető. Látványos volt a fejlődés a számomra a kezdeti bizonytalanságból, arra a pontra való eljutásig, amikor már tudatosan, a felépített rendszert ismerve tudtam a fejlesztést végezni.
A rendszer alapvetően egy úgynevezett keretprogramból áll, ami a teljes függvényhívást, adatkérést, fogadást vezérli, így biztosítottam, hogy mindig a megfelelő függvények kerüljenek meghívásra. Ez kiszámítható, stabil működést biztosít a program számára. A keretprogram felett osztályok találhatók, amelyek csoportokba gyűjtik az azonos területre specifikált függvényeket. Ezeket úgynevezett modul osztályok implementálják, és ezeken keresztül futnak át a kérések a felhasználótól. A felhasználó a template-en keresztül látja a kért információt, így jól elkülöníthetőek a különböző funkcionalitást ellátó kódok. Ennek köszönhetően egy jól átlátható rendszert tudtam alkotni, ahol könnyen nyomon követhető és kiszámítható a futási eredmény.
33
A működési folyamatot vázlatszerűen ábrázolja a csatolt kép:
A fejlesztés során létrehozott file-ok neveinél szerettem utalni annak tartalmára, a programban való szerepére. Így megkülönböztettem az osztályokat név.class.php, a template-ket név.tpl.php és az include file-okat is név.inc.php névvel. Így ránézésre látható, hogy milyen file-ról és körülbelül milyen tartalomról, funkcionalitásról lehet szó. 5.3. Osztályok A programban az objektum orientált szemléletnek megfelelően osztályokba fogtam össze azokat a tagváltozókat és tagfüggvényeket, amelyek azonos adatkörön hajtanak végre műveleteket. Így mindig pontosan tudható, hogy egy bizonyos feladat elvégzéséhez mely osztály implementálására és mely függvény meghívására van szükség. A tervezés során egy külön osztályt alkottam az adatbázissal való kapcsolattartásra. Ez a KAPCSOLAT osztály. A többi osztály ezen keresztül, mint egy kapcsolófelület kapnak elérést az adatbázis felé. Rajta keresztül küldhetnek kéréseket és fogadhatnak válaszokat. Ezzel a felülettel biztosítottam, hogy ne legyenek a programban behatárolhatatlan adatbázis műveletek. A kapcsolat felépítéséhez szükséges, kötelezően megadandó paramétereket egy külön file-ban helyeztem el, így biztosítva a kód hordozhatóságát és egyszerű kezelhetőségét (site.inc.php). define('DB_KISZOLGALO', 'localhost'); define('DB_FELHASZNALO', 'root'); define('DB_JELSZO', ''); define('DB_ADATBAZIS', 'Online_Shop_1_0');
34
Az osztályban két csoportra osztottam az adatbázis műveleteket. Az első csoport a lekérdezések, amelyek siker esetén egy eredménytömbbel térnek vissza és a futtatásokra, amelyek eredménye, hogy sikeres volt-e a lefutás vagy sem. A lekérdez függvény egy másik osztályt használ, ami ténylegesen segít feldolgozni az eredményhalmazt. A tervezés során már volt tapasztalatom a sorozatos adatbáziskérelmek és azok eredményeinek feldolgozásában. Jól tudtam, hogy milyen nehéz ezeket egymás után hatékonyan kezelni és kinyerni belőlük a szükséges információt. Ennek kezelésére született meg a lekérdezés osztály. (lekerdezes.class.php) Ebben egy iterátor segítségével végzem el az eredménytömb feldolgozását. Ez tulajdonképpen bizonyos műveletek ismétlését teszi lehetővé. A következő függvényekből áll: public function next() { $this->row = $this->getTomb(); $this->counter++; } public function valid() { return $this->row != false; } public function current() { return $this->row; } public function key() { return $this->counter; } public function rewind() { $this->futtat(); } A függvénynevekből már lehet következtetni azok funkcióira és az egész működésére is. Az iterátor használatával bármikor kezelni tudtam fennakadás nélkül az egymás után történt SQL lekérdezések eredményeit. Egységes
35
kezelésüknek köszönhetően sokkal gördülékenyebbé vált számomra a fejlesztés menete. Jellemzően két olyan osztály van, ami mind a két felületen a felhasználói és az adminisztrációs felületen is ugyanaz. Ez pedig a felhasználó és a termék osztály. Ezek csoportok is egyben. A termékosztályba helyeztem el az összes terméktáblákban manipulációt végző függvényt, míg a felhasználóosztályba a felhasználótáblákban műveletet végző függvények kaptak helyet. Mind a két osztály ugyanazt a felépítési elvet követi. Mivel a műveletek azonosak, csak céltáblák és a céladatok eltérőek, ezért azonos struktúra alapján építettem fel őket. Olyan alapvető folyamatokat végrehajtó függvényekből állnak, mint az adatok listázása (listaz) a termékek illetve felhasználók adatainak módosítása (modosit), az új adatok felvitele, regisztráció (regisztal) és a feleslegessé vált adatok törlése (torol). Mind a két osztály számára külső felületeket biztosítottam a bennük található tagváltozók és tagfüggvények elérésére, így elrejtettem a belső működéshez fontos adatokat a felhasználók elől. A tagváltozókat a get és a set függvények segítségével lehet lekérdezni, illetve azok értékeit beállítani. A fenti említett osztályokat a modul osztályok implementálják. A tervezés során ezeket az osztályokat bíztam meg a felhasználótól érkezett kérések fogadásával. Ide érkeznek az elküldött űrlapok adatai, itt történik a jogosultságok ellenőrzése. Azért nagyon fontosak a modul osztályok, mert a működés tényleges logikáját ezekbe az osztályokba építettem bele, ezek az osztályok végzik azt el. Itt ellenőrzöm, a $_SESSION[’felhasznalo_azon’] alapján, hogy van e belépett felhasználó a rendszerbe és itt ellenőrzöm, hogy az elküldött űrlapok minden kötelező adattal rendelkeznek-e, ami elő van írva. A felhasználó felé a tényleges felület kialakítását és a kért adatok kiíratását a template-ek végzik. Ezek HTML oldalak, amelyek az adatbázisban szereplő adatok alapján épülnek fel dinamikusan a modul osztályokkal közreműködve. Látható, hogy a működés során jól elkülöníthetőek lettek a PHP kódok a HTML kódoktól. Ennek egyik előnyét abban látom, hogy mindig pontosan meg tudom határozni, hogy milyen kódok végzik az
36
adathívásokat, és milyen kódokban kereshetem a megjelenítésért felelős tageket. 5.4. Adminisztrátori felület megvalósítása Az adminisztrátori felület volt az, amelyiket először elkészítettem. Ez a felület lehetővé teszi az adatbázisban található adatok manipulációját. Az oldalra való belépéshez, mivel itt meg kellett oldanom, hogy illetéktelenek ne lépjenek be, egy belépési form-ot készítettem. Ide egy felhasználói név és egy jelszó megadásával lehet belépni. Az ide tartozó jogosultsági adatokat az adminfelhasználók táblába tároltam el. A jelszó kódolva van MD5-ös algoritmussal. Alapvetően a rendszer ezen felületét egy felhasználósra terveztem, de ha szükséges egy egyszerű űrlappal és jogosultságkezeléssel lefejleszthető egy modul, amivel akár az adminfelhasználó tábla adatai is manipulálhatóak. Így nem lesz alap felhasználói név és jelszó megadva, ami a későbbi biztonság szempontjából egyébként fontos lehet az alkalmazásban. Külön menüpontok alatt érhetőek el a felhasználók és a termékek adatai. Ezeket az adatbázison keresztül lekért adatokat, a jobb átláthatóság miatt oldalszámozott formában jelenítem meg a felületen. Ehhez a MySQL egy megoldását használtam fel a LIMIT értéket. Az SQL lekérdezésben meg kellett adnom egy kezdeti értéket, hogy a lekérdezett adatok hányadik sorától olvasson és pontosan mennyi sort. Ezek után egy ciklussal és a teljes lekérdezés sorának összegével létrehoztam a linkeket mind számozott, mind előre, hátra lapozható formában. A felhasználók menüpont alatt az adott felhasználóhoz
tartozó
személyes
adatokra
a
következő
műveletek
megengedettek: az adatok módosítása, és a feleslegessé vált adatok törlése. Ezen a felületen nem megengedett az új felhasználó regisztrációja. A termékoldalon a regisztráció ad lehetőséget az új termékek felvitelére. Ezen kívül a felvitt adatokat tudom módosítani és törölni. A megjelenítést egy táblázatos formába beágyazott űrlapon keresztül érem el. A termékoldalon ahol dátumot kell megadni, ott megkönnyítettem a felvitelt egy felugró naptár alkalmazásával. Ezt
egy ingyenesen letölthető program, a datetimepicker
37
segítségével alakította ki. Ennek segítségével a felület kezelése is látványosabbá vált. 5.5. Felhasználói felület megvalósítása A felhasználói felület, azaz a webáruház működése jóval egyszerűbb, mint az adminisztrációs oldal esetén. Ugyanarra az alapra épül, de jóval kevesebb funkciót valósít meg. Így ezt a felületet gyorsabban és az előző felület technikáit és logikáit felhasználva hatékonyabban tudtam felépíteni. A működés alapja itt is az adatbázisból érkezett adatok táblázatos formában való megjelenítése, felhasználva az adminisztrációs oldalon használt lapozási formát. Az oldalon található termék kategóriák dinamikusan változnak annak függvényében, hogy az adminisztrátori felületen milyen termékmanipulációt hajt végre a rendszer gazdája. Ezt a dinamizmust vittem át a termékkereső felületre is. Ez egy Ajax technikát használó dinamikus listákból álló rendszer. Három listából áll, termék kategóriák, gyártók és típusok. A fejlesztés során ügyeltem arra, hogy a keresés során, a kiválasztott termék kategória alatt található gyártók jelenjenek csak meg a gyártók listában. Ezek után konkrét gyártót is választva már csak az arra a gyártóra jellemző termékek jelennek meg a típusok listában. Így le tudtam rövidíteni a felhasználó keresésre fordított időt. Az oldalon lehetőség van az új felhasználók regisztrációjára. Ez egy regisztrációs űrlap segítségével lehetséges. A vásárlás, postázás és a számlázáshoz szükséges adatokat itt lehet rögzíteni, ezért fontos ezek pontos megadása. Ezt nem bízom a felhasználóra, így bizonyos kritériumokat állítottam fel a kitöltéshez. Ezeket az úgynevezett kötelező mezőket a kliensoldalon ellenőrzöm első sorban javascript segítségével. Ezt úgy teszem meg, hogy amikor a felhasználó a regisztrál gombra kattint először egy javascript függvény hívódok meg, ami ellenőrzi a szükséges adatokat. Ha van olyan adat, ami nincs kitöltve, akkor arra felhívom a felhasználó figyelmét egy alert-et használva, illetve a hiányosan kitöltött sorok mellé css segítségével egy piros csillagot is teszek. Amennyiben az adatok helyesek PHP oldalon is ellenőrzöm a beérkezett adatokat. Ennek azért láttam szükség szerveroldalon
38
is, mert a felhasználó bármikor kikapcsolhatja böngészőjében a javascript futtatását,
így
iktatva
ki
az
elsődleges
ellenőrzési
rendszert.
A
termékvásárlásnál figyelnem kellett, hogy van e belépett felhasználó, ha nincs, nem engedélyezett a vásárlás. Ezt a $_SESSION[’felhasznalo_azon’] ellenőrzésével oldottam meg. Amennyiben van felhasználó azonosító megadva a session-ben, akkor továbblép a felület a pénztár oldalra, ha nincs, átlép a belépés oldalra. Abban az esetben, amennyiben volt belépett felhasználó a rendszer a pénztár oldalra lép. Itt táblázatokba foglaltan jelenítettem meg az adott felhasználó postázási és számlázási címét, valamit a rendelt_termékek alapján a vásárolni kívánt termékek listáját. Ide még terveztem egy utólagos ellenőrzést az adatok helyességét illetően. Amennyiben az adatok helyesek, el lehet fogadni a vásárlás üzleti feltételeit és magát a vásárlást is. Ebben az esetben a felhasználónak visszajelzést adok az oldalon a sikeres vásárlásról, és email útján tájékoztatom a vásárlásról és a további teendőkről. 6. Üzembe helyezés Az üzembe helyezés során az elkészült alkalmazást magába foglaló könyvtárakat az alkalmazás számára létrehozott webtárhelyen található mappákba másoltam. Ezek után ellenőriztem, a hivatkozások megfelelő beállítását. Amennyiben szükséges, a megfelelő aldomaineket be kell állítani. Mivel az általam tervezett alkalmazás két felületből áll, ezért egy aldomait is létre kellett hoznom az adminisztrációs felület számára. Ennek a felületnek a mappáit az aldomain számára létrehozott mappába helyeztem el. Az állományokat és könyvtárakat FTP-n keresztül másoltam fel a szolgáltató által megadott elérési adatok alapján. Erre a feladatra én a Total Commandert használtam. Mivel az alkalmazás a SESSION-ökre és azok kezelésre épül, figyelni kell a megfelelő session beállításokra az oldalon. Általában a C:\Temp file-ba
kerülnek
a
munkamenetek,
de
a
PHP
save_session_path()
függvényével megadható az a könyvtár, útvonal, ahová a rendszer elhelyezheti a munkamenet-állományokat.
39
Amint a file-ok a helyükre kerültek, létre kell hozni az adatbázist. Mindig üres adatbázist kapunk, amiben fel kell építeni az adatbázis tábláinak rendszerét, és ezekbe be kell inzertálni a kívánt adatokat. Ezt úgy tudtam a legkönnyebben megoldani, hogy a már elkészült adatbázisomat kiexportáltam egy sql kiterjesztésű állományba. Ez a file tartalmazza a teljes adatbázis felépítéséhez szükséges create és insert parancsokat és az ezekhez szükséges adatokat. Ezt azután nyugodtan le tudtam futtatni a kapott adatbázis kezelő felületen. Az esetek többségében a phpMyAdmin-ban. Ezek után az alkalmazáson belül található adatbázis kapcsolat paramétereit módosítani kell. Ezt két file-al oldottam meg, amelyek a site könyvtárban találhatóak, és az adatbázis csatlakozáshoz szükséges adatokat tartalmazza. Az egyik a localhost-os fejlesztéshez, a másik a szerveren való kommunikációhoz, így mind a két esetben kényelmesen tudtam fejleszteni és nem kellett a hálózat függvényében átírnom a kapcsolódáshoz szükséges adatokat. Amint mindezt beállítottam, a kapott URL-t begépelve a böngészőbe a létrehozott alkalmazás megtekinthető. Ezek után egy funkcionális teszteléssel győződtem meg arról, hogy az alkalmazás az üzembe helyezés után az elvárt módon működik-e. 7. Tesztelés Az élesbe helyezés előtt a tesztelés során bizonyosodtam meg arról, hogy az alkalmazás megfelelően működik-e. Mivel a fejlesztés során folyamatosan
teszteltem
a
létrehozott
függvényeket
és
logikákat
tesztadatokkal és azok eredményeinek ellenőrzésével, így ebbe a fázisban kerülve a fejlesztési projekt során a tényleges működésről már meg volt a szükséges visszaigazolásom, a korábbi tesztelési eredmények által. A tesztelés ebben a fázisban az élesre helyezett rendszer funkcionális tesztelését jelenti. Ez
az
alkalmazás
használhatóságában,
a
kívánt
lépések
megfelelő
eredménnyel történő végrehajtódásában merül ki. A funkcionális tesz során végigfuttatom a megjelent termékek listáját, a felületen található linkek végződéseit és azok hatásait figyelve. A teszt során olyan eseményeket generáltam, amik az éles helyzetben szintén előfordulhatnak majd, ilyen a
40
regisztráció, a vásárlás és a termékek közötti navigáció. Első körben ellenőriztem, hogy minden termék, ami az adatbázisban be van regisztrálva szerepel a felületen. Ezután egy próbaregisztrációt hajtottam végre, ellenőrizve a helyes működést. Itt szándékosan hagytam ki kötelező mezőket, hogy lássam, a rendszer erre adott figyelmeztető válaszát. Ezek után a belépést vizsgáltam helyes, és helytelen adatokkal. Itt az utóbbi esetben szintén külön figyelmeztetést kaptam a rendszertől a helytelen adatok miatt. Amint a próbafelhasználó minden szükséges adataival a rendelkezésemre állt a vásárlás következett, mint tesztelendő folyamat. Első körben a termékek kosárba gyűjtésének és onnan való eltávolításának folyamatát követtem figyelemmel. Ezek után a vásárlás funkciót teszteltem belépett felhasználó nélkül. A vásárlás linkre való kattintáskor a rendszer a belépés oldalra ugrott és ott kérte a belépéshez szükséges adatokat a vásárlás elindításához. Így látszott a helyes, elvárt működés az éles rendszeren is. Ezt követően a tényleges belépés után a bevásárlókosárban található termékek tényleges megvásárlásán volt a sor. A rendszer itt is az elvárt eredményt mutatta, azaz a pénztár oldalra ugrott, ahol a postázási adatok, a számlázási adatok és a megvásárolandó termékek együttes feltüntetése után befejezhető a vásárlás folyamata amennyiben az adatok helyesek. 8. Összefoglalás A szakdolgozat témája egy webes áruház működésének megtervezése és annak tényleges lefejlesztése volt. Ezt azért választottam, mert a mai világban egyre inkább támaszkodunk az internetre, a számítógépes hálózatokra, és a mindennapi tevékenységünk áthelyezésével egyre inkább előtérbe kerül az elektronikus kereskedelem. Egy webes áruház inkább a kis és középvállalatok, céges esetén lehet alternatíva, akik saját termékeiket akarják ilyen formán eladásra kínálni. Illetve azon kisebb cégeknek, akik mások által gyártott termékek árusításával akarnak foglalkozni, de nem tudnak, vagy nem akarnak raktárakat, üzlethelységeket bérelni, azok fenntartási procedúráival foglalkozni. Mivel egyre elterjedtebb ez a kereskedelmi forma ezért döntöttem
41
úgy, hogy ezt választom dolgozatom témájául. Az alkalmazás tényleges elkészítése előtt fontos meghatározni bizonyos célokat, felvázolni a leendő alkalmazás főbb működési elvárásait, az alkalmazás üzemeltetésére szánt technológiákat és azok működését. Így biztosan olyan terméket fogunk készíteni, ami megállja a helyét és megfelel a kívánt követelményeknek. Így a feladat specifikálása során felvázoltam a fontosabb pontokat, amivel foglakoznom kell a projekt megvalósítása során, mint az adatbázis tervezés, a felülettervezés, a használt technológia kiválasztása és a tényleges fejlesztés. Amint ezeket elkészítettem és a kódokból összeállt a működő alkalmazás azt üzembe kellett állítani. Amint az adott tárhely szolgáltató által biztosított területre felkerült az alkalmazás azt az élesbe állítás előtt is tesztelésnek kellett alávetni. Ez egy funkcionális teszt volt, amelynek során a lehetséges összes folyamatot végigjártam, ami egy webes áruház élete során bekövetkezhet. Amennyiben olyan eredményt kaptam, ami eltért az elvárttól akkor azt a kódban javítottam és ismét ellenőriztem. A végeredmény egy jól működő, az alapvető követelményeknek megfelelő webes áruház lett, amely felveszi a versenyt a jelenleg a weben található hasonló feladatot ellátó alkalmazásokkal. A teljes fejlesztés során rengeteg tapasztalatot szereztem a tervezés és a fejlesztés terén is. Megtanultam jól meghatározni a fejlesztés során elérendő célokat, jól megtervezni a részfeladatokat és így hatékony fejlesztői munkát végezni.
42
9. Felhasznált irodalom
1. Gál Tibor Webprogramozás Műegyetem Kiadó Budapest, 2004
2. Robert W. Sebesta A Word Wide Web programozása Panem Kiadó, Budapest, 2005
3. Peter Moulding PHP Fekete Könyv Perfact-Pro Kft. Budapest, 2002
4. Julie C. Meloni A PHP, a MySQL és az Apache használata Panem Kiadó, Budapest 2004
5. Virginia DeBolt HTML és CSS Webszerkesztés stílusosan Kispaku Kft, Budapest, 2005
6. Matt Zandstra Tanuljuk meg a PHP5 használatát 24 óra alatt. Kiskapu Kft, Budapest, 2005
7. JQuery http://jquery.com/ Dokumentáció
8. Wikipédia, Szabad felhasználású enciklopédia
43
9. Bookline éves beszámoló http://bookline.hu/istore/tempimgs/2006_eves_jelentes.pdf
10. Szonda Ipsos - Vásárlás és tájékozódás az interneten http://www.szondaipsos.hu/hu/ipsos/iarvasarlas
11. GKI Gazdaságkutató Zrt. www.gki.hu 10. Az elektronikus kereskedelmi portál elérhetősége
44
