25 сентября 2012 в 10:27
Хм, странная ситуация, моя в шоке ))
Итак, есть форма, записи "по умолчанию" в которую подставляются по результатам запроса.
Вернее сказать, что обход результатов запроса создает форму определенной величины. Конкретно:
Обход всех дочерних элементов у 1 материала, по модулю nodehierarchy, и занесение их в 1 таблицу-форму для массового редактирования.
Сделал, все работает как часы.
Решил добавить дочерние материалы с некоторыми незаполненными полями, т.е. поменял у запроса innerJoin на leftJoin.
Появились материалы с пустыми полями, но теперь сабмит вообще не отрабатывает.
ПС: не отрабатывает - значит при сабмите просто загружается заново форма, но метод ПОСТ происходит.
Вопрос: Как сабмит формы связан с наличием в запросе "левого присоединения".
В логах сервера, друпала пусто. И фаербаг показывает правильные ПОСТ данные.
Комментарии
Укороченный пример:
<?php$query = db_select('node', 'n');
$query->innerJoin('field_data_field_price','fdfp','fdfp.entity_id = n.nid');
$query->innerJoin('field_data_field_floor','fdff','fdff.entity_id = n.nid');
$query->condition('status', 1);
$query->fields('n',array('nid','title'));
$query->fields('fdff',array('field_floor_value'));
$query->fields('fdfp',array('field_price_value'));
$results = $query->execute(); $form = array();
foreach (
$results as $key=>$cnode) {
$ftitle = array('#id' => 'childnodes-' . $key . '-title',
'#type'=>'textfield',
'#default_value' => $cnode->title,
'#size' => 20,
);
$ffloor = array(
'#id' => 'childnodes-' . $key . '-floor',
'#type'=>'textfield',
'#default_value' => ($cnode->field_floor_value != NULL)?$cnode->field_floor_value:'',
'#size' => 5,
);
$fprice = array(
'#id' => 'childnodes-' . $key . '-price',
'#type'=>'textfield',
'#default_value' => $cnode->field_price_value,
'#size' => 10,
);
$form['childnodes'][] = array(
'ftitle' => $ftitle,
'ffloor' => $ffloor,
'fprice' => $fprice,
);
}
$form['submit'] = array('#type' => 'submit',
'#value' => t('Submit'),
'#submit' => array('mymodule_edit_form_submit)'
);
return
$form;}
?>
Так все работает. Но стоит поменять
<?php$query->innerJoin('field_data_field_floor','fdff','fdff.entity_id = n.nid');
?>
на
<?php$query->leftJoin('field_data_field_floor','fdff','fdff.entity_id = n.nid');
?>
чтобы отображались записи с незаполненными полями. То форма перестает передаваться в мою функцию сабмита.
Оказывается проблема в другом.
Я вообще исключил это условие из запроса, однако ошибка имеет место быть.
Я попробовал ограничивать выборку из базы и, "опытным путем" определил, что максимальное количество, которое друпал отлавливает это 121 запись по 7 полей в каждой.
При увеличении выборки на 122 элемента, происходило вышеописанное событие.
Так же я нашел почему не обрабатывается сабмит, оказывает информация о форме просто вырезается из POST запроса и обработчик (handler) просто не видит что нужно вызывать.
Отсюда я сделал вывод что присутствуют какие-то ограничения, но так и не могу их определить.
Размер POST и FILE_UPLOAD определен в 100МБ, когда вся форма целиком весит всего 25КБ.
Так же определил что обрезка POST происходит примерно после превышения порога в 24КБ, хотя это может быть и не связано.
Что я пропустил и как обойти эти ограничения?
Или подскажите, если знаете, другой вариант массового редактирования (((
В результате создал пошаговую форму редактирования. Как бы не ругались манагеры...это ограничение в количестве отправляемых ПОСТ данных я обойти не могу (((
Batch Api
мдяя....
Вы знаете как с помощью Batch сабмитить формы?
Просветите...
Batch запускается после сабмита, а если не запускается сабмит то не запускается и Batch.
Результат я конечно выполняю через Batch. Проблема как раз в том что до этого не доходит.
Странно, первый раз слышу,чтоб друпал обрезал ПОСТ-запрос, при сравнительно небольшом объеме данных..
Скорее всего собака в чем-то другом порылась-))
А чем вас не устроил стандартный шаблон имени функции сабмита: FORM_ID_submit($form,&$form_state)?
Какой смысл в "принудительном" назначении "#id" каждому элементы формы?
Форма "вызывается" функцией drupal_get_form("имя_функции_конструктора_формы", $args..)?
В БД нет каких-то ограничений на размер текстовых полей(в которых храниться $form_state формы?)
А зачем вам сабмитить форму через батч? Он не для этого
Передавать 20k+ данных через POST несколько странно.
И да: батч можно запускать не только через сабмит хэндлер
Я бы для начала сделал аналогичную форму на чистом пыхе, так узнал бы срупал в этом виноват или сервант
Какой смысл в "принудительном" назначении "#id" каждому элементы формы?
Это остатки от основного кода, в котором форма вызывается в табличном представлении, поэтому на форме есть 2 элемента, один это
<?php$form['childnodes'][] = &$element;
?>
а второй
<?php$form['childnodes'][#rows][] = &$element;
?>
т.е. два связанных элемента, один из которых является элементом формы, а второй элементом таблицы. Один из которых не отображается, но изменения значения на одном приводят к изменению значения на другом. Но это не важно, я убирал таблицу и делал чистую форму.
конечно
$form_state не режется, режется только $_POST.
да как его не запускай, а данных в $_POST для его перехвата после сабмита нет.
Сервант в этом не виноват.
Проверил на чистом ПХП. Создал форму из 1000 элементов и запостил.
Пост запрос пришел абсолютно верный, со всеми элементами.
Та же самая форма на друпале режется после ~820 элементов. Причем $_POST выглядит как бы завершенным, т.е. присутствуют все закрывающиеся скобки, вот только 100+ элементов в массиве не хватает, как и информации о кнопках ))
Возникла идея, поменять вес у кнопки и элементов, и подсчитать точно сколько элементов создастся
Т.е. в ПОСТЕ первыми будут идти данные о сабмите, и друпал их перехватит.
Вот что получилось:
Шаг 1: Загрузка файла прайс-листа в формате Excel
Шаг2: Выбор листа для обработки
Шаг3: Происходит загрузка листа в табличное представление.
На этом шаге мы назначаем заголовки столбцам или выполняем предустановленные действия:
- удаление столбца
- объединение или разделение столбцов
Т.к. строгий формат прайса не определен, и он может быть очень большим, предусмотрена функция удаления столбца со сдвигом влево.
Так же предусмотрена возможность объединения столбцов с названиями и ценами. Названия объединяются путем слияния через разделитель, а цены путем поиска максимального значения.
Тутже мы отмечаем строки, которые должны участвовать в импорте.
Удаленные столбцы можно вернуть обратно:
Шаг4: Происходит обработка файла по настроенным на предыдущем шаге параметрам, и создается многоступенчатая форма внутри другой многоступенчатой формы, которая позволяет произвести проверку всех обработанных данных и сделать, при необходимости, поправки.
Шаг5: Создание всех нод.
Все ajax действия и переход по страницам в любом направлении сохраняют любое выполненное действие на текущем шаге.
Какой парсер, PHPExel?
Да