OpenPSA API Documentation
Back to top  

Datamanager 2 Data Manager object creation controller class.

This class requires a callback that creates the actual object that should be created in a correct way. The implementation contained in this class should be able to avoid ghost object in almost all cases. The only thing that is not fully catchable here are cases where the type validation fails. But since all type validation rules are mappable to QuickForm rules, this problem should not appear.

Temporary objects (as initially created by the nullstorge implementations) will be memorized using a hidden form variable.

Creation callback

The callback is defined using the $callback_object and $callback_method members of this class. Only the first one is mandatory, the method name defaults to dm2_create_callback.

package midcom.helper.datamanager2

 Methods

_cast_to_storage_object ()

cast $storage to a simple midgard storage implementation.

the reference should propagate this. use a callback to work.

initialize (string $identifier)

You need to set the schema database before calling this function.

Optionally you may set defaults and the schemaname to use as well.

Parameters

$identifier

stringThe form identifier

Returns

booleanIndicating success.

process_ajax ()

Process AJAX-style creation requests

process_form ()

This function wraps the form manager processing.

If processing is successful and the form is in 'save'ed state, the storage backend is cast to a standard midgard object, any temporary resources are moved to there, and the formdata is saved.

There are several possible return values:

  • save and the variants next and previous (for wizard usage) suggest successful form processing. The form has already been validated, synchronized with and saved to the data source.
  • cancel the user cancelled the form processing, no I/O has been done.
  • edit, previous, next indicates that the form is not yet successfully completed. This can mean many things, including validation errors, which the renderer already outlines in the Form output. No I/O processing has been done.

The form will be automatically validated for 'save' and 'next', but not for 'previous'.

Normally, all validation should be done during the Form processing, but sometimes this is not possible. These are the cases where type validation rules fail instead of form validation ones. At this time, the integration of type validation is rudimentary and will transparently return edit instead of validation.

todo Integrate type validation checks cleanly.

Returns

stringOne of 'save', 'cancel', 'next', 'previous', 'edit', depending on the schema configuration.

 Properties

 

boolean $ajax_mode

Whether we're in AJAX mode
 

Array $ajax_options

Options to pass for the AJAX controller
 

object $callback_method

The name of the callback method to execute.

This defaults to _dm2_create_callback. If this member is changed, it must be done prior initialization.

 

object $callback_object

A reference to the object containing the creation callback.

This reference must be set prior initialization.

 

Array $defaults

The defaults to initialize the form manager with.

This array is indexed by field names.

 

string $form_identifier

Unique identifier form a creation instance, used mainly in AJAX mode
 

mixed $schemaname

The name of the schema to use.

If this is left to null, the first schema from the database is used instead.

 

boolean $wide_mode

Wide mode switch
 

boolean $window_mode

Window mode switch
 

string $_tmpid_fieldname

The name of the hidden field used to remember the temporary object id.