Renderers in HTML_QuickForm2 are classes that output the form. They either generate the resultant HTML themselves or represent the form in some intermediate format that can later be used by e.g. a template engine.
A new feature in HTML_QuickForm2 compared to HTML_QuickForm is the ability to extend Renderer functionality by plugins.
Typical form output workflow:
$renderer = HTML_QuickForm2_Renderer::factory('custom');
// common options
'group_errors' => true,
'required_note' => 'Fields labeled in 36pt bold red font are required'
// renderer-specific setup
// process the form
// Output the links to JS libraries, if used
echo $link . "\n";
// Assuming the renderer implements __toString()
The following renderers are installed with the package:
setOption() method is used to set the values of configuration parameters and getOption() method to read them. Passing an unknown parameter name to these methods will result in an Exception. The following parameters are defined in the base class and known to all Renderers:
|Parameter name||Description||Expected type||Default value|
||Whether to group hidden elements together or render them where they were added.||boolean||TRUE|
||Whether to group error messages or render them alongside elements they apply to.||boolean||FALSE|
||Leading message for grouped errors.||string||
||Trailing message for grouped errors.||string||
||Note displayed if the form contains required elements.||string||
reset() method clears all accumulated data. It is called automatically when rendering a HTML_QuickForm2 object, but must be called manually when rendering form elements separately.
It is only possible to instantiate built-in Renderers through HTML_QuickForm2_Renderer::factory() as their __construct() methods are declared protected. Moreover, factory() returns an instance of HTML_QuickForm2_Renderer_Proxy wrapping around a specific Renderer instance. This setup is needed for plugin support and serves as a workaround for PHP shortcomings:
Proxy and factory() are used to aggregate methods from several classes and to limit access to them from outside: all fields and methods of a Renderer instance are public, but the only path to that instance is through a Proxy that only allows access to explicitly "published" methods and methods defined in base class. Plugins, however, have direct access to a Renderer instance and thus can freely use its API.
It is definitely possible to create a subclass of a built-in Renderer with a public __construct() method and do not use factory(). This will, however, prevent plugins from working.
Plugins are the means to enhance Renderer functionality at runtime. From user's point of view the Renderer object simply gets a new method:
$foo = HTML_QuickForm2_Renderer::factory('foo');
// This will also work
The main puprose of plugins is to allow custom elements which require some complex output behaviour to define that behaviour in separate classes leveraging existing Renderer code. Previously it was usually implemented in the element class itself, leading to unnecessary bloat and code duplication.
dualselect.phpexample installed with the package shows, among other things, how to create a renderer plugin for a custom element.