Adds more config to FormCollection-ViewHelper#5565
Conversation
|
this would allow the form collection fieldset tag to be editable correct? |
|
Correct. You can then for instance replace the This will then wrap the collection into a |
There was a problem hiding this comment.
I think calling in current class can be call directly $this->labelWrapper
There was a problem hiding this comment.
I think it adds a degree of flexibility to have a getter. Don't have many use cases though
There was a problem hiding this comment.
As currently in render() and renderTemplate() also getters are used (see lines 106ff and 160ff), I decided to use getters instead of calling the property directly. Otherwise I would have to rewrite the complete class to make it consistent. Wouldn't be a problem though.
There was a problem hiding this comment.
@heiglandreas if you agree with me, I think you should only change the related with the PR to avoid confusion :)
|
Hey guys. Since you're working with form collections, would you mind taking a look at this issue? #5502 . I already tried to fix that myself, but i wasnt able. |
This commit adds more configuration options to the FormCollection-ViewHelper. The hard-coded fieldset-wrapper is now configurable as is the hard-coded legend as well as the hard-coded position and template of the template-provider. The defaults have been set to the currently hard-coded values, so that no BC-break should happen. Also the behaviour of the template-renderer has been changed in so far as the template is now rendered using the collection-object and not the content of the collection-object THis might be a case of BC-Break in edge-cases but the current default-behaviour as provided by the unit-tests is not broken. No tests have been changed, there have only been additions
THis aims to a better CodeCoverage
|
I'll open a new PR |
This commit adds more configuration options to the
FormCollection-ViewHelper.
The hard-coded fieldset-wrapper is now configurable as is the hard-coded
legend as well as the hard-coded position and template of the
template-provider. The defaults have been set to the currently
hard-coded values, so that no BC-break should happen.
Also the behaviour of the template-renderer has been changed in so far
as the template is now rendered using the collection-object and not the
content of the collection-object
THis might be a case of BC-Break in edge-cases but the current
default-behaviour as provided by the unit-tests is not broken.
No tests have been changed, there have only been additions