Разработка веб-приложения для автоматизации заказа товаров через Интернет с использованием средств CGI-программирования

Выбор подходящего способа проектирования веб-приложения, его этапы и критерии. Разработка концептуальной схемы БД будущей системы. Программная реализация веб-приложения для заказа товаров через Интернет с использованием средств CGI-программирования.

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык русский
Дата добавления 07.08.2011
Размер файла 1,5 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

КУРСОВАЯ РАБОТА

Разработка веб-приложения для автоматизации заказа товаров через Интернет с использованием средств CGI-программирования

Введение

В последнее время в нашей стране наблюдаются очень быстрые темпы роста популярности сети Интернет и, соответственно, количества её пользователей. Скорость подключения к сети постоянно растёт, не только в крупных городах и областных центрах, но и даже в небольших населенных пунктах. Этому способствует позиция руководства России, особенно Президента РФ Дмитрия Медведева, у которого есть свой сайт (http://kremlin.ru/), блог (http://community.livejournal.com/blog_medvedev/) и даже видео-блог (http://blog.kremlin.ru/). Цитата из обращения Президента России в своем видео-блоге: «Вот, наверное, две эти задачи: первая - обеспечение равного доступа к интернету (причём, конечно, хорошего качества и по разумной для нашей страны цене), и вторая - информационное удобство для граждан, полноценное присутствие в нём власти, - я считаю ключевыми для нашего государства в этой сфере» Режим доступа: http://www.kremlin.ru/text/appears/2009/04/215336.shtml). Имеется в виду сфера информационных технологий.

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

Несмотря на то, что общая компьютерная грамотность населения постоянно повышается, создать свой сайт может далеко не каждый пользователь ПК. Причём, если речь идёт о простом сайте (например, так называемые «домашние странички»), то на данный момент создано много веб-сервисов (хостинг-компаний), предлагающих услуги такого характера. Любой пользователь может воспользоваться услугами подобных компаний и создать простой сайт. Это происходит в автоматическом режиме и в большинстве случаев бесплатно (поставщики таких услуг обычно размещают рекламу на страницах пользователей или используют другие способы привлечения денежных средств в свои проекты - дополнительные платные услуги для пользователей, контекстная реклама с учётом сферы интересов посетителей и т.д.).

Сайты такого уровня призваны решать круг наиболее простых задач - ведение интернет-дневников («блогов»), размещение коммерческой информации («сайты-визитки» небольших организаций).

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

Для того чтобы получить наиболее качественный и ожидаемый результат, заказчик должен сформулировать чёткое (насколько это возможно) техническое задание - список требований к разрабатываемой информационной системе (сайту) - и поддерживать постоянное взаимодействие с разработчиком, своевременно сообщая о новых идеях и требованиях.

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

Интернет-магазин (англ. online shop или e-shop) - интерактивный веб-сайт, рекламирующий товар или услугу, принимающий заказы на покупку, предлагающий пользователю выбор варианта расчета, способа получения заказа и выписывающий счет на оплату. В зависимости от типа предлагаемой продукции, объёмов продаж и качества создания сайта его характеристики и возможности могут сильно отличаться, но цель и задачи всех интернет-магазинов похожи - организация торговли с помощью заказов через интернет.

Целью выполнения данной курсовой работы является разработка веб-приложения для автоматизации заказа товаров через Интернет с использованием средств CGI-программирования. Задачи, поставленные в рамках работы:

выбор подходящего способа проектирования веб-приложения;

разработка концептуальной схемы БД будущей системы;

программная реализация веб-приложения.

1. Формулировка задачи и поиск путей решения

1.1 Постановка задачи

приложение интернет программирование веб

Разрабатываемое веб-приложение должно выполнять задачу автоматизации заказа товаров через Интернет с использованием средств CGI-программирования.

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

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

1.2 CGI-программирование

Common Gateway Interface - это спецификация обмена данными между прикладной программой, выполняемой по запросу пользователя, и HTTP-сервером, который данную программу запускает. CGI позволяет разрабатывать программы независимо от сервера, механизм передачи им управления и данных был унаследован от программирования в среде командной строки. Последнее резко сокращает трудозатраты на разработку приложений, так как не надо программировать интерфейс пользователя: его функции выполняют формы.

Все данные в рамках Web-технологии передаются по протоколу HTTР. Исключение составляет обмен с использованием программирования на Java или обмен из Plugin-приложений.

HTTP - это протокол прикладного уровня. Он ориентирован на модель обмена «клиент-сервер». Клиент и сервер обмениваются фрагментами данных, которые называются HTTP-сообщениями. Сообщения, отправляемые клиентом серверу, называют запросами, а сообщения, отправляемые сервером клиенту - откликами. Сообщение может состоять из двух частей: заголовка и тела. Тело от заголовка отделяется пустой строкой.

Заголовок содержит служебную информацию, необходимую для обработки тела сообщения или управления обменом. Заголовок состоит из директив заголовка, которые обычно записываются каждая на новой строке.

Тело сообщения не является обязательным, в отличие от заголовка сообщения. Оно может содержать текст, графику, аудио- или видеоинформацию.

CGI-скриптом называют программу, написанную на любом языке программирования или командном языке, которая осуществляет обмен данными с HTTP-сервером в соответствии со спецификацией Common Gateway Interface.

Различают два типа запросов к CGI-скриптам: по методу GET и по методу POST. В свою очередь, запросы по методу GET подразделяются на запросы по типам кодирования: isindex и form-urlencoded, а запросы по методу POST - multipart/form-data и form-urlencoded.

В запросах по методу GET данные от клиента передаются скрипту в переменной окружения QUERY_STRING. В запросах по методу POST данные от скрипта передаются в потоке стандартного ввода скрипта. При передаче через поток стандартного ввода в переменной окружения CONTENT_LENGTH указывается число передаваемых символов.

Запрос типа ISINDEX - это запрос вида:

http:// адрес_сайта/somthing-cgi/cgi-script? word1+word2+word3

Главным здесь является список слов после символа»?». Слова перечисляются через символ «+» и для кириллицы в шестнадцатеричные последовательности не кодируются. Последовательность слов после символа»?» будет размещена в переменной окружения QUERY_STRING.

Запрос типа form-urlencoded - это запрос вида:

http:// адрес_сайта/somthing-cgi/cgi-script? field=word1&field2=word2

Данные формы записываются в виде пар «имя_поля-значение», которые разделены символом «&».

Приведенный пример - это обращение к скрипту по методу GET. Все символы после»?» попадут в переменную окружения QUERY_STRING. При этом если в значениях полей появляется кириллица или специальные символы, то они заменяются шестнадцатиричным кодом символа, который следует за символом «%».

При обращении к скрипту по методу POST данные после символа»?» не будут размещаться в QUERY_STRING, а будут направлены в поток стандартного ввода скрипта. В этом случае количество символов в потоке стандартного ввода скрипта будет указано в переменной окружения CONTENT_LENGTH. При запросе типа multipart/form-data применяется составное тело HTTP-сообщения, которое представляет собой данные, введенные в форме, и данные присоединенного внешнего файла. Тело помещается в поток стандартного ввода скрипта, при этом к данным формы применяется кодирование как в form-urlencoded, а данные файла передаются как есть.

Скрипт может принять данные от сервера тремя способами:

l через переменные окружения;

l через аргументы командной строки;

l через поток стандартного ввода.

1.2.1 Переменные окружения

При вызове скрипта сервер выполняет системные вызовы fork и exec. При этом он создает среду выполнения скрипта, определяя ее переменные. В спецификации CGI определены 22 переменные окружения. При обращении к скрипту разными методами и из различных контекстов реальные значения принимают разные совокупности этих переменных. Например, при обращении по методу POST переменная QUERY_STRING не имеет значения, а по методу GET - имеет. Другой пример - переменная окружения HTTP_REFERER. При переходе по гипертекстовой ссылке она определена, а если перейти по значению поля location или через JavaScript-программу, то HTTP_REFERER определена не будет.

1.2.2 Аргументы командной строки

У CGI-скрипта может быть такой элемент операционного окружения как командная строка. Это не означает, что скрипт реально можно вызвать из командной строки через сервер. Тем не менее получить доступ к содержанию командной строки скрипта можно с помощью тех же функций, что и при вызове его из-под интерактивной оболочки. Аргументы командной строки появляются только в запросах типа ISINDEX.

1.2.3 Поток стандартного ввода

Ввод данных в скрипт через поток стандартного ввода осуществляется только при использовании метода доступа к ресурсу (скрипту) POST. При этом в переменную окружения CONTENT_LENGTH помещается число символов, которое необходимо считать из потока стандартного ввода скрипта, а в переменную окружения CONTENT_TYPE помещается тип кодирования данных, которые считываются из потока стандартного ввода.

1.2.4 Механизм генерации отклика скриптом

Существует только один способ вернуть данные серверу и, соответственно, браузеру пользователя - писать в поток стандартного вывода (STDOUT). При этом скрипт должен формировать HTTP-сообщение.

Сначала выводятся директивы HTTP-заголовка. В минимальном варианте это либо Content-type: text/html, либо Location: http:// адрес_сайта/.

В первом случае определяется тип тела HTTP-сообщения, а во втором осуществляется перенаправление запроса.

После заголовка генерируется отклик в виде тела HTTP-сообщения, которое должно быть отделено от заголовка пустой строкой.

1.3 Выбор платформы реализации

Языком реализации был выбран зарекомендовавший себя язык веб-программирования PHP (PHP: Hypertext Preprocessor). PHP представляет собой скриптовый язык, встраиваемый в код веб-страницы. Значительная часть его синтаксиса заимствована из языков C, Java и Perl, с уникальными специфическими особенностями. Цель этого языка заключается в том, чтобы позволить веб-разработчикам быстро писать динамически создаваемые страницы.

Однако, несмотря на мощные средства программирования, предоставляемые языком PHP, разработка относительно большого приложения занимает много времени. Кроме того, многие подпрограммы (такие как подключение и использование БД, работа с шаблонами и многие другие функции) уже реализованы авторитетными разработчиками и включены в многочисленные библиотеки. Нет никакой необходимости переписывать подобные подпрограммы заново, теряя при этом время и не исключая возможность допущения ошибок.

Поэтому в настоящее время получила широкое распространение практика использования фреймворков (framework) при разработке веб-приложений. Фреймворк - каркас программной системы (или подсистемы). Может включать вспомогательные программы, библиотеки кода, язык сценариев и другое ПО, облегчающее разработку и объединение разных компонентов большого программного проекта. Обычно объединение происходит за счёт использования единого API.

При выборе платформы для разрабатываемого веб-приложения учитывались следующие факторы:

надежность приложения;

скорость разработки;

возможная расширяемость системы.

Всем этим требованиям удовлетворяет фреймворк CakePHP Официальный сайт - http://cakephp.org/).

CakePHP - это программный каркас для создания веб-приложений, написанный на языке PHP и построенный на принципах открытого ПО. CakePHP реализует паттерн «Модель-Вид-Контроллер» (MVC), о котором следует сказать подробнее.

«Модель-представление-поведение» («Model-view-controller», MVC, «Модель-представление-контроллер») - архитектура программного обеспечения, в которой модель данных приложения, пользовательский интерфейс и управляющая логика разделены на три отдельных компонента, так, что модификация одного из компонентов оказывает минимальное воздействие на другие компоненты. На рисунке 1 представлена схема обработки MVC-запроса.

Рисунок 1 - Основной MVC-запрос

Шаблон MVC позволяет разделить данные, представление и обработку действий пользователя на три отдельных компонента:

Модель (Model). Модель предоставляет данные (обычно для View), а также реагирует на запросы (обычно от контроллера), изменяя свое состояние.

Представление (View). Отвечает за отображение информации (пользовательский интерфейс).

Поведение (Controller). Интерпретирует данные, введенные пользователем, и информирует модель и представление о необходимости соответствующей реакции.

Важно отметить, что как представление, так и поведение зависят от модели. Однако модель не зависит ни от представления, ни от поведения. Это одно из ключевых достоинств подобного разделения. Оно позволяет строить модель независимо от визуального представления, а также создавать несколько различных представлений для одной модели.

Все запросы от браузера посетителя к разрабатываему приложению отправляются методом POST.

1.4 Пользователи системы

Можно выделить два пользователей разрабатываемого приложения - администратор и посетитель.

Оба пользователя могут просматривать открытую информацию, размещённую на сайте.

Посетитель имеет возможность просмотра информации о товарах, добавления товаров в «корзину», оформления заказа и его передачу в платёжную систему.

Администратор обладает правами редактирования информации о товарах и обработки заказов. Поэтому вход в панель администрирования должен быть защищён паролем. Разделение администраторов на различные группы с разными уровнями прав не требуется.

Авторизация посетителей в текущей версии системы также не предусмотрена.

2. Проектирование системы

2.1 Концептуальная модель

На рисунке 2 представлена концептуальная схема базы данных для создаваемого веб-приложения физического уровня.

Рисунок 2 - Концептуальная схема на физическом уровне

Для каждой таблицы имеется первичный ключ - уникальный идентификатор записи. Поле «id» автоматически назначается платформой CakePHP при добавлении записи в таблицу базы данных. Все первичные ключи имеют целочисленный тип, что упрощает (снижает нагрузку на сервер) их поиск и идентификацию.

Также почти во всех таблицах есть атрибуты «created» и «modified» - дата создания и дата последнего изменения значения, соответственно. Значения этим полям также автоматически присваивает CakePHP при создании или модификации кортежей.

Таблица «product_types» содержит описания категорий продукции - название вида продукции (поле «name») и текстовое описание (поле «text»).

В таблице «products» хранятся описания товаров, поля таблицы содержат следующую информацию:

l type - вид продукции;

l code - артикул;

l title - название;

l main_image - главное изображение;

l text - описание товара;

l price - цена.

Таблица «images» предназначена для хранения информации об изображениях товаров.

В таблице «orders» содержатся записи о заказах, они описываются следующими полями:

l account - номер счёта покупателя в платёжной системе;

l address - адрес покупателя для доставки товара;

l total - общая сумма заказа;

l paid - дата оплаты заказа (если он оплачен);

l complete - дата отправки товаров по заказу (если она произошла).

2.2 Ограничения целостности

Ограничение целостности на уровне базы данных осуществляется следующими средствами:

l использование атомарных типов полей таблиц;

l использование автоматической генерации значения (auto increment) для первичных ключей (для всех таблиц это целочисленное поле id);

l запрет на сохранение null-значений для некоторых полей (параметр NOT NULL). Например, поля account, address, total таблицы orders не могут быть пустыми.

Более сложные правила ограничения целостности организуются на уровне платформы (CakePHP), используя механизм валидации, предусмотренный в моделях. Например, артикул товара не может быть пустым и должен быть уникальным. Правило валидации для такой проверки задается в модели «Товар» следующим образом:

var $validate = array (

'code' => array (

'codeRule-1' => array (

'rule' => 'notEmpty',

'message' => 'Артикул не должен быть пустым'

),

'codeRule-2' => array (

'rule' => 'isUnique',

'message' => 'Товар с таким артикулом уже есть в базе'

)

)

 /// Другие правила валидации

2.2 Логика диалога с пользователем

Отобразим логику созданного диалога с пользователями посредством транзитивных сетей. При таком подходе логика диалога представляется в виде направленного графа, где состояния системы - это вершины, а переходы между обозначенными состояниями - дуги. Дуги обозначают входные сигналы или обратную связь прикладного интерфейса. Снизу они именуются согласно действию, которое должна выполнить система при переходе в данное состояние при определенном входном сигнале, который записывается над дугами.

На рисунке 3 показана транзитивная сеть диалога разрабатываемого веб-приложения с посетителем сайта, который в упрощенном виде заключается в запросе посетителем определённых страниц сайта и отображением их информационной системой. Эта схема является общим случаем для любого веб-сайта.

Опишем возможные состояния, возникающие в процессе диалога сайта с посетителем:

S0 - ожидание запроса от посетителя;

S1 - финишное состояние.

Логику диалога с администратором изобразим с помощью транзитивной сети с подсетями, содержащими группированные по смыслу состояния. В данном случае, например, «Подсеть работы в администраторской панели» будет объединять все те состояния диалога, которые имеют место при выполнении администратором действий, доступных только после аутентификации. Такое представление диалога позволит во много раз уменьшить избыточную для понимания взаимодействия с пользователем детализацию. В результате на рисунке 5 показана транзитивная сеть для диалога системы с администратором в области аутентификации.

Раскроем логику «Подсети работы в администраторской панели» в виде обобщённого представления (рисунок 6). Будем иметь в виду, что все функции по редактированию (добавлению, изменению, удалению) информации в каждом из разделов аналогичны.

Несмотря на упрощение, данная транзитивная сеть показывает логику взаимодействия администратора с системой при выполнении действий по редактированию информации.

Опишем возможные состояния, возникающие в процессе диалога системы с администратором в «Подсети работы в администраторской панели»:

3. Программная реализация

3.1 Модели

Шаблон проектирования MVC разлагает приложение на 3 отдельных уровня: обработка данных (модель), интерфейс пользователя и логика, соответственно.

Можно сказать, что модель в терминологии CakePHP - это совокупность таблицы БД и широкий ряд функций по обработке информации, хранящейся в этой таблице.

Кроме того, в с помощью моделей можно организовать процесс валидации данных - проверки введённой информации на корректность по определённым правилам.

Файлы модели хранятся в директории \app\models\. Файлы модели представляют собой обычные PHP-файлы (как и все файлы, используемые в CakePHP), именуемые следующим образом: «название_модели.php». В каждом из таких файлов описан класс модели, который наследуется от абстрактного класса модели AppModel.

Приведём пример модели «Изображение» (Image.php).

class Image extends AppModel {

 // Валидация данных - имя файла не может быть пустым и должно быть уникальным

var $validate = array (

'filename' => array (

'filenameRule-1' => array (

'rule' => 'notEmpty',

'message' => 'Имя файла не должно быть пустым'

),

'filenameRule-2' => array (

'rule' => 'isUnique',

'message' => 'Файл с таким именем уже есть в базе'

)

)

);

 // При удалении записи об изображении из базы, также следует удалить файлы

 // этого изображения - оригинал и уменьшеную копию

function beforeDelete() {

$result = 0;

if (is_file ('img/products/big/'. $this->field ('Image.filename'))) {

if (unlink ('img/products/big/'. $this->field ('Image.filename'))) {

$result++;

}

}

if (is_file ('img/products/small/'. $this->field ('Image.filename'))) {

if (unlink ('img/products/small/'. $this->field ('Image.filename'))) {

$result++;

}

}

return $result;

}

}

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

Это очень удобный способ обеспечения целостности системы на уровне платформы разработки.

Также в моделях можно определять действия, которые будут происходить по определённым событиям. В нашем примере перед удалением записи из таблицы будет установлено имя файла (обращение к информации - Image.filename) удаляемой фотографии, после чего файл фотографии и файл её уменьшенной копии будут удалены.

Для демонстрации возможностей, которые предоставляет CakePHP для установления взаимодействия моделей, приведём ещё один фрагмент кода из модели «Товар» (product.php).

class Product extends AppModel {

var $hasMany = array (

'Image' => array (

'className' => 'Image',

'dependent' => true

)

);

}

В этом фрагменте мы устанавливаем отношение «один ко многим» между моделями «Товар» и «Изображение», ведь у каждого товара может быть много изображений. Для определения этой связи устанавливаем для сущности «Изображение» внешний ключ «product_id» (идентификатор продукта).

Ключ «dependent» указывает на то, что при удалении товара из базы будут удалены и все изображения, относящиеся к нему (а следовательно и файлы изображений).

3.2 Контроллеры

В контроллерах CakePHP находится логика приложения, происходит принятие решений, выполняется последовательность действий и вообще всё, что делает приложение.

Контроллер управляет запросами сервера. Он принимает вводимую пользователем информацию (запросы URL, формирует запросы POST и GET, и так далее), при необходимости применяет логику, активизирует модели там, где требуется обработка информации, и отправляет результаты через соответствующее представление.

Как правило, контроллер управляет логикой для одной модели, но при необходимости можно подключать любую модель системы. В контроллере может содержаться любое количество функций, называемых действиями. Обычно действие применяет логику и отображает представление. Все контроллеры, определяемые пользователями, должны расширять класс AppController. Файлы контроллеров расположены в директории \app\controllers\, они именуются следующим образом: «название_controller.php».

В качестве примера приведём фрагмент кода из контроллера «Товары» (products_controller.php).

var $uses = array ('Product', 'Image', 'ProductType', 'User');

var $components = array ('Auth', 'RequestHandler');

Сначала определяются модели, с которыми будет взаимодействовать данный контроллер и компоненты, которые он будет использовать. В нашем примере используются следующие модели:

l «Товар» - для получения информации о товарах,

l «Изображение» - для вывода изображений товаров,

l «ТипПродукта» - для отображения информации о категориях продуктов,

l «Пользователь» - для аутентификации администратора.

Также подключаются два компонента - «Auth», предназначенный для аутентификации администратора при входе в администраторскую панель и работе с ней, и «RequestHandler» - для работы с AJAX-запросами.

Также как и в случае с моделями можно использовать обратные вызовы-то есть совершать действия по определённому событию в системе. Например, при каждом запуске контроллера можно сделать проверку - производится ли попытка доступа к администраторской части функций. Если да, то производится проверка аутентификации пользователя. Также можно указать действия контроллера (разделы сайта), доступ которым разрешен без прохождения процедуры аутентификации:

function beforeFilter() {

parent:beforeFilter();

$this->Auth->allow ('category', 'info', 'search');

}

Также можно определять свои собственные функции, которые будут обрабатывать определённые запросы пользователей. Например, отображение страницы с описанием товара производится следующим образом: из модели «Товар» по запросу с указанием идентификатора («id») извлекается информация о товаре, текст сохраняется в переменную («product») для дальнейшего использования в представлении (о которых будет рассказано в следующем разделе), также проверяется наличие главного изображения товара, и, если оно установлено, то также сохраняется в переменную («product_image») для вывода изображения в представлении.

Также из базы данных извлекаются заголовки категорий продукции (для формирования навигационного меню в представлении).

Если при обращении к действию контроллера не был указан идентификатор товара («id»), то браузер пользователя перенаправляется на страницу с описанием категории товаров.

Описанное действие контроллера («info») осуществляется следующим программным кодом:

function info ($id = null) {

$this->set ('product_types', $this->ProductType->find('list'));

if (is_null($id)) {

$this->redirect (array ('controller' => 'products', 'action' => 'category'));

} else {

$product = $this->Product->findById($id);

$this->set ('product', $product);

if (! is_null ($product['Product'] ['main_image'])) {

$this->set ('product_image', $this->Image->findById ($product['Product'] ['main_image']));

}

}

}

3.3 Представления

Представление в первую очередь связано с форматированием информации для выдачи её пользователю. Представление - это любая часть или вся работа, связанная с интерфейсом пользователя, включая все шаблоны. Файлы представления CakePHP являются обычными файлами HTML с расширением «.ctp», вложенными в код PHP. Они располагаются в директории \app\views\название_контроллера\.

В конечном итоге, представление - это просто шаблон страницы. Обычно представление называется по действию, связанному с ним. Например, у действия «info» будет представление info.ctp.

Рассмотрим код этого файла подробнее.

<div id= «content»>

<? php

if (empty ($product['Product'] ['type'])) {

echo '<h2>Товары вне категорий</h2>';

} else {

echo '<h2>'. $product_types [$product['Product'] ['type']]. '</h2>';

}

if ($product['Product'] ['title']) {

echo '<h3>&laquo;'. $product['Product'] ['title']. '&raquo;</h3>';

}

if (! empty ($product_image)) {

echo $html->image ('products/big/'. $product_image['Image'] ['filename'], array ('alt' => $product['Product'] ['title'], 'class' => 'product_image'));

}

echo '<div class= «product_info»>';

if ($product['Product'] ['price']) {

echo '<span class= «price»>Цена: '. $product['Product'] ['price']. ' руб.</span>';

}

echo '<span class= «add»>'. $html->link ('Добавить товар в корзину', array ('controller' => 'orders', 'action' =>'add', $product['Product'] ['id'])). '</span>';

echo 'Артикул: '. $product['Product'] ['code'];

if ($product['Product'] ['text']) {

echo '<pre>'. $product['Product'] ['text']. '</pre>';

}

echo '</div>';

?>

</div>

Код представления совмещает описания разметки на HTML и включение конструкций на языке PHP.

Сначала открывается тег <div> - блок, основного содержимого страницы.

После этого из переменной, сохраненной в контроллере («product»), выводится информация о товаре:

l категория товара (если он принадлежит к одной из категорий, иначе выводится стандартный заголовок «Товары вне категорий»);

l название товара;

l главное изображение товара (если оно установлено);

l цена;

l артикул;

l текстовое описание.

Также выводится ссылка «Добавить товар в корзину» для того, чтобы пользователь мог добавить интересующий его товар в заказ.

В итоге посетитель видит полноценную веб-страницу с описанием товара (рисунок 3).

Рисунок 3 - Отображение информации о товаре

Аналогичным образом формируются все остальные страницы системы. Раздел интерфейса администратора для редактирования информации о товаре представлена на рисунке 4.

Рисунок 4 - Редактирование информации о товаре

Заключение

В результате выполнения данной курсовой работы была достигнута её конечная цель - разработано веб-приложение для автоматизации заказа товаров через Интернет. На данный момент разработанная система успешно функционирует в тестовом.

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

На данном этапе выполняется тестирование системы. Также разрабатывается план её дальнейшего усовершенствования. Из первоочередных задач можно выделить следующие:

организация взаимодействия с платёжными системами;

возможность регистрации посетителей (покупателей);

изменение дизайна сайта.

Список литературы

1. Олькина Е.В. Методические указания по оформлению пояснительных записок к дипломным, курсовым проектам (работам) и отчётов по практикам в соответствии с требованиями государственных стандартов [Текст] / Е.В. Олькина; рецензент О.В. Конюхова. - ОрёлГТУ, 2007. - 54 с.

2. ГОСТ 7.1 - 2003. Общие требования и правила составления и оформление списка литературы [Текст]. - М.: Издательство стандартов, 2004. - 73 с.

3. Свободная энциклопедия [Электронный ресурс]. - Режим доступа: http://ru.wikipedia.org/wiki/.

4. IBM developerWorks Россия: Web-разработка [Электронный ресурс]. - Быстрое создание Web-сайтов с помощью CakePHP. - Режим доступа: http://www.ibm.com/developerworks/ru/edu/os-php-cake1/.

5. Официальный сайт фреймворка CakePHP [Электронный ресурс]. - Режим доступа: http://cakephp.org/.

6. Интернет Университет Информационных Технологий [Электронный ресурс]. - Спецификация Common Gateway Interface. - Режим доступа: http://www.intuit.ru/department/internet/cgi/1/1.html

Размещено на Allbest.ru


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.