Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Persistent form: Difference between revisions

From MoodleDocs
No edit summary
(2 intermediate revisions by 2 users not shown)
Line 145: Line 145:


This method is particularily useful when dealing with file managers.
This method is particularily useful when dealing with file managers.
== Grouping fields ==
There is a little bit of work to do when you want to group some properties together. Let's imagine that we are asking our users to pick amongst a few verbs and food. They can only tell us if they like or dislike something and what it is. Our form should display both the verb and the food next to each other, and to do so we need to use a group.
First, let's update our persistent with the new two values we will store:
<code php>
protected static function define_properties() {
    ...
        'verb' => array(
            'type' => PARAM_ALPHANUM,
            'default' => 'love'
        ),
        'food' => array(
            'type' => PARAM_ALPHANUM,
            'default' => 'pizza'
        )
    ...
}
</code>
Secondly, we must add the group to the form:
<code php>
public function definition() {
    ...
    // Food I like.
    $elements = [];
    $elements[] = $mform->createElement('select', 'verb', 'verb', [
        'hate' => 'I hate',
        'dislike' => 'I dislike',
        'like' => 'I like',
        'love' => 'I love'
    ]);
    $elements[] = $mform->createElement('select', 'food', 'Food', [
        'egg' => 'Egg',
        'tofu' => 'Tofu',
        'chicken' => 'Chicken',
        'fish' => 'Fish',
        'pizza' => 'Pizza'
    ]);
    $mform->addElement('group', 'foodilike', 'Food I like', $elements);
    ...
}
</code>
If you were to try the code like this, you would get an error telling you that the persistent did not expect to receive the property ''foodilike''. That's normal because the group is being set to the persistent which does not know what to do with it. In order to counter this we will need to convert the group to individual properties by extending the method ''convert_fields(stdClass $data)''.
<code php>
/**
* Convert fields.
*
* @param stdClass $data The data.
* @return stdClass
*/
protected static function convert_fields(stdClass $data) {
    $data = parent::convert_fields($data);
    // Convert the group to single properties.
    $data->verb = $data->foodilike['verb'];
    $data->food = $data->foodilike['food'];
    unset($data->foodilike);
    return $data;
}
</code>
Now it works because we've converted our group to individual properties. Note that you must call the parent method because we're automatically doing the same thing for you when you're using a text editor field.
While this works fine, this is not enough as when we load an existing object we must perform the same thing the other way around. We must convert the fields from our persistent to what the group field is expecting. To do so we override the method ''get_default_value()''. We're also taking care of the text editor for you here so don't forget to call the parent.
<code php>
/**
* Get the default data.
*
* @return stdClass
*/
protected function get_default_data() {
    $data = parent::get_default_data();
    // Convert the single properties into a group.
    $data->foodilike = [
        'verb' => $data->verb,
        'food' => $data->food,
    ];
    unset($data->verb);
    unset($data->food);
    return $data;
}
</code>
You should now notice that the default values are set to "I love" and "Pizza". And we're done!


== Examples ==
== Examples ==
Line 297: Line 395:
echo $OUTPUT->footer();
echo $OUTPUT->footer();
</code>
</code>
== See also ==
* [[Persistent]]
* [[Exporter]]

Revision as of 14:25, 9 April 2017

Moodle 3.3 If you are creating persistent entries from forms, we've got something for you. You can use the class core\form\persistent as a base for your form instead of moodleform. Our persistent form class comes handy tools, such as automatic validation.

Note: for more information about forms themselves, head this way.

Linking to a persistent

In order for the form class to know what persistent we'll be dealing with, we must declare the protected static $persistentclass variable. The latter contains the fully qualified name of the persistent class.

/** @var string Persistent class name. */ protected static $persistentclass = 'example\\status';

Defining the form fields

Unfortunately this is not automatically done for us, so let's add our fields to the definition() method like you would do for any form.

/**

* Define the form.
*/

public function definition() {

   $mform = $this->_form;
   // User ID.
   $mform->addElement('hidden', 'userid');
   $mform->setConstant('userid', $this->_customdata['userid']);
   // Message.
   $mform->addElement('editor', 'message', 'Message');
   // Location.
   $mform->addElement('text', 'location', 'Location');
   $this->add_action_buttons();

}

All of this is pretty standard, except for the userid. When creating a new 'status', we do not want our users to be in control of this value. Therefore we define it as a hidden value which we lock (using setConstant) to the value we created our form with. All the mandatory fields (without a default value) of the persistent need to be added to the form. If your users cannot change their values, then they must be hidden and locked with setConstant.

Did you notice that there isn't any call to setType in the above example? That is because we automatically do it for you based on the field name and your persistent's properties.

Also note that the id property is not included. It is not required, nor recommended, to add it to your fields as it will be handled automatically.

Using the form

When instantiating the form, there are two little things that you need to pay attention to.

Firstly you should always pass the URL of the current page, including its query parameters. We need this to be able to display the form with its validation errors without affecting anything else.

Secondly, the persistent instance must be provided to the form through the custom data. That persistent instance will be used to populate the form with initial data, typically when you are editing an object. When you don't have a persistent instance yet, probably because your user will be creating a new one, then simply pass null.

$customdata = [

   'persistent' => $persistent,  // An instance, or null.
   'userid' => $USER->id         // For the hidden userid field.

]; $form = new status_form($PAGE->url->out(false), $customdata);

Just like any other form, we will be using get_data() to validate the form. The only difference is that to determine whether we are editing an object, or creating a new one, we will check if the id value was returned to us. The persistent form will return the ID value from the persistent we gave it. Then it's up to you to decide how to apply the data, most likely you will defer the logic to another part of your code, one that ensures that all capability checks are fulfilled.

// Get the data. This ensures that the form was validated. if (($data = $form->get_data())) {

   if (empty($data->id)) {
       // If we don't have an ID, we know that we must create a new record.
       // Call your API to create a new persistent from this data.
       // Or, do the following if you don't want capability checks (discouraged).
       $persistent = new status(0, $data);
       $persistent->create();
   } else {
       // We had an ID, this means that we are going to update a record.
       // Call your API to update the persistent from the data.
       // Or, do the following if you don't want capability checks (discouraged).
       $persistent->from_record($data);
       $persistent->update();
   }
   // We are done, so let's redirect somewhere.
   redirect(new moodle_url('/'));

}

Additional validation

There are times when the built-in validation of the persistent is not enough. Usually you would use the method validation(), but as the form persistent class does some extra stuff to make it easier for you, you must use the extra_validation() method. The latter works almost just like the validation() one.

/**

* Extra validation.
*
* @param  stdClass $data Data to validate.
* @param  array $files Array of files.
* @param  array $errors Currently reported errors.
* @return array of additional errors, or overridden errors.
*/

protected function extra_validation($data, $files, array &$errors) {

   $newerrors = array();
   if ($data->location === 'SFO') {
       $newerrors['location'] = 'San-Francisco Airport is not accepted from the form.';
   }
   return $newerrors;

}

The typical additional validation will return an array of errors, those will override any previously defined errors. Sometimes, though rarely, you will need to remove previously reported errors, hence the reference to $errors given, which you can modify directly. Do not abuse it though, this should only be used when you have no other choice.

Foreign fields

By default, the form class tries to be smart at detecting foreign fields such as the submit button. Failure to do so will cause troubles during validation, or when getting the data. So when your form becomes more complex, if it includes more submit buttons, or when it deals with other fields, for example file managers, we must indicate it.

Fields to ignore completely

The fields to remove are never validated and they are not returned when calling get_data(). By default the submit button is added to this list so that when we call get_data() we only get the persistent-related fields. To remove more fields, re-declare the protected static $fieldstoremove class variable.

/** @var array Fields to remove when getting the final data. */ protected static $fieldstoremove = array('submitbutton', 'areyouhappy');

Do not forget to add the submitbutton back in there.

Fields to validate

What about when we have a legit field but it does not belong to the persistent? We still want to validate it ourselves, but we don't want it to be validated by the persistent as it will cause an error. In that case we define it in the protected static $foreignfields class variable.

/** @var array Fields to remove from the persistent validation. */ protected static $foreignfields = array('updatedelay');

Now the persistent will not validate this field, and we will get the updatedelay value when we call get_data(). Just don't forget to remove it before you feed the data to your persistent.

if (($data = $form->get_data())) {

   $updatedelay = $data->updatedelay;
   unset($data->updatedelay);
   $newpersistent = new status(0, $data);

}

This method is particularily useful when dealing with file managers.

Grouping fields

There is a little bit of work to do when you want to group some properties together. Let's imagine that we are asking our users to pick amongst a few verbs and food. They can only tell us if they like or dislike something and what it is. Our form should display both the verb and the food next to each other, and to do so we need to use a group.

First, let's update our persistent with the new two values we will store:

protected static function define_properties() {

   ...
       'verb' => array(
           'type' => PARAM_ALPHANUM,
           'default' => 'love'
       ),
       'food' => array(
           'type' => PARAM_ALPHANUM,
           'default' => 'pizza'
       )
   ...

}

Secondly, we must add the group to the form:

public function definition() {

   ...
   // Food I like.
   $elements = [];
   $elements[] = $mform->createElement('select', 'verb', 'verb', [
       'hate' => 'I hate',
       'dislike' => 'I dislike',
       'like' => 'I like',
       'love' => 'I love'
   ]);
   $elements[] = $mform->createElement('select', 'food', 'Food', [
       'egg' => 'Egg',
       'tofu' => 'Tofu',
       'chicken' => 'Chicken',
       'fish' => 'Fish',
       'pizza' => 'Pizza'
   ]);
   $mform->addElement('group', 'foodilike', 'Food I like', $elements);
   ...

}

If you were to try the code like this, you would get an error telling you that the persistent did not expect to receive the property foodilike. That's normal because the group is being set to the persistent which does not know what to do with it. In order to counter this we will need to convert the group to individual properties by extending the method convert_fields(stdClass $data).

/**

* Convert fields.
*
* @param stdClass $data The data.
* @return stdClass
*/

protected static function convert_fields(stdClass $data) {

   $data = parent::convert_fields($data);
   // Convert the group to single properties.
   $data->verb = $data->foodilike['verb'];
   $data->food = $data->foodilike['food'];
   unset($data->foodilike);
   return $data;

}

Now it works because we've converted our group to individual properties. Note that you must call the parent method because we're automatically doing the same thing for you when you're using a text editor field.

While this works fine, this is not enough as when we load an existing object we must perform the same thing the other way around. We must convert the fields from our persistent to what the group field is expecting. To do so we override the method get_default_value(). We're also taking care of the text editor for you here so don't forget to call the parent.

/**

* Get the default data.
*
* @return stdClass
*/

protected function get_default_data() {

   $data = parent::get_default_data();
   // Convert the single properties into a group.
   $data->foodilike = [
       'verb' => $data->verb,
       'food' => $data->food,
   ];
   unset($data->verb);
   unset($data->food);
   return $data;

}

You should now notice that the default values are set to "I love" and "Pizza". And we're done!

Examples

Minimalist

class status_form extends \core\form\persistent {

   /** @var string Persistent class name. */
   protected static $persistentclass = 'example\\status';
   /**
    * Define the form.
    */
   public function definition() {
       $mform = $this->_form;
       // User ID.
       $mform->addElement('hidden', 'userid');
       $mform->setConstant('userid', $this->_customdata['userid']);
       // Message.
       $mform->addElement('editor', 'message', 'Message');
       // Location.
       $mform->addElement('text', 'location', 'Location');
       $this->add_action_buttons();
   }

}

More advanced

class status_form extends \core\form\persistent {

   /** @var string Persistent class name. */
   protected static $persistentclass = 'example\\status';
   /** @var array Fields to remove when getting the final data. */
   protected static $fieldstoremove = array('submitbutton', 'areyouhappy');
   /** @var array Fields to remove from the persistent validation. */
   protected static $foreignfields = array('updatedelay');
   /**
    * Define the form.
    */
   public function definition() {
       $mform = $this->_form;
       // User ID.
       $mform->addElement('hidden', 'userid');
       $mform->setConstant('userid', $this->_customdata['userid']);
       // Message.
       $mform->addElement('editor', 'message', 'Message');
       // Location.
       $mform->addElement('text', 'location', 'Location');
       // Status update delay.
       $mform->addElement('duration', 'updatedelay', 'Status update delay');
       // Are you happy?
       $mform->addElement('selectyesno', 'areyouhappy', 'Are you happy?');
       $this->add_action_buttons();
   }
   /**
    * Extra validation.
    *
    * @param  stdClass $data Data to validate.
    * @param  array $files Array of files.
    * @param  array $errors Currently reported errors.
    * @return array of additional errors, or overridden errors.
    */
   protected function extra_validation($data, $files, array &$errors) {
       $newerrors = array();
       if ($data->location === 'SFO') {
           $newerrors['location'] = 'San-Francisco Airport is not accepted from the form.';
       }
       return $newerrors;
   }

}

Using the form

Consider the following code to be a page the users will access at '/example.php'.

require 'config.php';

// Check if we go an ID. $id = optional_param('id', null, PARAM_INT);

// Set the PAGE URL (and mandatory context). Note the ID being recorded, this is important. $PAGE->set_context(context_system::instance()); $PAGE->set_url(new moodle_url('/example.php', ['id' => $id]));

// Instantiate a persistent object if we received an ID. Typically receiving an ID // means that we are going to be updating an object rather than creating a new one. $persistent = null; if (!e mpty($id)) {

   $persistent = new status($id);

}

// Create the form instance. We need to use the current URL and the custom data. $customdata = [

   'persistent' => $persistent,
   'userid' => $USER->id         // For the hidden userid field.

]; $form = new status_form($PAGE->url->out(false), $customdata);

// Get the data. This ensures that the form was validated. if (($data = $form->get_data())) {

   try {
       if (empty($data->id)) {
           // If we don't have an ID, we know that we must create a new record.
           // Call your API to create a new persistent from this data.
           // Or, do the following if you don't want capability checks (discouraged).
           $persistent = new status(0, $data);
           $persistent->create();
       } else {
           // We had an ID, this means that we are going to update a record.
           // Call your API to update the persistent from the data.
           // Or, do the following if you don't want capability checks (discouraged).
           $persistent->from_record($data);
           $persistent->update();
       }
       \core\notification::success(get_string('changessaved'));
   } catch (Exception $e) {
       \core\notification::error($e->getMessage());
   }
   // We are done, so let's redirect somewhere.
   redirect(new moodle_url('/'));

}

// Display the mandatory header and footer. // And display the form, and its validation errors if there are any. echo $OUTPUT->header(); $form->display(); echo $OUTPUT->footer();

See also