Form abstract factory #4358
Form abstract factory #4358
Conversation
- Modified Factory to allow passing an InputFilterInterface as an input_filter specification. - Created FormAbstractFactory, which utilizes FormElementPluginManager, InputFilterPluginManager, FilterPluginManager, and ValidatorPluginManager to create a form from a specification
- Tested that form specification can accept an InputFilter instance - Tested that hydrator creation will use the HydratorManager, if present.
- Tests for all behaviors of abstract factory - Fixed a number of issues along the way - Form Factory should inject created input filter with input filter factory if it will accept it.
- Superceded by FormAbstractFactory, which is more complete and uses the new plugin managers we've added.
|
Also supercedes #4100 |
|
Ready for review! |
| $this->assertFalse($this->forms->canCreateServiceWithName($this->services, 'Form\Foo', 'Form\Foo')); | ||
| } | ||
|
|
||
| public function testMissingFormConfigIndicatesCannotCreateForm() |
There was a problem hiding this comment.
This test is identical to the previous one!
| /** | ||
| * @var string Top-level configuration key indicating forms configuration | ||
| */ | ||
| protected $configKey = 'form_manager'; |
There was a problem hiding this comment.
forms wouldn't make more sense here? Since everything that will go under this key are just forms specifications!?
There was a problem hiding this comment.
I'm ambivalent. I went with something that mirrored the idea of
service_manager.
On Tuesday, April 30, 2013, Josias Duarte Busiquia wrote:
In library/Zend/Form/FormAbstractFactory.php:
- * @copyright Copyright (c) 2005-2013 Zend Technologies USA Inc. (http://www.zend.com)
- * @license http://framework.zend.com/license/new-bsd New BSD License
- */
+
+namespace Zend\Form;
+
+use Zend\InputFilter\InputFilterInterface;
+use Zend\ServiceManager\AbstractFactoryInterface;
+use Zend\ServiceManager\ServiceLocatorInterface;
+
+class FormAbstractFactory implements AbstractFactoryInterface
+{- /**
\* @var string Top-level configuration key indicating forms configuration*/- protected $configKey = 'form_manager';
forms wouldn't make more sense here? Since everything that will go under
this key are just forms specifications!?—
Reply to this email directly or view it on GitHubhttps://github.com//pull/4358/files#r4024798
.
Matthew Weier O'Phinney
[email protected]
http://mwop.net/
|
I'm sorry about this but early today I didn't have the time to express some of my thoughts. I just wanted to discuss them before this gets released. @weierophinney, @akrabat ping |
Intended as an alternative to #4343 and #4283.
This abstract factory simply consumes the existing factories. FormElementManager gives us the ability to create elements and fieldsets, and the Form Factory can accept an FormElementManager optionally to the constructor. Additionally, the Form Factory will pull hydrators from the parent service manager already (I have a TODO to alter this to use the HydratorPluginManager).
I modified Form Factory to allow passing an InputFilter instance for the input_filter specification. This allows attempting to pull the InputFilter via the InputFilterManager. If we cannot, we can use the composed InputFilterFactory in the Form Factory, and inject it with the FilterManager and ValidatorManager -- allowing us access to custom filters and validators.
This approach requires no addition of large components, and works with the features that already exist.
Todo: