hummermania

А можно и вообще без else сделать. В условии проверить на isset ($_GET/$_POST['имя кнопки формы']) - если да то внутри скобок идет основной алгоритм скрипта. Дополнительно нужно проверить данные пришедшие из каждого поля! (не доверяйте даже скрытым полям, которые сами же и задали) - потом логика скрипта. А на else - можно поставить вывод опять той же формы! if(isset ($_GET/$_POST['имя кнопки формы']) { // 1-проверка первого поля на тип данных и на недопустимые символы ..... // 2 -проверка второго и т.д. полей ..... // 3 логика скрипта } else { // вывод формы } А и еще. Чтобы выводить сообщения об ошибках - их надо собирать по мере проверок полей формы. т.е. завести себе переменную в которую конкатенацией добавлять сообщения об ошибках если таковые будут появляться по логике скрипта или по результатам проверок. Если на сайте предполагается большое кол-во полей и форм - то я себе сделал класс который накапливает сообщения и может их все скопом распечатывать перебирая элементы массива. и универсальную ф-цию проверки поля. Использую eregi_replace для проверки на недопустимые символы.

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

А файлы есть в папке? Судя по тому что на место $rezult - выдается в таблице пустая ячейка - то файлы хоть и есть но пустые. И как должна тогда отображаться таблица?

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

И ч? ты врешь, ставя значек CSS-valid? http://jigsaw.w3.org/css-validator/validat...rning=1〈=en Вот теперь ЦСС - валид!

=) Спасибо за комменты - передам дизайнеру. Я в дизе не силен, так по мелочи.

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

По идее должно. Парсер вначале считает код в память, потом содержимое файла рек.пхп и включит в памяти как продолжение -НЕЗАВИСИМО от того сработает ли условие. Т.е. на этапе непосредственно парсинга, обработки, а не на этапе исполнения кода.

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

Хм, а почему ДВЕ формы???? Если хотите двумя скриптами: form.php - файл скажем формы <form action='add_img.php' method='POST' enctype='multipart/form-data'> Фото: <input type='file' name='t_item'> <input type='submit' name='ok' value='Добавить' /> </form> Имеем форму а в ней поле с кнопкой обзор справа и кнопку отправки. После выбора файла путь к нему высветится в текстовом поле. А после нажатия браузер вызовет скрипт add_img.php, в который и обьединяем оба кода: занесение в базу, и копирование в папку на сервере. if (isset($_POST['ok'])) { $success=0; $upfiledir=$upfile=$uplink=''; // копируем пришедший из формы файл в папку с фотками $upfiledir = $_SERVER['DOCUMENT_ROOT']."/MySite/foto_img/";/* Определяем директорию на сервере. */ $upfile = $upfiledir.$_FILES['t_item']['name']);/* Полное имя загружаемого файла */ if (move_uploaded_file($_FILES['t_item']['tmp_name'], $upfile ) )/* если файл перемещен в нужную директорию выводим информацию */ { $uplink = "/MySite/foto_img/".$_FILES['t_item']['name'];/* Данная переменная хранит относительную ссылку, которую можно поместить в БД */ $success++; } // фиксируем название файла в базе, только в том случае если он успешно скопировался if ($success) { $result = mysql_query ('INSERT INTO data (img) VALUES ("'.$uplink.'")'); if (mysql_affected_rows($result)==1) // если вставка была успешна $success++; } if($success==2) // Если успешны обе операции! { echo "Файл ".$_FILES['t_item']['name']." успешно загружен на сервер! Размер: ".$_FILES['t_item']['size']." байт. тип: ".$_FILES['t_item']['type']." } } Кстати $_FILES['t_item']['name'] - должен содержать только имя файла, путь на локальной машине откуда берется этот файл браузер же никогда не передает. ( в данном случае - aaa.jpg)

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

Можно еще прочувстовать разницу между ними если знать как ПХП обрабатывает файлы. Допустим мы запросили файл index.php - в корне сайта. ПХП считывает его, разбирая синтаксис. После анализа формирует в памяти внутреннее предсатвление считанного файла в виде конкретных инструкций. И затем выполняет их последовательно. В результате получаем ХТМЛ ответ. Если попадается инструкция include - парсер ПХП останавливает обработку текущего файла, и переключается на тот который в инклуде. Например include("news.php") - ищет и разбирает по строкам файл новостей. Потом опять возвращается к Индекс. Если не ошибаюсь то для всех обрабатываемых файлов создаются отдельные таблицы внутреннего для ПХП представления переменных и функций. Что приводит к некоторым накладным расходам. Если подключаемый файл отсутствует - выдается лишь ворнинг и обработка Индекс продолжается. Если же вместо include будет require - то весь текст файла вставляется в индекс, т.е. в памяти он становится одним. И все рекуайр аналогично. Весь индекс пхп становится одним, состоящим из кода всех подключаемых файлов. И при анализе уже одного большого файла создается одна таблица ф-ций и переменных, которая потом используется для трансляции во внутреннее представление. В этом случае -если файл отсуствует получим фатал еррор, и остановку дальнейшей обработки. Вся страница будет прервана после первого же отсутвующего файла в рекуайр. В итоге: какой то из методов дает выигрыш в производительности, кажись рекуайр - так как транслятору пхп быстрее обработать один файл и создать едину таблицу и внутренний код инструкций, чем переключаться между разными файлами и обрабатывать каждый по отдельности. Но так как сейчас сервера доведены до предела мощностей - выигрыш в долях секунды вряд ли будет заметен. Хотя можно поэкспериментировать сравнив время генерации страницы.

проверка на кнопку - это верно, в случае если в будущем вдруг надо срочно сменить название на кнопке или name кнокпи - то попутно надо рыскать по пхп коду где все эти проверки. А скрытыми полями можно унифицировать все формы сайта, завести скажем серию констант, а потом подставлять их значения в скрытое поле action например. define("USER_REGISTER", 12); define("USER_LOGIN", 17); define("USER_OPTIONS", 24); а при создании формы ... echo ' ... .... ';

не забывайте резать данные пришедшие от пользователя на чужеродные символы $str=eregi_replace('[^-a-z0-9]','',$_POST['user']); т.е. любой символ кроме тире, англ букв, и чифр вырезаем.

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