As with all subclasses, the actual initialization is done in the initialize() function, not in the constructor, to allow for error handling.
Quick glance at the changes
| package | midcom.helper.datamanager2 |
|---|
Nothing fancy, the actual startup work is done by the initialize call.
booleanIndicating success, false will abort the type construction sequence.| see | \midcom_helper_datamanager2_schema::translate_schema_string() |
|---|
stringThe string to be translated.stringThe translated string.The default implementation works on the default field name, you don't need to override this function unless you have multiple widgets in the form.
This maps to the HTML_QuickForm_element::freeze() function.
You may either return a single value for simple types, or an array of form field name / value pairs in case of composite types. A value of null indicates no applicable default from the type or storage, in which case defaults from the handler or the DM2 schema can be applied.
This default implementation returns null unconditionally.
mixedThe default value as outlined above.Besides other parts in the datamanager framework, nobody should ever have to touch this information.
stringThe key by which this configuration option is referenced.mixedThe configuration value, which is null if the key wasn't found.stringThe name of the field to which this widget is bound.arrayThe configuration data which should be used to customize the widget.\midcom_helper_datamanager2_schemaThe full schema object.\midcom_helper_datamanager2_typeThe type to which we are bound.stringThe namespace to use including the trailing underscore.booleanWhether to load JS and other dependencies on initializebooleanIndicating success. If this is false, the type will be unusable.The default implementation works on the default field name, usually you don't need to override this function unless you have some strange form element logic.
This maps to the HTML_QuickForm_element::isFrozen() function.
booleanTrue if the element is frozen, false otherwise.No Form validation has been done at this point. The event is triggered on all submissions with the exception of the cancel and previous form events.
You should be careful when using this event for data processing therefore. Its main application is the processing of additional buttons placed into the form by the widget.
The implementation of this handler is optional.
arrayThe complete form results, you need to extract all values
relevant for your type yourself.The default implementation calls the type's convert_to_html method.
stringThe rendered HTMLBesides other parts in the datamanager framework, nobody should ever have to touch this information.
stringThe key by which this configuration option is referenced.mixedThe configuration value.\HTMLQuickForm&$form The form to use.stringThe state we're in.The default implementation works on the default field name, you don't need to override this function unless you have multiple widgets in the form.
This maps to the HTML_QuickForm_element::unfreeze() function.
Description texts etc. are taken from here.
| access | protected |
|---|
| access | protected |
|---|
| access | protected |
|---|
This variable will always contain a parsed representation of the schema, so that one can swiftly switch between individual schemas of the Database.
| access | protected |
|---|
| access | protected |
|---|
This maps to the schema's field name. You should never have to change them.
It is deduced by the formmanager and tries to be as smart as possible to work safely with more then one form on a page.
You have to prefix all elements which must be unique using this string (it includes a trailing underscore).
The type should never touch this variable, which is controlled by a corresponding getter/setter pair.
| see | \set_external_config() |
|---|---|
| see | \get_external_config() |