Как обратиться к конкретному элементу из подчиненной формы и правильно ли он отобразить с помощью []

Question

относится к этому вопросу Zend_Form - элементы на основе массива?

$form = new Zend_Form();
$subForm = new Zend_Form_SubForm();
$subForm->addElement('Text', '1')
        ->addElement('Text', '2');
$form->addSubForm($subForm, 'element');
$var = '1'; $var2 = '2';
echo $form->getSubForm('element')->$var;
echo $form->getSubForm('element')->$var2;

Если я использую этот способ, вывод будет ошибочно (или, по крайней мере, не совсем ожидаемым)

<input type="text" value="" id="1" name="1">

Если я использую echo $, вывод будет корректно

<input type="text" value="" id="element-1" name="element[1]">

но тогда я теряю гибкость

Я не говорю, что это ошибка или что-то еще, просто не уверен, какой будет правильный синтаксис. Спасибо

Answer 1

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

По моим исследованиям, в билетной системе Zend есть как минимум 7 ошибок, связанных с этой проблемой - хотя описания сильно различаются.

(SO помешал мне вставить все ссылки, поэтому я свяжу одну и дам вам идентификаторы билетов для других: ZF-9386, ZF-3567, ZF-9451, ZF-7836, ZF-9409 , ZF-7679)

http://framework.zend.com/issues/browse/ZF-10007

Лучшим описанием проблемы и возможных исправлений является 10007 - однако сами ZF необъяснимым образом выбрали , а не , чтобы исправить ее до версии 2.0.

Проблема связана с тем, что при явном использовании:

$ this-> form-> a-> b-> c-> d, d забудет все подчиненные формы предка, за исключением непосредственного "c". Когда у вас есть большая форма с пользовательским поведением, это довольно обременительно, потому что вы можете рендерить всю подчиненную форму «d», не вызывая ее специфических потомков, но вы можете захотеть ее в определенном месте, или Zend Decoraters не сможет тянуть его без кучи работы или вообще.

Мне следует подумать, что это будет распространенной проблемой в мире подчиненных, поскольку по определению вы работаете со сложными формами и исключаете наиболее общие формы, едва ли какая-либо из них будет линейной или четко разделенной dt / dd или другим чистая разметка.

Я нашел три способа решения этой проблемы.

Первый - это прекрасный патч, добавленный в 10007 - он не будет работать для меня, потому что он работает только с печатью подчиненной формы, а не отдельных элементов - что составляет около 50% моего варианта использования. Не зная ZF достаточно хорошо, я не стремился распространить эту функциональность и на элементы.

Второй - отказаться от всех пользовательских html-элементов вокруг элементов и добавить достаточное количество декораторов для удовлетворения макета. Хотя мои хорошо структурированы с TR / TD и т. Д., Я просто не мог оправдать ни время, ни решение о 100% ZFификации наших самых сложных форм - потому что когда-нибудь может оказаться, что ZF не будет лучшим выбором.

Третий вариант - это гораздо более скромный и сухой компромисс, который я и выбрал: я бы отказался от убежденности в возможности эхоподобия субформы $ this-> form-> a-> b-> c-> d, и вместо этого индивидуально отображать все мои элементы в соответствующих местах (например, echo $ this-> form-> a-> b-> c-> d-> element1 и echo $ this-> form-> a-> b-> C-> D-> element2). Это исключает мой HTML из декораторов, у которых есть свои компромиссы, но сохраняет мои формы в ZF, и это все, что я хочу. С помощью этого решения вы можете теперь вызывать setElementsBelongsTo () для подчиненной формы d и использовать запись массива, чтобы заставить представление вести себя правильно, например так:

$ objSubFormD-> setElementsBelongTo ( '[а] [б] [с]').

Пожалуйста, помните, что я привел эти примеры почти за пределы практичности, так что преимущества (недостатки) могут быть не сразу очевидны для каждого из них, я дал только то, что я воспринимаю как варианты, и что я выбрал в качестве решения , Я также чувствую, что мое решение дает мне лучший путь обновления до ZF 2.0.