Howto address specific element from subform and have it displayed correctly with []

Question

related to this question Zend_Form - Array based elements?

$form = new Zend_Form();
$subForm = new Zend_Form_SubForm();
$subForm->addElement(\'Text\', \'1         


        

Answer 1

So the answer is rather late, but I recently ran across this issue and though I'd share the reason and possible solutions.

From my research, there are at least 7 bugs in Zend's ticketing system dealing with this problem - though the descriptions vary dramatically.

(SO has prevented me from pasting all of the links, so I'll link one and give you the ticket IDs for the others: ZF-9386, ZF-3567, ZF-9451, ZF-7836, ZF-9409, ZF-7679)

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

The one that best describes the issue, and possible fixes, is 10007 - however, ZF themselves have inexplicably chose not to fix it until 2.0.

The problem stems from the fact that when explicitly using:

$this->form->a->b->c->d notation, d will forget every one of it's ancestor subforms, except for it's immediate "c". When you have a big form with custom behavior, this is quite burdensome because you may want to render the whole subform "d" without calling out it's specific descendents, but you may want it in a certain spot or the Zend Decoraters may not be able to pull it without a bunch of work or at all.

I should think this would be a common problem in the subform world, since by definition you're working with complex forms and excepting the most generic of forms hardly any of it would be linear or clearly separated by dt/dd or other clean markup.

There are three ways I found to deal with this issue.

The first is the fine patch contributed in 10007 - this won't work for me because it only works with printing a subform directly and not individual elements - which is about 50% of my use case. Not knowing ZF well enough, I did not pursue extending this functionality to elements as well.

The second is to forgo all custom html around the elements and add enough decorators to satisfy the layout. Although mine are structured well with TRs/TDs, etc., I just couldn't justify the time nor the decision to 100% ZFify our most complex forms - because someday it could be that ZF would not be the best choice.

The third is a much more cut and dry tradeoff, which is what I chose: I would forgo the convience of being able to echo the $this->form->a->b->c->d subform, and instead individually echo all of my elements in their apppropriate spots (like echo $this->form->a->b->c->d->element1 and echo $this->form->a->b->c->d->element2). This keeps my HTML out of the decorators which has its tradeoffs, but keeps my forms in ZF, which is all I want. With this solution, you can now call setElementsBelongsTo() on the d subform and use array notation to get the submission to behave properly, like so:

$objSubFormD->setElementsBelongTo('[a][b][c]').

Please be mindful that I've dumbed down these examples almost beyond practicality so the (dis)advantages may not be immediately clear for each one, I've only given what I perceive to be options and what I chose as a solution. I also feel my solution gives me the best upgrade path to ZF 2.0.