А это клавиатура, с помощью которой я творю...
http://kurepin.ru/php/flag/
Rambler's Top100
Пишем на PHP: Флаг enable и удаление файлов

Печально констатировать, но за прошедшие дни не пришло ни одного варианта решения по заданиям из прошлого выпуска.

Жаль. Мне бы хотелось видеть среди своих читателей не только кодировщиков, но и программистов.

Вы знаете, что в классическом процессе создания программного продукта должно быть три звена: постановщик задачипрограммисткодировщик?

Постановщик — ставит задачу. Ставит ее на родном языке, да так, чтобы она всем была понятна. Особенно программисту.

Программист — ломает голову над алгоритмами решения тех задач, которые поставил постановщик задач. А потом вдалбливает эти алгоритмы в голову кодировщику.

Кодировщик — пишет всякие тексты, понятные только компьютеру. Это последнее звено в приготовлении программного продукта.

Сегодня, после того, как языки программирования поднялись до уровня обычного английского (а в некоторых случаях и родного, локального) языка, эти три ипостаси как-то незаметно слились воедино. Лично мне кажется, что это плохо. Но с этим ничего не поделаешь, поэтому и я тоже стал "сам себе постановщик–программист–кодировщик", хотя программировать (в чистом понимании этого процесса) мне больше нравится. Именно поэтому, кстати, у меня очень много заброшенных проектов, которые решены в голове, но не реализованы на бумаге. Ну что поделать... остается только надеяться, что у вас таких проектов будет меньше.

Ну да ладно, что-то я разболтался сегодня. Перейдем к делу.

Прежде всего, давайте вот какой вопрос решим. Как сделать так, чтобы мы могли снимать и ставить материалы на сайт быстро и с легкостью?

Способов решения такой задачи настолько много, насколько много программистов на этой земле, я думаю. Но мы воспользуемся самым традиционным, как мне кажется, способом.

Раз у нас есть база данных, значит надо добавить в таблицу текстов флажок, указывающий на "видимость" материала.

Этот флажок можно назвать, например, t_enable. Или t_on. Мне больше нравится t_enable, а вам?

Модифицировать таблицу мы уже умеем, поэтому разжевывать следующий запрос в SQL я не буду:

alter table tbltexts add column t_enable enum("Y","N") not null default "N";

Кто такой enum() и с чем его едят — вы можете прочесть тут: 6.2.3.3 The ENUM Type.

Вот. Теперь каждый добавленный в базу текст будет иметь флаг t_enable, который будет изначально устанавливаться в N (No).

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

Назовем эту функцию in_text_enable().

Добавьте в class_in переменную in_text_enable:

$this->in_text_enable;

и приступим к написанию коротенькой функции.
Как видите, ничего особенно умного тут придумывать не надо. Достаточно присвоить переменной in_text_id номер текста, переменной in_text_enable статус (Yes/No) и вызвать нашу свежеиспеченную функцию in_text_enable().

Какую проверку на ошибочные данные я не сделал в этой переменной? Правильно, — не сделал проверку на существование текста, которому мы хотим сменить статус.

И ничего страшного, я вам скажу. Это как раз тот случай, когда запрос в БД построен так, что никакого вреда случиться не может.

Посудите сами. Переменная in_text_enable может нести в себе только значение "N" или "Y": все другие значения напрочь отметаются первой строкой тела функции. Либо переменная равна 'Y', либо мы ей тут же присваиваем значение "N".

    Честно говоря, эту проверку можно было бы тоже не производить — MySQL сам не пропустит значений, не входящих в перечислимый тип enum(). Но! Нам тогда надо было бы "прослешить" эту переменную, чтобы не допустить подстановки в нее взламывающего кода, а потом еще обрабатывать сообщение об ошибке от mysql, если значение окажется не 'Y' и не 'N'. Поэтому, проще привести данные к их точному виду и ни о чем не волноваться.

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

Если же значение переменной in_text_id окажется ложным, и такого текста в нашей базе нет, то SQL-запрос обычно отработается, не внеся в базу никаких изменений и не возвратив никаких ошибок.

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

Теперь на нашем сайте будут видны только те тексты, которые должны быть видны, а не все подряд.

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

Для удаления файла с диска в PHP (для UNIX) используется функция unlink(), которой в качестве аргумента передается полный путь к файлу, подлежащему уничтожению.
Тоже простая функция, комментировать построчно я ее не стану. Лучше обратите внимание на порядок выполнения: сначала мы удаляем текст из БД, а только потом с диска, а не наоборот! Почему?

А представьте себе, что будет, если мы сначала удалим файл с диска, а потом по какой-нибудь случайной причине не получится удалить файл из БД? В этом случае документ будет по-прежнему отображаться на сайте, а при его запросе пользователем будет выскакивать ошибка открытия файла на диске. Фу, как это не красиво!

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

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

    Именно поэтому, мы должны были на нашем прошлом занятии сначала записать файл на диск, а потом уже добавлять его в базу данных. Но мы сделали наоборот, и я обязан объяснить почему.
    Мы не можем записать файл на диск, не узнав его ID. А узнать его ID мы можем только после добавления записи в базу. Казалось бы, что это заколдованный круг, но не тут-то было! У нас же теперь есть флаг t_enable, который защитит нас от ошибки. Даже если произошла ошибка записи на диск, то на сайте никаких изменений не произойдет, так как по умолчанию флаг t_enable установлен в 'N' и добавленный текст на сайте не показывается, до его подтверждения при помощи функции in_text_enable(). Вот такая военная хитрость!


И не забудьте добавить в файл class_utils описание новой ошибки:

$err[32]="Не могу удалить файл: ".$this->PATH_DATA."/".$this->in_text_id;

... и почему я все время вам об этом напоминаю...

На сегодня это все. До завтра!

[шаг назад] [печатать] [в начало сайта]



copyright ©2000-2017 Ruslan Kurepin