Архів якісних рефератів

Знайти реферат за назвою:         Розширений пошук

Меню сайту

Головна сторінка » Інформатика, програмування

Розробка онлайн інтернет-магазину для торгівлі аудіо товарами (дипломна робота)

1. ОСНОВИ ПРОЕКТУВАННЯ СИСТЕМ ДЛЯ ТОРГІВЛІ ЧЕРЕЗ

ІНТЕРНЕТ

1.1. Основи електронної комерції та принципи Інтернет-торгівлі

В основі розвитку систем Інтернет-бізнесу лежить використання техно­логій і методів електронної комерції (е-соттегсе), що стають сьогодні най­важливішою ланкою в розвитку бізнесу. Електронна комерція заснована на структурі традиційної торгівлі, а використання електронних мереж додає їй гнучкість.

Датою зародження систем електронної торгівлі можна вважати 1993 рік, коли в результаті істотного зниження вартості і підвищення продуктивності апаратних і програмних засобів почалася масова експлуатація мережі Інтернет і одного з її основних ресурсів - Всесвітньої павутини (^Уогіа \¥іае ^еЬ). Виникла глобальна інформаційна структура стала основою для розвитку систем електронної торгівлі. Стимулом для впровадження систем електронної торгівлі з'явилася економія витрат при придбанні виробничих ресурсів.

Щодо термінології, то в американській традиції частіше використовується сполучення «електронна торгівля», у європейської -«електронна комерція». За сутністю обидва поняття можна вважати ідентичними. Зокрема, електронна торгівля - це новий спосіб організації, управління, і здійснення бізнес-угод з використанням комп'ютерів і комунікаційних мереж [13, с.22]; будь-яка форма бізнес-угоди, у якій сторони взаємодіють електронним способом, а не за допомогою фізичних операцій обміну чи прямого фізичного контакту .

За визначенням Всесвітньої торгової організації, під електронною торгівлею розуміється виробництво, реклама, продаж і поширення товарів за допомогою телекомунікаційних мереж [32, с.31].


 

Платформу електронної комерції складають телекомунікаційні мережі (з домінуючою роллю Інтернет), а надбудова охоплює системи електронних платежів, системи і технології забезпечення безпеки (мереж і транзакцій), рі­зні моделі споживчого і корпоративного ринку і т.п.

Основні сфери діяльності електронної комерції наступні [13, с.43 - 48]:

електронний маркетинг (Інтернет-маркетинг);

фінансування створення електронних магазинів, а також їхнє страхування;

комерційні операції, що включають у себе замовлення, одержання товару й оплату;

спільна розробка декількома компаніями нового продукту чи послуги;

організація розподіленого спільного виробництва продукції;

адміністрування бізнесу (податки, митниця, дозволи, концесії і т.д.);

транспортне обслуговування, техніка перевезень і способи постачання;

ведення бухгалтерського обліку;

розв'язання конфліктних ситуацій і спірних питань.

Індивідуальні інтерактивні каталоги, яки динамічно генеруються, з можливістю пошуку потрібної інформації є важливою частиною систем Інтернет-бізнесу й стають стандартним методом подання продукції. При цьому інтеграція цих каталогів з корпоративними системами дозволяє сьогодні персоніфікувати надавані на основі каталогів послуги й синтезувати нові види інформаційного обслуговування споживачів.

Наявність різних підходів у компаній до ведення корпоративних каталогів не дозволяє стандартизувати форму каталогів, тому використання електронних площадок посередників для збору й інтеграції інформації про продукцію (що має форму галузевих або міжгалузевих каталогів) дає можливість провадити порівняння й відбір продукції по яких-небудь ознаках. Використовуючи свою, оригінальну логіку побудови каталогів і форм подання даних, посередники за допомогою спеціальних програмних засобів (програм-агентів) можуть здійснювати збір даних про схожі продукти,


 

представляти їх у вигляді порівняльних таблиць, виробляти рекомендації, пропонувати послуги зі створення індивідуальних каталогів і т.п.

До основних елементів інфраструктури системи електронної комерції відносяться:

1) спеціальне програмне забезпечення;

2) система управління базами даних і додатками;

3) телекомунікації і зв'язок;

4) система, що забезпечує безпеку актів купівлі-продажу товарів,
послуг і результатів інтелектуальної діяльності;

5) юридичне, правове забезпечення;

6) віртуальна банківська система;

7) спеціальні платіжні системи;

8) автоматизоване складське господарство;

9) система доставки товарів і надання послуг;

10) фінансові інститути (брокерські й інші контори);

11) система оподатковування і митних тарифів;

12) служба маркетингу, що включає в себе банерну рекламу, відділ продажів, відділ дизайну ^еЬ-сторінок, \уеЬ-серверів, відділ ціноутворення.

Повний цикл електронної комерції можна умовно розбити на декілька процесів, що за Д.Коз'є [14, с.51 - 70] складається з п'яти систем:

1) доступ до інформації (дослідження ринку, пошук партнерів і т.д.);

2) замовлення (заявки, запити);

3) оплата (платіжні системи);

4) виконання замовлення (системи доставки товарів);

5) післяпродажне обслуговування і підтримка.

Доступ до інформації. Електронна комерція дозволяє ефективно сполучити два процеси: рекламу і маркетинг, тобто надання споживачам інформації і вивчення попиту. Наприклад, розміщення в системі Інтернет-бізнесу електронного каталогу компанії дозволяє не тільки знайомити споживачів із продукцією, але і збирати статистику запитів на ту чи іншу


 

продукцію, а також проводити опитування відвідувачів корпоративного сайту.

Оформлення замовлення. Оформлення електронного замовлення на товари і послуги через Інтернет-сайти на основі електронних форм заявок, а також прийом замовлень по електронній пошті з наступним розміщенням інформації про замовлення в базі даних компанії-постачальника сьогодні стає вже стандартом ведення бізнесу.

Оплата. У сьогоднішніх умовах зростаючої комерціалізації середовища Інтернет все більшу актуальність здобувають електронні платіжні системи, що дозволяють здійснювати ділові операції й транзакції через Інтернет, що робить електронні платіжні системи невід'ємним атрибутом систем Інтернет-бізнесу.

Здійснення платежів через Інтернет, по суті, являє собою електронну версію традиційних платіжних систем: готівки, чеків, кредитних карт та ін., з тією відмінністю, що весь процес від початку до кінця проходить у цифровій формі. Разом з тим «цифровізація» привела до появи й широкого поширення нових типів електронних платежів: за допомогою електронних чеків і цифрових грошей, які орієнтовані переважно на здійснення дрібних термінових електронних платежів за різні електронні сервіси, надання інформації та інші послуги, пов'язані з інтерактивною природою сучасного Інтернету.

Послуги електронних платіжних систем сьогодні адаптовані під будь-які термінальні користувальницькі пристрої: персональні комп'ютери, кишенькові комп'ютери (РБА - Регзопаї БІ£І1:а1 Аззізіапі;), мобільні телефони й т.п.

Виконання замовлення. Інтернет-сайти й електронна пошта є ефективними інструментами в забезпеченні процесу виконання замовлення і доставки товарів споживачу, тому що дозволяють оперативно повідомляти службам перевезення про необхідність доставити той чи інший товар, а також дізнаватися, що доставка відбулася. У випадку ж, якщо фірма торгує


 

інформаційною продукцією чи електронними даними (інформаційними бюлетенями, зведеннями новин, аналітичними звітами, біржовими котируваннями, програмним забезпеченням і т.п.), то тоді Інтернет стає основним засобом для передачі електронної продукції замовникам.

Післяпродажне обслуговування і підтримка. Сьогодні системи після­продажного обслуговування і підтримки обов'язково повинні бути доступні через Інтернет і містити технічні характеристики продукції, відповіді на пи­тання, що часто задаються, (РАСО, обновлені версії програм і „заплатки", а також доносити інформацію від споживачів відразу по декількох каналах, та­ким як телефон, факс, електронна пошта і \¥еЬ.

Технічна сторона електронної комерції. Для функціонування систем Інтернет-торгівлі необхідний хостинг із підтримкою тієї платформи, на якої він побудований. Тобто хостинг припускає:

- виділення постійного доменного і'мя (ІР адресу), за яким буде здійснюватися доступ до сайту;

- виділення певного вільного місця на сервері (для бази даних, програм­них скриптів тощо);

- достатню швидкість доступу;

- достатню кількість одночасного перебування користувачів;

- достатню ступінь захищеності;

- стабільність доступу у часі (цілодобово, без перерв, з мінімумом збоїв). Чим кращі характеристики має хостинг, тім більше він коштує, адже за кори­стування хостингом потрібно вносити абонплату. Кращі пропозиції мають ті сервіси, у яких максимальна швидкість доступу, необмежена чисельність одночасних відвідувачів, максимальна ступінь захищеності та більше вільного місця, а також є підтримка усіх відомих (популярних) платформ. Середня ціна платного хостингу коливається у границях від $5 до $40 на місяць. Ще одним варіантом запуску Інтернет-магазину є організація власно­го сервера з підключенням до провайдера Інтернет-послуг та встановлення на нього відповідного програмного забезпечення. У випадку застосування


 

операційної системи сімейства Ьіітих можна виключити витрати на її при­дбання, адже вона розповсюджується безкоштовно; у випадку застосування у якості платформи для Інтернет-магазину зв'язки, відмінної від РНР+Му8<ЗЬ (і подібних), до витрат треба додати вартість відповідної платформи. Власний сервер має такі переваги над хостингом:

- незалежність від хостера, який часто знаходиться за тисячі кілометрів;

- недоступність програмного коду для інших;

- більше вільного місця;

- встановлення за бажанням будь-якої платформи та програмного забез­печення;

- відсутність реклами тостера на сайті;

- сервер постійно знаходиться «під рукою» (у межах фізичної досяжності);

- крім магазину, на сервері можна організувати сайт, портал, форум, по­шту тощо;

- якщо окрім сервера існує локальна комп'ютерна мережа, то шляхом ор­ганізації проксі-сервера можна через нього підключити до Інтернету і всі комп'ютери цієї мережі.

Проте така організація має й певні недоліки:

- на адміністратора серверу покладається завдання його захисту;

- значні фінансові витрати на придбання і регулярні витрати на абонпла-ту та підтримку домена;

- проблема легального програмного забезпечення тощо.

1.2. Характеристика програмних засобів розробки онлайн-магазинів

На сьогодняшній час існує безліч інструментів для створення систем електронної торгівлі. Поступово нові конструктори сайтів, що навить не вимагають будь-якої квалифікації програміста від розроблювана, витісняють класичні методи програмування на традиційних мовах.


 

вимагають будь-якої квалифікації програміста від розроблювана, витісняють класичні методи програмування на традиційних мовах.

Розглянемо найбільш популярні серед них [22, с.25 - 44].

РНРЗпор (компанія РНР81юр 8ой\уаге) - це готове рішення для швидкого створення Інтернет-магазина, не потребуюче програмних доробок під конкретний проект, при цьому забезпечує достатню гнучкість, надає широкі можливості по настроюванню. Розглянемо доступні версії РНР8пор, що пропонуються на теперішній час.

РНР8пор 8їагі - система управління інтернет-магазином економ-класу. Сполучає у собі многофункциональность і прийнятну ціну ($130). Скрипт містить самі необхідні інструменти для створення інтернет-магазина. Зручне керування каталогом, візуальний редактор контента.

Основні можливості (РНР8Ьор усіх версій):

- повністю готовий до роботи скрипт інтернет-магазина;

- зручний инсталятор;

- робота з Му80Ь;

- визначення НТМЬ описів категорій;

- НТМЬ-опис продуктів;

- управління сортуванням товарів для кожної категорії; _- підтримка фільтрів для продуктів;

- фотографії продуктів, які можна завантажити в двох варіантах (зменшена і збільшена);

- указівка старої і поточної цін для товарів;

- указівка тимчасової відсутності товару на складі з можливість покупки під замовлення;

- перехресний маркетинг: товари, що рекомендуються, новинки, спецпропозиції, розпродажі;

- пошук по найменуванню, артикулу й опису продуктів у користувальницькій частині;

- 100% відкритий вихідний код (крім файлу з ліцензією);


 

- прокоментований вихідний код;

- Стабільна робота на платформах \¥іпсіо\уз, ІЖІХ, Ьіпих, РгееВ8Б, Мас08;

- дружній інтерфейс користувальницької частини;

- резервне копіювання бази з можливістю завантаження архіву;

- інструменти для синхронізації каталогу продукції;

- експорт продуктів у Яндекс.Маркет;

- експорт товарів у Рамблер-Покупки;

- інтуїтивна в керуванні панель адміністрування в стилі М8 \¥іпсіо\уз за технологією АІАХ (без перезавантаження сторінки);

- 3-х місячна безкоштовна технічна підтримка;

- безкоштовний доступ до відновлень протягом технічної підтримки.
РНР81іор Ешегргізе - професійна система керування інтернет-

магазином. Підтримка підключення до бази іншого інтернет-магазина, функції розмежування доступу, шаблонові макети дизайну, набір стандартних можливостей, у тому числі - публікація новин, каталог, гостьова книга й т.д., можливість використання зовнішніх модулів.

У версії Інтернет-Магазин РНР8пор Ешегргізе пропонується:

- автоматичне відновлення/відновлення із сервера за технологією РНР8пор ІІрсІаїе;

- завантаження характеристик через Ехсеї разом з товарами.

- вивантаження характеристик і їхніх значень із 1С:Підприємство;

- вивантаження зображень (до Зх) з ІС.Підприємство (8.0 і 8.1);

- вивантаження дерева каталогів з 1С:Підприємство;

- підтримка розміщення товару в різних каталогах;

- можливість завантаження більших прайс-аркушів (50000 і більше позицій за розкладом через Сгоп);

- Ріазії-Вивід тегів;

- підтримка браузера ІЕ 8;

- зміна провайдеру 8М8 повідомлень.


 

РНРЗЬор Са1а1о§ - професійна система керування інтернет-каталогом (вітриною) бізнес класу. Повна взаємодія інтернет-магазина з базою 1С. Вивантаження товарної бази з 1С у інтернет-каталог. Набір стандартних можливостей, у тому числі - публікація новин, статей, опитування, закриті сторінки для користувачів і ін. Орієнтована ціна - $210.

Інший розроблювач програмного забезпечення для інтернет-магазинів -компанія 080 - зробила ставку на тісну інтеграцію із продукцією «1С». Незважаючи на присутність у лінійці рішень і СМ8 для сайтів некомерційного профілю основні замовники 080 - таки підприємці, яким пропонується три варіанти програмного забезпечення залежно від масштабу бізнесу. У двох з них, Зіапсіагсі і Ргої" ($1000 і $4000 відповідно), використовується ядро \¥еЬ8пор, що дозволяє спростити керування магазином з обліковою системою (насамперед з «ЮПідприємством»).

Рішення 080 дозволяє:

1. Формувати товарну базу інтернет-магазина в режимі офф-лайн,
використовуючи програму 080 \¥еЬ8Ьор Мапа§ег, що є повноцінним
офісним додатком (таким як, наприклад, М8 ^/огд і М8 Ехсеї). З її
допомогою можна легко створювати об'ємні каталоги товарів зі складною
структурою і необмеженим числом характеристик кожного товару (кілька
графічних зображень, короткий і докладний описи, кілька цін у будь-який
валюті і багато інших параметрів). Якщо каталог поєднує різноманітний
асортимент товарів і ведеться, наприклад, у базі М8 Ехсеї, то є можливість
оперативно переносити дані в базу інтернет-магазина, використовуючи
автоматичні і конвертери, що набудовуються, дані програми 080 \УеЬ81юр
Мапа§ег.

2. Легко і вчасно обновляти асортимент інтернет-магазина,
експортуючи на сервер дані про товари.

3. Одержувати дані по кожному зареєстрованому клієнту, збирати й
обробляти інформацію про замовлення, що надійшли, відслідковувати і


 

змінювати стан замовлення, відправляти клієнту оповіщення про кожну зміну по електронній пошті.

4. Проводити гнучку цінову політику за рахунок створення різних схем
знижок для постійних і/чи оптових покупців.

5. Організувати просування визначених категорій товарів,
використовуючи маркетингові можливості системи спеціальних пропозицій.

6. Пропонувати клієнтам різні форми доставки й оплати товарів; забезпечувати безупинний зворотний зв'язок з користувачами і клієнтами за допомогою засобів керування модулями сайту 080 ^УеЬ8не - інформаційних розсилань, форуму, гостьової книги, опитувань, вікторин і т.д.

7. Автоматизувати партнерські взаємини (взаєморозрахунки, виплата винагороди партнеру і т.д.) за допомогою модуля "080: Партнерські програми"; викладати дані про товарний асортимент інтернет-магазина на найбільш великій і відвідуваній електронній торговій площадках - Япсіех-Маркет, Рамблер-Покупки, АВС-ціни за допомогою модуля "080 ХМЬ-конвертор". Для одержання більш повної інформації про товар користувачі по посиланню будуть переходити на сайт інтернет-магазина - це значно збільшить для приплив цільових відвідувачів.

Цікавий штрих - свої системи 080 не продає. Передбачається лише здача в оренду, причому щомісячні внески залежать від широти асортиментів магазина. Так, якщо на «полках» лежить менш трьох сотень товарних одиниць, власник магазина платить щомісяця по $75, менш тисячі - по $125, менш десяти тисяч - по $200. Звичайно, аутсорсинг додатків практикують і інші розроблювачі, але повний перехід на А8Р (Арріісагіоп 8егуісе Ргоуісііп§ -оренда програмних продуктів і потужностей сервера на основі щомісячних платежів з доступом до додатків через Інтернет або приватну віртуальну мережу) - поки рідкість.

Для власників інтернет-магазинів пропонується: - готовий до роботи інтернет-магазин;


 

- можливість використання готових шаблонів дизайну/модифікація ди­зайну;

- навички програмування для роботи з інтернет-магазином не потрібні;

- технологія АІАХ;

- робота з необмеженим числом типів валют;

- функція закриття магазина на технічне обслуговування;

- можливість допрацьовувати інтернет-магазин під потреби користувача;

- зручна система адміністрування;

- прогресивна платформа для розвитку інтернет магазина (Місгозой.МЕТ);

- безкоштовний доступ до майбутніх релізів;

- підтримка продукту (лінія консультацій, допомога в рішенні питань). Для розроблювачів пропонується:

- робота на платформі .КЕТ 3.5 (А8Р.1МЕТ, \¥іпс1о\уз Рогтз);

- шаблоновий дизайн на основі технології МазіегРа^ез, ЦзегСопІгоІз;

- робота під 1185/6;

- робота з 88Ь;

- підтримка бази даних М8 8(}Ь 8єгуєг 2005 / 2008 Ехргезз Ешгіопз \уіїЬ
Асіуапсесі 8єгуісєз;

- функціонал, розроблений на основі технології АіАХ;

- система генерації звітів на базі Місгозой Кероггіп^ 8егуісе;

- код, розроблений на основі принципів обьектно-ориентированного програмування;

- можливість доробки проекту;

- можливість додавання модулів.

Переваги платформи АсП/ап1;8пор.]\[ЕТ при створенні інтернет-магазина наступні. Якщо проект необхідно розвивати вже зараз, то можна взяти продукт, вибрати шаблон дизайну, заповнити його товаром і вже починати продавати. Звичайне виконання такого проекту може укластися в два робочих дні. Установка продукту на сервері здійснюється безкоштовно.


 

Масштабованість платформи. Платформа працює на різних засобах перегляду \¥ЕВ-сторінок, як у звичайному броузері, на мобільному телефоні або КПК.

Для доробки рішення програмісти можуть використовувати будь-яку зручну мову програмування, проблеми зв'язку вирішує платформа Місгозой.КЕТ. Тобто якщо хтось знає тільки одну мову програмування, це не поміщає йому внести доробки на сайт.

Платформа вже містить готові компоненти (робота з користувачами, замовленнями, платіжними системами), які можна використовувати для розвитку проекту. Дуже часто 90% програмного коду проекту становить код платформи АсІУапі8пор.КЕТ, інше можна доробити, самостійно, або силами фахівців. Це дозволяє заощаджувати гроші на розробці. Кількість компонентів росте, а самі вони постійно вдосконалюються.

Платформа Місгозой.КЕТ де-факто є стандартом для розробки складних проектів, де беруть участь кілька розроблювачів і необхідно вирішувати питання колективної розробки проекту. Це дозволяє використовувати продукт, як базис для розвитку проекту.

Продукт працює на професійної СУБД (система управління базами даних), що дозволяє зробити його безпечніше й стійкіше в роботі з більшим обсягом даних. Крім того, рішення підтримується й на Місгозой 8С>Ь 8егуег 2005 Ехргезз Есіігіоп (поширюється безкоштовно).

Продукт постійно розвивається й підтримується.

8пор-8сгірі - це програмне забезпечення (РНР-скрипти), за допомогою якого можливо швидко створити власний магазин чи каталог. Це лінійка продуктів для створення інтернет-магазинів різного масштабу - від невеликих інтернет-вітрин до великих електронних магазинів.

Переваги інтернет-магазина 8Ьор-8сгірі:

- цілком готовий до роботи скрипт інтернет-магазина;

- безкоштовна установка скриптов на сайт власника;

- безкоштовна цілодобова підтримка і доступ до відновлень скриптів;


 

- відкритий вихідний код (РНР/Му8С2Ь);

- проста інтеграція дизайну (у будь-якому НТМЬ редакторі);

- набір готових шаблонів дизайну;

- оптимізація для пошукових систем Яндекс, Рамблер, Ооо£Іе;

- інтеграція з основними електронними платіжними системами;

- обробка платежів по кредитних картах;

- розрахунок вартості доставки в реальному часі;

- повідомлення про замовлення по електронній пошті і 8М8;

- багатомовність інтерфейсу;

- проста локалізація магазина.

Скрипти магазина 8пор-8сгір1; надаються в цілком відкритих вихідних кодах, що дає повну волю в їхній зміні і доробці по вимогах замовника.

Ціна: від $140 до $200 у залежності від комплектації.

Власні розробки мають ряд об'єктивних переваг: наприклад, можливість реалізації своїх оригінальних ідей і задумів, обмежених лише професіоналізмом програмістів і бюджетом.

Потужні системи статистичного аналізу й зачатки СКМ (Сштотег Ке1агіоп8пір Мапа§етеп1; - загальна назва для клієнтоцентрованої бізнес-методології й класу корпоративних систем на її основі) у рамках стандартного продукту не створити. Серійні рішення такого рівня практично відсутні, тому що бажаючих придбати їх небагато. Тому «власноручний варіант» у цьому випадку - безальтернативний. Виникає скоріше зворотна ситуація: до унікальної системи купуються й інтегруються готові «запчастини» начебто шлюзів із платіжними системами або аналітичні модулі.

Іншими вірними прихильниками самостійної розробки залишаються е-комерсанти зі скромним бюджетом, для яких виділити $1000...2000 на покупку готового рішення - недозволенна розкіш. Звичайно вони й бізнесмени, і розроблювачі в одній особі.

Природно, від недоліків унікальні системи теж не вільні.


 

Найчастішими проблемами залишаються залежність від власних програмістів і висока щільність помилок, що виявляються, на одиницю часу. І зрозуміло, чимало сил і людино-годин прийде витратити на розробку. А оскільки часу завжди не вистачає, постійний тиск на програмістів не сприяє якості й стабільності роботи системи.

У підсумку найбільш прийнятним для бізнесмена «середньої руки», не схильного до експериментів, можна назвати готове рішення на базі однієї з добре зарекомендували себе СМ8. А для розроблювача краще реалізовувати такі проекти самостійно, користуючися безкоштовними звя'зками РНР+Му8дЬ, АЗР.ШТ, ХМЬ тощо.


 

2. РОЗРОБКА СТРУКТУРИ ЕЛЕКТРОННОГО МАГАЗИНУ

2.1. Архітектура електронного магазину

У модулі інтернет-магазина звичайно перебувають засоби для створення каталогу товарів, кошика покупця, оформлення замовлення й адміністративного розділу. Загальноприйнята наявність для кожної категорії товарів сторінки, що містить короткі анотації й предпросмотровьіе зображення для швидкого завантаження.

Термін «купівельний кошик» (зпорріп£ сагх) описує спеціальний онлайновий механізм здійснення покупок. У процесі перегляду деякого онлайнового каталогу товарів користувач може додавати у свій кошик окремі позиції (найменування товарів). По завершенні перегляду користувач проводить розрахунок з онлайновим магазином, тобто, по суті справи, купує товар, раніше поміщений ним у кошик.

Кожний елемент категорії повинен містити гіперпосилання для більше детального знайомства із предметом, що зацікавив, а убудований у систему пошук по каталозі повинен допомогти клієнтові швидко вийти на необхідний йому товар. Для цього, крім найменування й категорії, повинні використовуватися інші критерії пошуку - наприклад, часовий діапазон надходження, ціна, країна-виробник і т.д. Адже всі ми розуміємо: чим докладніше результати пошуку, тим вище шанс, що клієнт не піде без покупки.

Уміст кошика повинний змінюватися не тільки убік збільшення номенклатури, потрібно, щоб покупець міг вилучити звідти обраний раньїше товар і переглянути нову сумарну ціну покупок. Поточний уміст кошика повинний відображатися постійно, крім того, якщо користувач уже вибрав спосіб оплати й доставки, рекомендується показувати вартість покупок з урахуванням доставки, комісійних платіжних систем і т.п.


 

Інформація про покупця (за винятком тієї, що покладено знати тільки процессинговой компанії або платіжній системі) і замовлення заноситься в базу даних, причому тут спливає потреба ще в одному важливому компоненті модуля е-комерції - розділі історії замовлень, де користувачі можуть переглядати хронологію своїх покупок і статус угод. У свою чергу, інтерфейс адміністратора в торговельному модулі повинен дозволяти редагувати список замовлень для кожного покупця, змінювати їхні статуси, інформацію про доставку і її вартість, дані про доступні платіжні системи, типи платників (юридичне/фізична особа), знижки, податкові ставки, валютні курси й використовувані валюти.

Користувальницька частина системи відповідає за розмежування доступу до контенту для зареєстрованих користувачів з різним статусом. Реєстрація складається із двох етапів: заповнення відповідної форми на публічній частині сайту й підтвердження авторизації адміністратором.

Отже, існують два основних представлення системи: користувальницьке й адміністраторське. З урахуванням необхідних функціональних можливостей створені дві блок-схеми системи - по однієї для кожного представлення. Ці блок-схеми показані на рисунках 2.1 і 2.2.

На рисунку 2.1 показані головні посилання між сценаріями в тій частині сайту, що стосується користувача. Клієнт спочатку відкриває головну сторінку, у якій перераховані всі категорії моделей на сайті. Сценарій надає користувачу посилання, що дасть можливість додати обрану модель у кошик. На етапі роботи з кошиком можна зробити остаточний розрахунок і залишити магазин.

На рисунку 2.2 приведений інтерфейс адміністратора. Він містить більше число сценаріїв, але не особливо багато нового коду. Ці сценарії дозволяють адміністратору входити в систему і додавати нові моделі, бренди та категорії.


 

Рис. 2.1. Онлайн-магазин у представленні користувача

Рис. 2.2. Онлайн-магазин у представленні адміністратора


 

Розглянемо методи реалізації кожної з раніше перерахованих вимог.

Побудова онлайнового каталогу. Для збереження каталогу магазина створюється індивідуальна база даних.

Відстеження обираного товару. Існує два базових методи відстеження товарів, обираних відвідувачами. Один з них складається в периміщенні обираних елементів у базу даних, а другий - у використанні деякої перемінної сеансу.

Використання перемінної сеансу з метою відстеження обираних елементів у процесі переходів між сторінками набагато простіше в реалізації, оскільки не вимагає постійних запитів до бази даних. Крім того, цей метод дозволяє уникнути захаращення бази даних непотрібними даними, що надходять від відвідувачів, що просто переглядають каталог і дуже часто змінюють свої рішення.

Таким чином, потрібно розробити перемінну сеансу, чи можливо, набір перемінних для збереження обраних користувачем елементів. Коли користувач завершує відвідування магазина і виконує остаточний розрахунок, ця інформація переміщається в базу даних як запис, що реєструє транзакцію.

Крім того, ці дані можуть використовуватися для відображення в куті сторінки поточного стану кошика, щоб відвідувач у будь-який момент міг бачити майбутню суму витрат.

Здійснення платежу. Щоб налагодити механізми безготівкового розрахунку, магазину потрібно скористатися послугами процессинговьіх компаній або встановити шлюзи до окремих електронних платіжних систем прямо. Після цього покупець буде повідомляти свої особисті фінансові дані не магазину, а серверу процессинговой компанії, що, одержавши від магазина дані про угоду, зв'язується із платіжною системою або банком покупця й знімає необхідну суму, і після відрахування комісійних вона надходить на рахунок магазина.

У цьому проекті додаємо тільки механізм прийому замовлення від


 

відвідувача і відомостей, що стосується доставки. Реальна обробка платежів тут не виконується. Існує велика розмаїтість платіжних систем, при цьому для кожної з них характерна власна реалізація. Напишемо фіктивну функцію, которую згодом можна буде замінити інтерфейсом будь-якої обраної платіжної системи.

Платіжній системі необхідна інформація про клієнта (наприклад, номер кредитної картки), ідентифікуюча інформація від власника магазина (щоб вказати, який торговий рахунок буде кредитуватися), а також загальна сума транзакції.

Суму замовлення можна витягти з перемінної сеансу. купівельного кошика. Остаточна інформація з замовлення буде занесена в базу даних, а перемінна сеансу після цього буде вилучена.

Інтерфейс адміністрування. Крім усього сказаного вище, передбачимо інтерфейс адміністрування, що дозволяє додавати, видаляти і редагувати інформацію по моделях, брендах і категоріях у базі даних.

Одним з часто використовуваних елементів редагування є зміна ціни товару (наприклад, для спеціальних пропозицій чи продажів зі знижкою). Це означає, що збереження замовлення клієнта передбачає і збереження ціни, яка повинна бути заплачена за товар. Якщо записи відбивають лише позиції, замовлені кожним клієнтом, і поточну ціну кожного найменування, це істотно ускладнює систему бухгалтерського обліку. Крім того, це означає, що коли клієнт повертає або обмінює товар, можливо, йому будуть повертатися зайві кошти якщо, наприклад, він здобував щось під час акції і потім по якийсь заподії відмовився від покупки. У даному проекті не ставиться за мету створювання повноцінного інтерфейсу відстеження замовлень і реалізації.

Найпростіший спосіб реалізувати редагування та видалення моделей, брендів і категорій полягає в тому, щоб відобразити для адміністратора дещо відмінну версію інтерфейсу користувача сайту. Адміністратор як і раніше буде мати можливість переглядати категорії, моделі і бренди, але замість


 

доступу до купівельного кошика він може переходити до визначеної моделі чи категорії, а потім редагувати чи видаляти її. Розробка сценаріїв, одночасно придатних як для звичайних користувачів, так і для адміністраторів, дозволяє заощадити час і трудовитрати.

2.2. Розробка бази даних та структури проекту

Трьома основними модулями коду для даного додатка є:

- каталог;

- купівельний кошик і обробка замовлення

- адміністрування.

Доцільно об'єднати фрагменти коду, що відповідають за включення НТМЬ-вмісту, в одну бібліотеку. Це повинно цілком відповідати принципу поділу логіки і вмісту і, що ще важливіше, такий підхід спростить читання і супровід коду.

8С>Ь-код створення бази даних аигозошісі приведений у додатку А.

Для того щоб створити в системі базу даних, у середовищі Му8(Д. буде потрібно виконати сценарій аигозошкі^І, володіючи правами привілейованого користувача (гооі):

глузді -и гоог: -р < аигозошісі. зді

Далі буде потрібно ввести пароль привілейованого користувача. До цього моменту необхідно змінити пароль користувача аитзошкі на що-небудь, відмінне від 'раззлуогсГ (установлюється за замовчуванням).


 

З. ІНТЕРФЕЙС І ПРОГРАМНА РЕАЛІЗАЦІЯ ІНТЕРНЕТ-МАГАЗИНУ 3.1. Розробка онлайн-каталогу

Розроблювальний додаток містить три сценарії, зв'язаних з каталогами: головна сторінка, сторінка категорій і сторінка інформації про модель (товарі).

Титульна сторінка сайту генерується сценарієм іпдех.рпр. Виведення цього сценарію можна бачити на рисунку 3.1. Нескладно помітити, що крім списку категорій вікно містить посилання на купівельний кошик (у правому верхньому куті) і підсумкові дані по умісту кошика. Ці елементи містяться на кожній сторінці, що відкривається в процесі перегляду і вибору товару.

Рис. 3.1. Титульна сторінка


 

Як тільки користувач виконує щиглика на одній з категорій,

відкривається сторінка категорій, що генерується сценарієм зпо\у_саір1ір.

Наприклад, на рисунку 3.2 показана сторінка категорій для моделей СБ-
ресіверів.

Рис. 3.2. Кожна модель категорії супроводжується зображенням

Усі моделі категорії СБ-ресіверів представлені у виді списку посилань. Коли користувач виконує щиглика на одному з посилань, відкривається сторінка з інформацією про відповідну модель, що показана на рисунку 3.3.


 

Рис. 3.3. З кожною моделлю зв'язана сторінка інформації, що містить опис

На цій сторінці, крім посилання "Перегляд кошика", знаходиться посилання "Додати у кошик", що дозволяє вибирати товар.

Розглянемо кожний із трьох сценаріїв.

Список категорій. Перший сценарій, іпдех.рпр, виводить список усіх категорій з бази даних:

Сценарій починається з включення файлу аиІ080шісї_8с_пі8.рпр, що містить усі бібліотеки функцій для даного додатка.

Після цього буде потрібно запустити сеанс, що необхідний для коректного функціонування купівельного кошика. Сеанс використовується кожною сторінкою сайту.

Сценарій включає виклики функцій виведення НТМЬ-вмісту, таких як код яких знаходиться у файлі

Крім того, передбачимо код для перевірки ситуації, коли користувач входить у систему з правами адміністратора. У цьому випадку такому користувачу надаються деякі інші засоби навігації.

Функція §еІ_са1:е£огіе8() повертає масив категорій, що існують у системі, що потім передається уфункцію сіІ8р1ау_са1;е§огіе8(). Код функції §еІ_са1е§огіе8() з бібліотеки оиіриігпз.рЬр, що витягає з бази даних список категорій, показаний нижче:

Як можна бачити, функція здійснює з'єднання з базою даних і потім витягає список, що включає всі ідентифікатори й імена категорій. Тут використовується раніше написана функція сю_ге8и1і_іо_аггау() з бібліотеки сІЬгш.рпр. Ця функція, код якої приведений нижче, приймає ідентифікатор результату від Му8(^Ь і повертає масив рядків з числовою індексацією, де кожен рядок являє собою асоціативний масив:

У нашому випадку цей масив повертається в сценарій іпаех.рпр, де, у свою чергу, передається у функцію Ш8р1ау_са1е§огіе8() з бібліотеки оШриігпз.рпр. Ця функція відображає кожну категорію у виді посилання на сторінку, що містить моделі даної категорії. Код функції показаний у наступному листінгу:

Функція дІ8р1ау_са1;е£огіе8() перетворює кожну категорію бази даних у посилання. Усі посилання передаються в наступний сценарій, 8по\¥_саірпр, при цьому кожна з них має власний параметр - ідентифікатор категорії БеуісеТуре. Це унікальне число, що згенероване Му8С£Ц що застосовується для ідентифікації категорії.

Згаданий параметр визначає, яка категорія повинна в кінцевому рахунку відображатися.

Видача списку моделей, що належать категорії. Процес виведення списку моделей, що належать визначеної категорії, аналогічний розглянутому вище. Виведення здійснює сценарій 8по\у_са1.рпр, що показаний у листінгу:

Структура цього сценарію багато в чому подібна структурі сценарію виведення титульної сторінки, з тією лише різницею, що замість категорій витягаються моделі.

Спочатку, як звичайно, запускається сеанс за допомогою функції 5Є88Іоп_8І;аг(;(), а потім з використанням функції §еІ_са1:е§огу_пате() переданий ідентифікатор категорії перетворюється в ім'я категорії:

$пате = де1:_са"Ьедогу_пате ($^еVІсеТуре) ;

Ця функція виконує пошук імені категорії в базі даних. Код функції приведений нижче:

Після витягу імені категорії ми можемо вивести НТМЬ-заголовок і перейти до витягу з бази даних списку моделей, що відносяться до обраної категорії:

Функції §еі_Ьоок8() і о!І8р1ау_Ьоок5() багато в чому подібні функціям ееі_саїе£огіе8() і сіізрІаусаІе^огіевО, тому вони тут детально не розглядаються. Єдина відмінність полягає в тому, що інформація витягається з таблиці моделей, а не таблиці категорій.

Функція дІ8р1ау_тоаеІ8() створює посилання на кожну модель даної категорії з використанням сценарію 8Ію\у_тосІе1.рпр. І знову, кожне посилання супроводжується параметром у виді суфікса. Цього разу він являє собою унікальний ідентифікатор (МосІеІСоае) конкретної моделі.

У заключному фрагменті сценарію 8по\у_саірпр міститься код для відображення додаткових функціональних можливостей у випадку, коли в систему входить адміністратор.

Виведення інформації про конкретну модель. Сценарій 8По\¥_тоае1.рпр приймає номер МодеІСосІе як параметр, а потім витягає і відображає детальні відомості про дану модель. Код цього сценарію приведений у наступному листінгу:


 

Цей сценарій також дуже схожий на сценарії виведення двох раніше розглянутих сторінок. Спочатку, як завжди, запускається сеанс, а потім за допомогою рядка:

з бази даних витягається інформація про модель. Для висновку даних у НТМЬ-форматі використовується наступний виклик:

Слід також зазначити, що функція о1І8р1ау_тоа!е1_а!е1:аіІ5() виконує пошук файлу зображення для моделі, ім'я якої виглядає якЬпа§е8/$МосІеІСобІе.Ір&. Якщо такий файл не існує, зображення не виводиться.

Частина сценарію, що залишилася, установлює засоби навігації. Звичайному користувачу надається кнопка "Продовжити покупки", що повертає на сторінку категорій, і кнопка "Додати у кошик" для додавання моделі в купівельний кошик. Якщо користувач, що ввійшов у систему, має права адміністратора, йому пропонуються дещо інші опції.

На цьому огляд системи видачі каталогів можна вважати завершеним. Тепер перейдемо до коду, що реалізує функціональність купівельного кошика.

3.2. Розробка купівельного кошика

Функціональність купівельного кошика тісно зв'язана з перемінної сеансу сагі Вона являє собою асоціативний масив, у якому ключами служать коди МодеІСосІе моделей, а значеннями - замовлена кількість моделей. Наприклад, якщо у кошику міститься один екземпляр даної моделі, у масиві з'являється наступний запис: 42 => 1

Приведений запис означає один екземпляр моделі з кодом МодеІСосІе 42. Коли моделі поміщаються у кошик, у масив додаються елементи подібного роду. Під час перегляду умісту кошика будемо використовувати масив сагі для пошуку в базі даних повної інформації з моделей.

Крім того, використовуються ще два перемінних сеанси для керування відображенням у заголовку даних по кількості елементів (Усього товарів) і сумі замовлення (Сума покупок) - відповідно, іїетз і ІоІа1_ргісе.

Використання сценарію 8Ію\у_сагІ:.рпр. Огляд реалізації купівельного кошика почнемо зі сценарію 8по\¥_сагІ. рпр. Він виводить сторінку, що відкривається після щиглика на посиланнях "Перегляд кошика" або "Додати в кошик". Якщо сценарій впо^сагі.рпр викликається без параметрів, відображається просто уміст кошика. Якщо як параметр передається який-


 

небудь код МосіеІСосіе, модель, що відповідає цьому номеру МосіеІСосіе, додається у кошик.

Спочатку розглянемо рисунок 3.4.

Рис.3.4. Сценарій зпо\¥_саг1:.рпр, викликаний без параметрів, просто виводить уміст кошика

У даному випадку користувач виконав щиглика на посиланні "Перегляд кошика", коли кошик був ще порожній. Іншими словами, не обрана ще жодна позиція для покупки.

На рисунку 3.5 показаний кошик у трохи більш довгому стані, коли для покупки обрані дві моделі. У даному випадку користувач потрапив на цю сторінку в результаті щиглика на посиланні "Додати в кошик" у межах сторінки, що була згенерована сценарієм 8ПО\у_тосІе1.рЬр для моделі АЬРШЕ СБА-9884К. Якщо уважно подивитися на рядок адреси в броузері, можна помітити, що цього разу сценарій викликається з параметром. Параметр називається пеш і має значення 42, тобто номер МосіеІСосіе моделі, тільки що поміщеної у візок.


 

Рис. 3.5. Сценарій зпо\у_саг1;.рпр, викликаний з параметром пе\у, поміщає у кошик новий елемент

На цій сторінці присутні дві додаткові опції. Першу з них, кнопку "Зберегти зміни", можна використовувати для зміни кількості елементів у візку. Для цього варто безпосередньо змінити кількість екземплярів у полях кількості і клацнути на кнопці "Зберегти зміни". По суті справи, це кнопка відправлення форми, що забезпечує повернення в сценарій зпош_саг1.р]ір з метою відновлення умісту кошика.

Друга опція, кнопка "Розрахунок", вибирається відвідувачем для того, щоб залишити магазин.

Розглянемо код сценарію зпо\у_сагі.рпр, що показаний нижче:

 

 


Цей сценарій складається з трьох основних частин: виведення умісту кошика, додавання в неї елементів і збереження змін.

Виведення умісту кошика. Уміст кошика повинен відображатися поза залежністю від сторінки, на якій був зроблений щиглик на посиланні "Перегляд кошика". У загальному випадку, як тільки відвідувач клацне на посиланні "Перегляд кошика", єдиною порцією коду, що виконується, буде наступна:

З коду видно, що якщо кошик не порожній, викликається функція <1І8р1ау_саг1;(). Якщо ж кошик порожній, просто виводимо відвідувачу відповідне повідомлення.

Функція сіІ8р1ау_саг1;()лише виводить уміст кошика в читабельному НТМЬ-форматі, як показано на рисунках 3.4 і 3.5. Код функції міститься в бібліотеці оиІрш_пі8.рпр і заслуговує окремого розгляду.

 

 


Розглянемо базові алгоритмічні конструкції, що реалізує дана функція:

1. Циклічний обхід кожного елемента візка і передача його номера МосІеІСосІе у функцію £ЄІ:_тосІе1_сІе1;аіІ8(), що дозволяє одержати підсумкову інформацію по кожній моделі.

2. Для кожної моделі виводиться зображення, якщо воно існує. Тут за допомогою НТМЬ-дескрипторів висоти і ширини зображення небагато зменшується в розмірах. У результаті зображення злегка спотворюються, однак вони досить малі, щоб це не особливо кидалося в око і створювало проблеми.

3. Перетворення кожного запису кошика в посилання на відповідну
модель, тобто на виклик сценарію зпо^ушоаеі.рпр з передачею йому як
параметр номера МосІеІСосІе.

4. Якщо функція викликається, коли параметр $спап§е одержує
значення ггае (або взагалі не одержує значення, тому що Ігае приймається за
замовчуванням), для представлення замовленої чисельності виводяться
текстові поля введення. Разом вони утворюють форму, в яку входить також і
кнопка "Зберегти зміни". Слід зазначити, що при повторному виклику
функції Ш8р1ау_саг1() після здійснення остаточного розрахунку не можна
допустити, щоб користувач зміг ще раз змінити своє замовлення.

Ця функція не містить нічого особливо складного, проте, виконує безліч операцій. Саме тому варто дуже уважно вивчити її код.

Додавання елементів у кошик. Коли користувач попадає на сторінку 8По\у.сагірпр у результаті щиглика на кнопці "Додати в кошик", перед виведенням умісту кошика необхідно виконати визначену підготовчу роботу. Зокрема, у кошик варто помістити відповідний елемент.

По-перше, якщо відвідувач поки ще нічого не поміщав у кошик, то


 

власне кошика і не існує, тому його необхідно створити:


 

 


 


Спочатку кошик порожній. По-друге, коли відомо, що кошик створений, у неї можна додати елемент:

Тут ми перевіряємо, чи не міститься даний товар у кошику. Якщо це так, кількість даного товару збільшується на одиницю, у противному випадку у кошик додається новий елемент.

По-третє, потрібно визначити загальну суму замовлення і кількість товарів у кошику. Для цього застосовуються функції са1си1а!;е_ргісе() і саІсшаїеиетвО:

Ці функції містяться в бібліотеці тоае1_йі8.рпр. їхній код приведений нижче.


 

Нескладно помітити, що функція са1си1аіе_ргісе() виконує пошук у базі дані ціни кожного елемента, поміщеного у кошик. Цей процес вимагає часу, тому, щоб не повторювати його частіше, ніж це необхідно, ціна (так само як і загальна кількість елементів) зберігаються в перемінних сеансу. Повторні обчислення виконуються тільки у випадках, коли уміст кошика змінюється.

Функція са1си1а1е_і1;ет8()простіше - вона лише підсумовує кількості всіх елементів кошика з метою одержання підсумкового значення.

Збереження змін умісту кошика. Коли сценарій 8по\у_саі1рпр викликається в результаті щиглика на кнопці "Зберегти зміни", характер процесу дещо змінюється. У даному випадку здійснюється передача форми. При уважному розгляді коду можна помітити, що кнопка "Зберегти зміни" є кнопкою відправлення форми. Ця форма містить сховану перемінну зауе. Якщо значення цієї перемінної встановлене, то відомо, що сценарій викликаний у результаті щиглика на кнопці "Зберегти зміни". Це означає, щокористувач міг змінити кількості елементів, і бажає зберегти ці зміни.

Якщо повернутися до тієї частини коду форми збереження змін, можна помітити, що текстові поля введення кількості одержують імена, що збігаються з номерами МосІеІСосІе, що вони представляють:

Тепер розглянемо ту частину сценарію, що відповідає за збереження змін:

Як видно, виконується перебір всіх елементів, збережених у кошику, і для кожного номера МосІеІСосІе перевіряється значення Р08Т-перемінної з таким же ім'ям. У цьому випадку Р08Т-перемінні - це поля раніше розглянутої форми збереження змін.

Якщо якесь поле встановлене рівним нулю, ми видаляємо відповідний елемент із кошика з використанням функції шізедО. У противному випадку уміст кошика обновляється значеннями полів форми:


 

Після відновлення умісту кошика повторно викликаються функції са1сша1:е_ргісе() і са1си1а1е_і1ет8() з метою визначення нових значень перемінних сеансу Іо{а1_ргісе і ііетз.

Друкування підсумкових даних у рядку заголовка. У рядку заголовка кожної сторінки сайту відображаються підсумкові дані по стану купівельного кошика. Це здійснюється за рахунок висновку значень перемінних сеансу Іоіаі^гісе і іїетз за допомогою функції сІоптіїпеасІегО.

Згадані перемінні реєструються, коли користувач уперше відвідує сторінку 8По\у_сагі.рЬр. Крім того, потрібно реалізувати логіку для випадків, коли користувач ще жодного разу не відкривав дану сторінку. Ця логіка також міститься у функції сІо_п1:т1_пеасІег():

Виконання остаточного розрахунку. Коли користувач клацає на кнопці переходу до остаточного розрахунку ("Розрахувати"), активізується сценарій спескоиі.рпр. Доступ до сторінки остаточного розрахунку і зв'язаним з нею сторінкам повинний здійснюватися через 88Ь-з'єднання, однак даний демонстраційний додаток цього не вимагає.

Зовнішній вигляд сторінки остаточного розрахунку показаний на рисунку 3.6.


 

Рис. 3.6. Сценарій сЬескоит.рпр приймає детальну інформацію про клієнта

Даний сценарій вимагає, щоб клієнт увів свою поштову адресу (а також адресу доставки, якщо вони відрізняються). Сценарій досить простий:

Якщо кошик порожній, про це виводиться відповідне повідомлення. У противному випадку відображається форма, показана на рисунку 3.6.

Коли користувач продовжує роботу в результаті щиглика на кнопці "Оплатити" у нижній частині форми, запускається сценарій ригспазе.рпр. На рисунку 3.7 показане виведення цього сценарію.


 

Рис. 3.7. Сценарій ригспазе.рпр обчислює остаточну суму замовлення і витрати на доставку, а також приймає дані, що стосуються платежу

У порівнянні з спескоиі.рпр цей сценарій небагато складніше. Його код представлений нижче:

Логіка сценарію проста: виконується перевірка, що клієнт заповнив усі поля форми, після чого в базі даних зберігається введена інформація шляхом виклику функції іп8еії_ога!ег(). Це нескладна функція, що вставляє відомості про клієнта в базу даних. її код приведений нижче:


 

Код функції достатньо довгий, оскільки потрібно виконати вставку даних про клієнта, замовлення, а також інформації про кожну модель, що купується.Потім визначаємо вартість доставки за адресою клієнта і виводимо її на екран за допомогою наступної рядка коду:

сИзр1ау_згіірріпд (са1си1а1:е_5Ііірріпд_со5І: () ) ;

Код обчислення вартості доставки, що оформлений у вигляді функції са1си1аІе_5Ь.ірріп§_со5І(), завжди повертає значення $5. У реальному сайті, що реалізує онлайнову торгівлю, буде потрібно надати клієнту вибір способу доставки, підрахувати витрати на доставку по різних адресах і відповідним чином обчислити вартість доставки.

Далі відображаємо форму для введення клієнтом даних про кредитну картку за допомогою функції сіїзр1ау_сагсІ_Гогт() з бібліотеки оиІриІ_гпз.рЬр.

Рис. 3.8. Транзакція успішно закінчена


Реалізація платежу. Як тільки клієнт виконає щиглика на кнопці "Оплатити", за допомогою сценарію ргосезз.рпр обробляються дані, що стосуються платежу. Результати успішної платіжної операції показані на рисунку 3.8.


 

Код сценарію ргосезз. рЬр представлений нижче:

Ключовий аспект сценарію укладений у наступних рядках коду:


 

Дані обробляються по кредитній картці, надані клієнтом, і у випадку, якщо усе завершується успішно, знищуємо сеанс клієнта.

У нашому спрощеному прикладі функція обробки даних кредитної картки просто повертає значення ипе. Якщо бути точніше, спочатку необхідно передбачити набір перевірок на допустимість (у тому числі, перевірку, чи не минув термін дії кредитної картки, а також коректність уведеного номера картки), і тільки потім переходити до власне здійснення платежу.

У реальному сайті буде потрібно прийняти рішення, який механізм транзакцій буде використовуватися. Існують наступні можливості:

укласти договір із провайдером грошових транзакцій. Тут мається безліч альтернатив, що залежать від регіону, у якому проживає власник магазину. Деякі провайдери пропонують послугу банківських операцій у реальному часі. Необхідність у таких операціях залежить від пропонованих сайтом послуг. Якщо передбачається постачання онлайнових служб, то, швидше за все, можливість здійснення банківських операцій у реальному часі знадобиться. У тому випадку, якщо забезпечується тільки продаж і доставка деяких товарів, це менш важливо. У будь-якому випадку, провайдери грошових транзакцій звільняють власника Інтернет-магазину від такої неприємної відповідальності за збереження номерів кредитних карток;


 

відправляти номера кредитних карток собі самому в зашифрованих повідомленнях електронної пошти, наприклад, з використанням РОР чи ОРО. Після одержання і дешифрації таких повідомлень транзакції можна обробляти вручну;

зберігати номера кредитних карток у своїй базі даних. Настійно не рекомендується прибігати до цього методу, якщо не має впевненості, що належним образом забезпечений найвищий ступінь захищеності своєї системи.

3.3. Розробка інтерфейсу адміністратора

Реалізований у цьому проекті інтерфейс адміністрування досить простий. Він зводиться до розробки \¥еЬ-інтерфейсу взаємодії з базою даних, у якому застосовується вхідна аутентифікація..

Рис. 3.9. Для доступу до функцій адміністрування користувач повинний пройти через сторінку входу в систему


Інтерфейс адміністрування вимагає, щоб користувач ввійшов у систему через сценарій 1о§іп.рЬр, що потім виводить меню адміністрування за допомогою сценарію асітіп.рпр. Сторінка входу в систему показана на рисунку 3.9.


 

Як виглядає меню адміністрування, показане на рисунку 3.10.

Рис. 3.10. Меню адміністрування дає доступ до набору функцій адміністрування

Код реалізації меню адміністрування приведений нижче.

Як тільки адміністратор досягає цієї крапки, він може змінювати свій пароль або виходити із системи. Ідентифікація користувача-адміністратора після входу в систему здійснюється через перемінну сеансу асітіпизег і функцію спеск_аа!тіп_шег(). Ця й інша функції, використовувані сценаріями адміністрування, містяться в бібліотеці адтіпйіз.рпр.

Коли адміністратору потрібно додати нову категорію чи модель,
викликається або сценарій іп8егі_са1:е£огу_кзгт.рпр, або сценарій
ішегі_тосіе1_&гт.рпр. Кожен сценарій надає адміністратору форму для
заповнення. Форми обробляються відповідними сценаріями

(Іп8ег1_саіе£0гу.р1ір і іп8Єгі_тос1е1.рпр), що перевіряють форму на предмет заповнення і зберігають нову інформацію в базі даних. Сценарії, зв'язані з додаванням моделі, ідентичні оскільки обидві пари сценаріїв відрізняються друг від друга лише незначно.

Виведення сценарію іп8егі_тосІе1_пшп.рпр показаний на рисунку 3.11.

Рис. 3.11. Ця форма дозволяє адміністратору додавати в онлайновий каталог нові моделі

Поле "Категорія" являє собою НТМЬ-елемент 8ЕЬЕСТ. Опції для цього елемента виходять у результаті виклику раніше розглянутої функції §еІ_саІЄ£огіез().

Після щиглика на кнопці "Додати модель" активізується сценарій ішегМтюсІеІ.рпр, код якого показаний у листінгу:

Цей сценарій звертається до функції ішегітосІеІО. Ця й інша функції, використовувані сценаріями адміністрування, містяться в бібліотеці адтіп_пі8.рпр.

Крім додавання нових категорій і моделей, користувач із правами адміністратора може редагувати і видаляти ці елементи. При реалізаціїзгаданих функціональних можливостей повторно використовується максимально можливий обсяг коду. Коли адміністратор виконує щиглика на посиланні "Перейти на основний сайт" у меню адміністрування, виводиться індекс категорій (за допомогою розглянутого раніше сценарію іпсіех.рпр). Після цього адміністратор може виконувати навігацію по сайту так само, як і рядовий відвідувач. При цьому задіються ті ж самі сценарії.

Однак з навігацією адміністратора зв'язані деякі відмінності. Для нього виводяться особливі, опції, зв'язані з тим, що зареєстровано перемінна сеансу асітіп_и8ег. Наприклад, на розглянутій раніше сторінці 8ПО\¥_тосІе1.рпр будуть помітні відмінності в меню опцій (рис. 3.12).

Рис. 3.12 Виведення сценарію 8ПОЛу_тосІе1.рпр для адміністратора відрізняється від такого для рядового відвідувача


 

На цій сторінці адміністратору надаються дві додаткові опції: "Змінити елемент" і "Меню адміністратора". Крім того, у правому верхньому куті замість посилання на купівельний візок знаходиться кнопка "Вихід" ("Ьо£ Оиі").Усе це реалізується в наступному фрагменті коду:

Якщо знову повернутися до сценарію 8по\у_саі.рпр, нескладно помітити, що в ньому також присутні дані опції. Коли адміністратор виконує щиглика на кнопці "Змінити елемент", запускається сценарій есІії_тосІе1_:Гогт.рпр. Виведення цього сценарію показаний на рисунку 3.13.

Фактично, це та ж форма, що раніше використовувалася для витягу даних зв'язаних з моделлю. У неї убудована можливість передачі й відображення існуючих зведень про модель. Те ж саме було виконано й у відношенні форми перегляду категорій.Все вищесказане відбито у листінгу:

 

 


Рис. 3.13. Сценарій ес1іІ_тосІе1_гогт.рпр дає адміністратору можливість редагувати інформацію про модель і видаляти модель

Якщо передається масив, що містить дані про модель, форма переводиться в режим редагування, а поля заповнюються існуючими даними:

При цьому використовується навіть інша кнопка відправлення форми. Фактично, у формі редагування їх дві - одна для відновлення інформації про модель, а друга - для видалення моделі цілком. З цими кнопками зв'язані виклики сценаріїв есШ;_гпосІе1.рпр і <іе1е1;е_тосІе1.рпр, що відповідним чином обновляють базу даних.

Версії розглянутих вище сценаріїв, зв'язані з категоріями, працюють в основному ідентично, за винятком одного моменту. Коли адміністратор намагається видалити категорію, цього не відбудеться, поки категорія містить моделі. Це перевіряється шляхом відправлення запиту до бази даних. У такому випадку мінімізується імовірність помилкового видалення. У нашій ситуації, якщо видалити категорію, що містить моделі, ці моделі стануть "висячими". Перехід до них буде неможливий, оскільки з даними моделями не зв'язана жодна категорія.





Реферат на тему: Розробка онлайн інтернет-магазину для торгівлі аудіо товарами (дипломна робота)


Схожі реферати



5ka.at.ua © 2010 - 2016. Всі права застережені. При використанні матеріалів активне посилання на сайт обов'язкове.    
.