Задача. Интернет-кафе.

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

Интерфейс пользователя: см. html-demo

Пользователь зайдя на сайт, может выбрать сорта кофе, которые он хочет заказать, отметив соответствующие строки в списке возможных сортов. Список сортов храниться в базе данных. В списке на UI не показываются сорта с disabled='Y' (см. скрипт для создание БД). Для каждого сорта кофе пользователь может ввести количество чашек.

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

Правило подсчёта цены заказа:

1. каждая n чашка кофе одного сорта бесплатна. Пример (n=5): 2 чашки чёрного кофе по 1 TGR и 4 чашки со сливками по 2 TGR в сумме стоят 10 TGR но 6 чашек чёрного кофе по 1 TGR стоят 5 TGR, потому что 5 чашка бесплатная.
2. если заказ был сделан более чем на x TGR, то доставка бесплатна, в противном случае стоимость доставки = m TGR

Значения для n, x, m задаются в базе данных в таблице Configuration: id = 'n', id = 'x' и id = 'm' соответственно. Значения по умолчанию: n = 5, x = 10, m = 2

Магазин может время от времени менять правила подсчёта цены заказа, поэтому необходимо облегчить эту процедуру, сделав необходимые изменения в коде для смены алгоритма минимальными. В идеальном случае они не должны требовать перекомпиляции приложения :). Одно из решений использовать скриптовый язык (bsh, groovy, jython) для этой цели, но в реализации данного тестого задания это решение использовать нельзя.

Требования к пользовательскому интерфейсу:

1. интерфейс на 2-х языках (русский и английский).

2. интернационализация i18n c языком по умолчанию - английским.

3. Валидация (client side + server side). Пример: если пользователь ввёл невалидное количество, то должно появиться сообщение (например, javascript:alert), что формат неверен, если же ему всё же удалось послать неверное количество на сервер (например, с помощью wget, curl или чего-нибуть аналогичного), то пользователь возвращается на страницу и видит сообщение об ошибочном формате числа.

   На второй странице поле адрес является обязательным и не может быть пустым.

4. не надо копировать код из html-demo, данный код был создан более 10 лет назад и не является примером для подражания, а только визуализирует функциональность и UI, для вашего воплощения в вашем собственном коде.

Требования к реализации:

1. Приложение должно работать на MySQL, MSSQL server, Oracle, PostgreSQL. Проверять все эти БД не обязательно, но задуматься стоит над тем, что и как стоит применить для работы с БД.
2. Запускается или путем разворачивания на сервере приложения типа Tomcat или как независимое приложение (например, используя Spring Boot).

База данных (см. скрипт).

Конфигурация приложения:

1. Конфигурирование коннекта к БД, как и другие вещи должно осуществляться из внешнего файла. Пример файла конфигурации приложите отдельным файлом к выполненому заданию с указанием как его подключить к запускаемому приложению. Например: "Приложенный файл db.properties.sample необходимо переименовать в db.properties и указать путь к нему в system properties config.path, например: java -Dconfig.path=/home/my/db.properties".

Что должно быть включено в результаты тестового задания:

1. Исходные коды (без бинарных файлов внешних библиотек);
2. Файл сборки проекта, на базе систем управления сборкой проекта, имеющих возможность управлять зависимостями от внешних библиотек (например, maven).
3. Краткое описание процесса сборки проекта и его запуска после сборки.

Используемые технологии:

1. Любой MVC фреймворк;
2. Любая реляционная база данных.

Приветствуется:

1. Наличие Unit тестов (jUnit, TestNG и др.);
2. DAO abstraction. Очень хорошо если будут реализовано обращение к базе данных через JPA/Hibernate и JDBC, с возможностью конфигурации конкретной реализации во время уcтановки приложения на сервер;
3. Clean and documented code;
4. Чёткое соблюдение MVC (например: нет Java кода на JSP, но не только это);
5. Понятный HTML код, использование понятного и структурированного CSS.
6. Использование многократно используемых Layout элементов.

Хардкор!

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

1. Разрешается использовать только Servlet API, JSP, pure JDBC, jUnit;
2. Внедрение Spring IoC;
3. Добавление JPA/Hibernate как альтернатива pure JDBC;
4. Замена кода выполненного на Servlet API на какой-нибудь MVC фреймворк, например, Spring MVC;
5. Перевод приложения на подход дистрибуции с встроенным аппликейшен сервером (например, Spring Boot).

Перед выполнением задания рекомендуется создать Git/Mercurial репозиторий, в котором вы будете сохранять изменения исходных кодов и маркировать тегами каждую из указанных выше фаз развития вашего проекта.