そのため、答えはかなり遅れていますが、最近この問題に出くわしましたが、その理由と可能な解決策を共有したいと思います.
私の調査によると、この問題に対処する Zend のチケット システムには、少なくとも 7 つのバグがあります。ただし、説明は劇的に異なります。
(すべてのリンクを貼り付けることができないため、1 つをリンクし、他のチケット ID を提供します: 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 デコレーターができない場合があります。手間をかけずに、またはまったく引っ張ることができます。
これは、サブフォームの世界ではよくある問題だと思います。なぜなら、定義上、複雑なフォームを扱っており、最も一般的なフォームを除いて、線形であるか、dt/dd またはその他のクリーンなマークアップで明確に分離されているフォームはほとんどないからです。
この問題に対処するために私が見つけた 3 つの方法があります。
1 つ目は 10007 で提供された細かいパッチです。これは、個々の要素ではなく、サブフォームを直接印刷する場合にのみ機能するため、私には機能しません。これは、私のユース ケースの約 50% です。ZF のことをよく知らなかったので、この機能を要素に拡張することも追求しませんでした。
2 つ目は、要素の周りのすべてのカスタム html を放棄し、レイアウトを満たすのに十分なデコレータを追加することです。私は TR/TD などで適切に構成されていますが、最も複雑なフォームを 100% ZF 化する時間や決定を正当化することはできませんでした。
3 つ目は、より切り詰めたトレードオフであり、私が選択したものです: $this->form->a->b->c->d サブフォームをエコーできるという便利さを放棄し、代わりに個別にすべての要素を適切な場所にエコーします (echo $this->form->a->b->c->d->element1 および echo $this->form->a->b->c-> など)。 d->要素 2)。これにより、HTML はトレードオフのあるデコレーターから除外されますが、フォームは ZF に保持されます。これが私が望むすべてです。このソリューションにより、次のように、d サブフォームで setElementsBelongsTo() を呼び出し、配列表記を使用して送信を適切に動作させることができます。
$objSubFormD->setElementsBelongTo('[a][b][c]')。
これらの例はほとんど実用性を超えて馬鹿げていることに注意してください。そのため、それぞれの (欠点) 利点がすぐには明確にならない可能性があります。オプションであると認識したものと、解決策として選択したもののみを示しています。また、私のソリューションが ZF 2.0 への最適なアップグレード パスを提供してくれると感じています。