Пишем на PHP: BackOffice (продолжение-3)
Руслан Курепин
http://kurepin.ru
Тестирование онлайн-магазина сети гипермаркетов
"Рамстор" закончилось полным провалом для последнего. Никогда больше не
воспользуюсь его услугами.
Из заказанных в магазине товаров мне
привезли всего лишь 40% от общего количества. Причем, что особенно меня
впечатлило, у них не оказалось (ща уписаетесь):
1. Макарон типа
"спагетти" итальянского производства (предлагали взамен украинские).
2. Макарон типа "Рожки", та же песня.
3. Сладкой кукурузы типа
"Зеленый великан", предложили "6 соток или как-то так".
4. Воды "святой
источник 0.33л" (0.5л тоже не оказалось. Предложили взять 1.5л).
5.
Вместо одного салата положили другой, причем взвесили его на кассе по цене
заказанного салата. Можно подумать, что если я покупаю через Сеть салат,
то не знаю его названия и внешнего вида.
...и так далее.
Для
подтверждения собственных догадок я не поленился доехать до ближайшего
"Рамстора" и купить все 13 наименований в торговом зале, что меня сильно
развеселило. А для пущей веселухи я приехал с бланком заказа, где было
отпечатано отсутствие заказанных наименований, и попросил девушку в зале
помочь мне в наборе товаров по данному списку. Она сначала сказала, что
это не ее работа, но когда узнала в чем дело -- сама долго смеялась и
помогала отыскивать все эти макароны, сыры и консервы. Которые, как я и
полагал, оказались в наличии.
Из перечисленного можно сделать
вывод, что в большой и богатой торговой сети гипермаркетов "Рамстор" не
нашлось зарплаты человеку, который вносил бы коррективы в базу данных
магазина хотя бы раз в год.
Надеюсь, мой курс по PHP не станет
причиной написания подобных "магазинов".
А мы продолжаем строить
backoffice.
Пора перейти к добавлению текстов в базу. Для чего
создадим папку text в админской директории.
В общем-то, нам
достаточно скопировать файл add.php из папки рубрик в папку текстов
и чуть подправить его, заменив названия переменных и добавив пару
элементов в форму.
Но мы же не просто делаем сайт. Мы же еще и
чему-то учимся, не так ли?
Поэтому, предлагаю усложнить самим себе
жизнь и добавить еще мелких задач.
Какие параметры мы вписываем в
базу для регистрации нового текста:
1. Название текста
2. Сам
текст
3. Номер рубрики
С первыми двумя полями точно ничего не
сделаешь, а вот к третьему давайте хоть выпадающее меню напишем, а? Чтобы
реже ошибаться в номере рубрики.
Предлагаю создать эту функцию в
файле out.class, так как она может нам понадобиться в любом
последующем классе.
В классе out у нас уже есть одна
функция, выводящая в формате html список рубрик --
out_cat_list.
Предлагаю новую назвать по аналогии --
out_cat_droplist. Ага?
Настоящий программист всегда ленив до
рутиной работы: мы просто скопируем первую функцию чуть ниже, переименуем
ее в out_cat_droplist и чуть иначе оформим html-вывод рубрик. Не
сложно. Если вы сейчас посмотрите на out_cat_list и вспомните, как
оформляется в html выпадающее меню, то тут же поймете, как новая функция
будет выглядеть.
Вот только не надо на меня кряхтеть: "Что-то у
него все как-то просто получается. Даже когда он сознательно усложняет
себе жизнь. Все сводится к тому, что надо что-то во что-то скопировать и
чуточку поправить. Прямо не работа, а халява сплошная получается...",
-- не надо, не тратьте на меня свои нервы. Так все и есть: при правильном
подходе программировать весело и интересно. Особенно в таких проектах, где
не надо искать хитроумных алгоритмов для решения сложных задач. У нас пока
все просто и легко. Наслаждайтесь.
Но одно существенное изменение
мы все-таки внесем в новую функцию.
Дело в том, что думать надо
чуть дальше, чем решаемая в данный момент задача. Остановись, подумай над
тем, как эта функция будет использоваться... Какие могут возникнуть с ней
сложности или неудобства?..
Остановились? Подумали? Да куда
там...
А я, вот, подумал. И вот, что я надумал. Добавление текста
-- занятие не однозначное. Помните, сколько мы описали ситуаций, когда
скрипт даст отказ на проведение добавления? При этом надо дать
пользователю возможность исправиться. А для этого мы вместе с сообщением
об ошибке всегда заполняем форму теми данными, которые он уже
ввел.
Ну, представьте. Пользователь (а в данном случае это мы с
вами) заполняет форму данными (а форма может быть большой и иметь много
разных полей для заполнения) и ошибается в какой-нибудь ерунде. Мы
сообщаем ему об этом. Пользователь поправляется. Но все остальные поля
стоят уже в "сброшенном" положении. Это так не удобно, так бесит, ей
богу!
Как сохранить данные в форме? Очень просто: надо в значение
формы подставить вывод значения переменной, совпадающей с именем поля
формы. Вы это уже могли видеть на добавлении рубрики (если название
написать длиннее положенных 50 символов, вы увидите сообщение об ошибке и
свой текст на месте его редактирования. А я получу еще одно
письмо-уведомление об ошибке выполнения операции добавления рубрики
:).
Но в случае с выпадающими меню, селекторами типа "radio button"
и "чекбоксами" ситуация совершенно иная.
Вот мы ее сейчас и
обработаем. Смотрите, как будет выглядеть функция вывода наших рубрик в
виде выпадающего меню:
То есть, мы на входе принимаем значение, которое
должно быть выбрано изначально.
Если такое значение в базе находится,
то так тому и быть. А коли не найдется, так на "нет" и суда
нет...
Если позволите, я не буду сегодня задействовать это меню,
т.к. уверен, что оно заработает. В этом мы убедимся в завтрашнем выпуске.
А сегодня я предлагаю вернуться аж ко второй главе
повествования о PHP, которая закончилась фразой: "Добавили в свою базу
данных эти две таблицы? Отлично. Можете пока подумать, как будет выглядеть
третья таблица. А я тем временем прощаюсь с вами до следующего
выпуска".
Речь шла о том, что мы создали таблицу для текстов и
таблицу для рубрик. Но должна быть и третья таблица. Я все ждал, пока
кто-нибудь спросит: "А какая же -- эта третья таблица?!". Но никто так и
не спросил. Будем считать, что все догадались -- третья таблица нужна для
связки рубрик с текстами.
И не надо строить такие умные моськи, я
вас умоляю! В процедуре добавления текста, в SQL-запросе написана
откровенная лажа, которую вы сожрали -- как так и надо. Там даже
количество передаваемых параметров не совпадает. Внимательные вы
мои...
Я ставлю всем по "двойке" за наблюдательность и начинаем
разбираться в этой ситуации.
Связать текст с рубрикой можно и без
третьей таблицы. Достаточно добавить поле t_cat в таблицу текстов и
в это поле писать номер рубрики, к которой относится текст.
Так
все обычно и делают. Но мы пойдем другим путем; у нас большой проект, нам
надо закладываться в максимальную гибкость. Что мы будем делать, когда
начнут появляться тексты, имеющие отношение к разным рубрикам. Например,
куда поместить текст с условным названием "PHP и MySQL, популярные
решения"? В рубрику "Базы данных", "Программирование на PHP" или "PHP для
чайников"?
Так вот, чтобы не ломать голову над подобными
проблемами, мы просто создадим таблицу связей между текстами и
рубриками.
Моя база вот так сожрала запрос на создание связующей
таблицы:
И в эту базу мы будем заносить все соответствия
текстов рубрикам. Сможем привязывать один текст с любым количеством
рубрик, или рубрику с любым количеством текстов -- называйте это как
хотите.
Так что, приготовьтесь -- завтра будем вносить изменения в
комплект функций, занимающихся добавлением текста в базу.
До
завтра! Приятного вам интернет-шопинга...