Как стать автором
Обновить

Комментарии 40

Если поле назвать «name[files][]»?
Будет
array (
  'name' => array (
    'files' => array (
      0 => array (
        'name' => 'Новый текстовый документ.txt',
        'type' => 'text/plain',
        'tmp_name' => '/tmp/phpFYV1jb',
        'error' => 0,
        'size' => 13950,
      ),
      1 => array (
        'name' => 'Безымянный.png',
        'type' => 'image/png',
        'tmp_name' => '/tmp/phpOcCqkl',
        'error' => 0,
        'size' => 59329,
      ),
    ),
  ),
)
На самом деле архитектура $_FILES логична. Нужно только вспомнить о представлении таблиц в базах данных — таблица-столбец-строка.
Именно в этом ключе и нужно рассуждать:
files — это таблица с параметрами файлов
name — столбец имен файлов
type — столбец типов
и т.п.
Все крайне логично. И не получится, что будут потеряны какие-нибудь из параметров файла, например, размер, как в случае Вашей иерархической системы.
Не совсем понятно как в моём случае был (будет) потерян размер.

Плюс ко всему — в случае files[pictures][animals][dog], files[pictures][animals][cat] идеология двумерной «таблицы БД», на мой взгляд, не совсем уместна. Что в данном случае считать за координаты (БД/таблица/столбец/строка)?
Я думаю, что ситуацию возможной многомерности массива файлов разработчики PHP как-то упустили… Ну сложно им было представить себе форму в виде двух или трехмерной таблицы для Upload'а файлов :)
Так что вся реализация основана на линейных списках значений одного типа.
Наверное, под самую странную реализацию можно подобрать свою логику. Мне лично странно встретить в реализации $_FILES логику не стандартных хеш-массивов PHP, а баз данных.
Все очень просто — в зависимости от конкретной задачи я могу выбрать хэш (массив) того признака, который меня интересует. Например, только имена.
Если следовать логике «иерархического дерева» (как в статье), то мы будем даже для задачи «поиск файла по имени» вынуждены извлекать все дерево.
В логике же разработчиков PHP — только массив строк.
Уже вполне приемлемо, по-моему.
Обычно делают как: есть какой-то код, который отвечает за сабмит формы. Чтобы отвязать этот код от суперглобальных переменных (например, для юниттестов), обычно в него передают массивы $_POST и $_FILES. Вот на этом этапе и можно преобразовать $_FILES в более удобную и логичную структуру, но только локально в коде, отвечающем за сабмит формы. В частности, именно так было сделано в Symfiny 1.x. А если вы преобразуете прямо суперглобальный массив, потом могут возникнуть проблемы. Например: вы подключите к своему приложению в одном месте сторонний код, который будет надеяться увидеть в $_FILES именно такую структуру, какая там по умолчанию — и на вашем приложении он работать уже не будет.
При желании массив $arrayForFill можно присвоить чему угодно (ну или передать куда угодно). Простите за воспринятую «пропаганду», но это решение скорее для примера.
А еще программист, который будет разбирать код после вас, будет очень удивлен, почему $_FILES не такого формата, как должен быть. И будет очень долго материться, когда наконец-то найдет rRestructuringFilesArray() в auto_prepend-файле )
Для таких нюансов, как мне кажется, придумали документирование. Притом, что такие глобальные вещи комментировать надо в самом заметном месте.
Например, в каком? :)
В том, которое не пройдет ни один человек (разработчик), получивший доступ к проекту…

Битрикс: bitrx/php_interface/init.php (здесь, собственно, я и применил описанное в посте);
ZF: Bootstrap/index.php/Основной_конфиг (это — для примера)
Мне кажется, что в любом проекте/фреймворке/CMS есть такие места (те, которые приходят в голову в первую очередь).
А, так вы это для битрикса пишете, тогда ОК!
Документирование и комментирование как-то разные вещи. Но, у настоящих джедаев, все должно быть понятно и без комментариев.

«Комментарии — это дезодорант к плохо пахнущему коду».
Кент Бек.

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

А массив $_FILES легко разбирается и без велосипедов:

$files = $_FILES['files'];
foreach( $files['error'] as $i => $file_error ) {
switch ( $file_error ) {
case UPLOAD_ERR_OK:
$this->fooModel()->doFooUpload( $files['name'][$i], $files['tmp_name'][$i], $files['type'][$i], $files['size'][$i] );
break;
default:
$this->fooResponse()->addFeedback('Error uploading file '.$files['name'][$i]);
break;
}
}
Как я вас понимаю. Хорошо, что там где я работаю русский мат не понимают.
А если ООП-вариант? Типа:
$files = myFwRequest::Files();
foreach($files as $item) {
    echo $item->name;
    ...
    $item->saveAs($path);
}
А мне вот не ясно — что не так в обычном варианте?
В обычном варианте при помощи foreach красиво по массиву не пробежишь
А Вы бегите фором а не форичем =) Очень даже красиво получается.
Не вижу проблем
foreach($files['name'] as $k => $item) {
    echo $files['type'][$k];
    echo $files['tmp_name'][$k];
    echo $files['error'][$k];
    echo $files['size'][$k];
}
Мой вариант
function multiple(array $_files, $top = TRUE)
{
	$files = array();
	foreach($_files as $name=>$file){
		if($top) $sub_name = $file['name'];
		else	$sub_name = $name;
		
		if(is_array($sub_name)){
			foreach(array_keys($sub_name) as $key){
				$files[$name][$key] = array(
					'name'     => $file['name'][$key],
					'type'     => $file['type'][$key],
					'tmp_name' => $file['tmp_name'][$key],
					'error'    => $file['error'][$key],
					'size'     => $file['size'][$key],
				);
				$files[$name] = multiple($files[$name], FALSE);
			}
		}else{
			$files[$name] = $file;
		}
	}
	return $files;
}

Ссылка на код на github github.com/kohana-mdma/mdma-modules/blob/3.2/develop/common/classes/upload.php#L46

Переделывать приходится для того чтобы работали функции валидации фреймверка.
Протестировал. Все работает для случая levelOne[], но не удалось получить результат для levelOne[levelTwo][]. Или я что-то не так понял?
Да был косяк, вот этот вроде бы работает.
function multiple(array $_files)
	{
		$files = array();
		foreach($_files as $name=>$file){
			if(is_array($file['name'])){
				foreach(array_keys($file['name']) as $key){
					$files[$name][$key] = array(
						'name'     => $file['name'][$key],
						'type'     => $file['type'][$key],
						'tmp_name' => $file['tmp_name'][$key],
						'error'    => $file['error'][$key],
						'size'     => $file['size'][$key],
					);
					$files[$name] = multiple($files[$name]);
				}
			}else{
				$files[$name] = $file;
			}
		}
		return $files;
	}
Чем же Вам так for не угодил что нужно аж массив перестраивать и проходиться по нему в итоге (!!!)3 раза?
Всех очень устраивает for… очень удобный и быстрый цикл. Но что-то я не вижу «навскидку» решения поставленной задачи с помощью этого цикла, да так, чтобы «красиво» было.

Не дадите нам всем посмотреть на Ваш вариант?
Но учтите, что в данной задаче есть не только массивы вида files[], но и любого измерения (многомерные, типа files[level1][level2][level3] и т.д). Спасибо.
Вы же знаете изначально вложенность, вот и ходите по вложенности
$file = $_FILES[вложенность1][вложенность2];
for( $q = 0; $q < count(['errors']); $q++)
{
    // тут делаем что надо с элементом $q
    // $file['name'][$q]
    // $file['error'][$q]
    // $file['etc'][$q]
}
Ответил бы с пояснением (массивами), но не хочу писать некрасивый коммент (без разметки), кармы не хватает.
Вы сделайте var_dump($_FILES) имея форму с полями файлов, имена которых — files[pictures][animals][], files[pictures][animals][]. Как посмотрите их структуру, ещё раз подумайте над использованием for.

Кстати, имена могут быть именноваными (files[pictures][animals][dog] например)… тогда for точно не подойдет.
Да =) Так уже фор не катит, в свое оправдание лишь скажу что так не делал никогда =) всегда как массив числовой отдаю, если больше одного файла
Вы меня простите, но это велосипед, практической пользы от которого, лично я, не вижу.
Уже давно фреймворки научились предоставлять разработчику данные в том виде, в котором удобно.

Зачем городить то, для чего потом придётся ещё дописывать/переписывать/писать поддерживающие классы/методы/функции?

На мой взгляд, Вы из пальца высосали проблему.
Не всегда и не везде используют фреймворки. Далеко не везде предоставлен инструмент. И ещё не во всех проектах код идет в ногу со временем.
Проблема была «высосана из пальца» при работе с одной известной CMS, в которой подобного нет (я предполагаю, что случай не единичный). Почему «проблема»? — потому что гуглы и еже с ним ответа не дали.
Выковыривать из фреймворков — дело не всегда удобное… данное решение — 10 строчек кода которые можно вставить куда угодно и получить то, что необходимо и достаточно.
Это скорее «костыль», нежели могучий функционал. В данном случае — главное, что работает, думать много не надо, совместимо с PHP4.
Я понял Вашу позицию.

Однако, как тут уже говорилось ранее, имеет место быть такой фактор, как «ожидаемость».

Вы ведь не только для себя код пишете, правильно?

Документация, как правило, одно из самых слабых мест — поэтому, не стоит на неё надеяться, а если всё-таки надеетесь, то помните, что эту документацию придётся читать, вникать.
Т.е. тратить время, которое нет надобности убивать, если использовать «стандартные средства».

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

Напомню: не обязательно перегружать сам глобальный массив, можно в необходимом месте получать его представление и именно там добавить /* записку_охотника */
Откуда столько извращенцев, зачем переопределять $_FILES, если можно было сделать простенькую обёртку с итератором и не бояться, что ваш код «сопровождать будет склонный к насилию психопат, который знает, где вы живете».
$oFiles = new Http_Files();
foreach($oFiles AS $aFile) {
echo $aFile['name'], PHP_EOL;
}
Вот так с помощью нехитрых манипуляций можно переопределить $_FILES и заставить материться даже очень спокойного и уравновешенного человека. Но зачем?
P.S. Кто нибудь добавьте картинку с троллейбусом, с телефона неудобно.
PHP-шники всегда радуют )
Стандартная структура логична и понятна. С ней работать даже проще, чем с «правильной» структурой автора.
Меня всегда удивляло, нет, даже бесило, когда начинают заниматься программированием ради программирования, а не достижения результата. Автору лучше придержать свои собственные хотелки при себе.
Может быть, было бы правильнее написать служебный класс и использовать его при разборе массива _FILES?
Такой вот своеобразный интерфейс к массиву. Любой программист поинтересуется, что делает метод, и всё поймёт
/**
 * Корректирует неадекватную структуру суперглобального массива $_FILES.
 * Возвращает рекурсивно упорядоченный массив пришедших файлов.
 *
 * @param array $input ожидается массив $_FILES
 * @return array массив со скорректированной структурой
 */
public function ConvertFilesStructure($input) {
    $output = [];
    foreach ($input as $key => $file) {
        $output[$key] = $this->ConvertFilesStructureRecursive(
            $file['name'],
            $file['type'],
            $file['tmp_name'],
            $file['error'],
            $file['size']
        );
    }
    return $output;
}

public function ConvertFilesStructureRecursive($name, $type, $tmp_name, $error, $size) {
    if (!is_array($name)) {
        return [
            'name'     => $name,
            'type'     => $type,
            'tmp_name' => $tmp_name,
            'error'    => $error,
            'size'     => $size,
        ];
    }
    $output = [];
    foreach ($name as $key => $_crap) {
        $output[$key] = $this->ConvertFilesStructureRecursive(
            $name[$key],
            $type[$key],
            $tmp_name[$key],
            $error[$key],
            $size[$key]
        );
    }
    return $output;
}
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории