KumiSystems/moodle-local_mycerts
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
moodle-local_mycerts/edit_element.php

101 lines
3.6 KiB
PHP
Raw Normal View History

Completely refactored the code for editing a custom certificate The elements for each page are listed in a table below the other page settings, meaning each page has a separate table for listing their elements. Each element is now edited in a pop-up, rather than having all the element settings displayed at once on the form causing it to look overcrowded. There is also no longer any need for the function add_element to add default values for the elements when they are added, as a a form is shown when you click to add an element where you can enter the values before it is created. Note: I did not create a db/upgrade.php script to add the new database columns as this module should not be currently used by anyone.
2013-06-06 10:59:08 +00:00
<?php
// This file is part of the customcert module for Moodle - http://moodle.org/
//
// Moodle is free software: you can redistribute it and/or modify
// it under the terms of the GNU General Public License as published by
// the Free Software Foundation, either version 3 of the License, or
// (at your option) any later version.
//
// Moodle is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
// GNU General Public License for more details.
//
// You should have received a copy of the GNU General Public License
Changed PHPDocs and added date to the copyright to match Moodle coding guidelines
2013-07-22 05:06:18 +00:00
// along with Moodle. If not, see <http://www.gnu.org/licenses/>.
Completely refactored the code for editing a custom certificate The elements for each page are listed in a table below the other page settings, meaning each page has a separate table for listing their elements. Each element is now edited in a pop-up, rather than having all the element settings displayed at once on the form causing it to look overcrowded. There is also no longer any need for the function add_element to add default values for the elements when they are added, as a a form is shown when you click to add an element where you can enter the values before it is created. Note: I did not create a db/upgrade.php script to add the new database columns as this module should not be currently used by anyone.
2013-06-06 10:59:08 +00:00
/**
* Edit a customcert element.
*
* @package mod_customcert
Changed PHPDocs and added date to the copyright to match Moodle coding guidelines
2013-07-22 05:06:18 +00:00
* @copyright 2013 Mark Nelson <markn@moodle.com>
Completely refactored the code for editing a custom certificate The elements for each page are listed in a table below the other page settings, meaning each page has a separate table for listing their elements. Each element is now edited in a pop-up, rather than having all the element settings displayed at once on the form causing it to look overcrowded. There is also no longer any need for the function add_element to add default values for the elements when they are added, as a a form is shown when you click to add an element where you can enter the values before it is created. Note: I did not create a db/upgrade.php script to add the new database columns as this module should not be currently used by anyone.
2013-06-06 10:59:08 +00:00
* @license http://www.gnu.org/copyleft/gpl.html GNU GPL v3 or later
*/
require_once('../../config.php');
Huge refactor 1) Every certificate is a template. Before a user would create a certificate then had the option to save it as a template. This could potentially be chaotic with numerous users creating templates, making the template system a mess. Now, rather than creating a certificate first, then saving it as a template, you are always creating a template. Each template is associated with a context, so depending on where you are creating it the context is different. This means users in the CONTEXT_MODULE context are creating a template specific to that module, where as a user creating a template in the CONTEXT_SYSTEM context would be creating a general template that can be used by others. This meant we can remove the 'customcert_template_*' db tables. Yay - no duplicated tables. 2) Created new helper classes and moved functionality there. 3) Moved files to classes/ for autoloading. 4) General tidy up.
2016-02-16 09:03:34 +00:00
$tid = required_param('tid', PARAM_INT);
Completely refactored the code for editing a custom certificate The elements for each page are listed in a table below the other page settings, meaning each page has a separate table for listing their elements. Each element is now edited in a pop-up, rather than having all the element settings displayed at once on the form causing it to look overcrowded. There is also no longer any need for the function add_element to add default values for the elements when they are added, as a a form is shown when you click to add an element where you can enter the values before it is created. Note: I did not create a db/upgrade.php script to add the new database columns as this module should not be currently used by anyone.
2013-06-06 10:59:08 +00:00
$action = required_param('action', PARAM_ALPHA);
Huge refactor 1) Every certificate is a template. Before a user would create a certificate then had the option to save it as a template. This could potentially be chaotic with numerous users creating templates, making the template system a mess. Now, rather than creating a certificate first, then saving it as a template, you are always creating a template. Each template is associated with a context, so depending on where you are creating it the context is different. This means users in the CONTEXT_MODULE context are creating a template specific to that module, where as a user creating a template in the CONTEXT_SYSTEM context would be creating a general template that can be used by others. This meant we can remove the 'customcert_template_*' db tables. Yay - no duplicated tables. 2) Created new helper classes and moved functionality there. 3) Moved files to classes/ for autoloading. 4) General tidy up.
2016-02-16 09:03:34 +00:00
$template = $DB->get_record('customcert_templates', array('id' => $tid), '*', MUST_EXIST);
// Set the template object.
$template = new \mod_customcert\template($template);
// Perform checks.
if ($cm = $template->get_cm()) {
require_login($cm->course, false, $cm);
} else {
require_login();
}
// Make sure the user has the required capabilities.
$template->require_manage();
Completely refactored the code for editing a custom certificate The elements for each page are listed in a table below the other page settings, meaning each page has a separate table for listing their elements. Each element is now edited in a pop-up, rather than having all the element settings displayed at once on the form causing it to look overcrowded. There is also no longer any need for the function add_element to add default values for the elements when they are added, as a a form is shown when you click to add an element where you can enter the values before it is created. Note: I did not create a db/upgrade.php script to add the new database columns as this module should not be currently used by anyone.
2013-06-06 10:59:08 +00:00
if ($action == 'edit') {
// The id of the element must be supplied if we are currently editing one.
$id = required_param('id', PARAM_INT);
$element = $DB->get_record('customcert_elements', array('id' => $id), '*', MUST_EXIST);
Huge refactor 1) Every certificate is a template. Before a user would create a certificate then had the option to save it as a template. This could potentially be chaotic with numerous users creating templates, making the template system a mess. Now, rather than creating a certificate first, then saving it as a template, you are always creating a template. Each template is associated with a context, so depending on where you are creating it the context is different. This means users in the CONTEXT_MODULE context are creating a template specific to that module, where as a user creating a template in the CONTEXT_SYSTEM context would be creating a general template that can be used by others. This meant we can remove the 'customcert_template_*' db tables. Yay - no duplicated tables. 2) Created new helper classes and moved functionality there. 3) Moved files to classes/ for autoloading. 4) General tidy up.
2016-02-16 09:03:34 +00:00
$pageurl = new moodle_url('/mod/customcert/edit_element.php', array('id' => $id, 'tid' => $tid, 'action' => $action));
Completely refactored the code for editing a custom certificate The elements for each page are listed in a table below the other page settings, meaning each page has a separate table for listing their elements. Each element is now edited in a pop-up, rather than having all the element settings displayed at once on the form causing it to look overcrowded. There is also no longer any need for the function add_element to add default values for the elements when they are added, as a a form is shown when you click to add an element where you can enter the values before it is created. Note: I did not create a db/upgrade.php script to add the new database columns as this module should not be currently used by anyone.
2013-06-06 10:59:08 +00:00
} else { // Must be adding an element.
Huge refactor 1) Every certificate is a template. Before a user would create a certificate then had the option to save it as a template. This could potentially be chaotic with numerous users creating templates, making the template system a mess. Now, rather than creating a certificate first, then saving it as a template, you are always creating a template. Each template is associated with a context, so depending on where you are creating it the context is different. This means users in the CONTEXT_MODULE context are creating a template specific to that module, where as a user creating a template in the CONTEXT_SYSTEM context would be creating a general template that can be used by others. This meant we can remove the 'customcert_template_*' db tables. Yay - no duplicated tables. 2) Created new helper classes and moved functionality there. 3) Moved files to classes/ for autoloading. 4) General tidy up.
2016-02-16 09:03:34 +00:00
// We need to supply what element we want added to what page.
Completely refactored the code for editing a custom certificate The elements for each page are listed in a table below the other page settings, meaning each page has a separate table for listing their elements. Each element is now edited in a pop-up, rather than having all the element settings displayed at once on the form causing it to look overcrowded. There is also no longer any need for the function add_element to add default values for the elements when they are added, as a a form is shown when you click to add an element where you can enter the values before it is created. Note: I did not create a db/upgrade.php script to add the new database columns as this module should not be currently used by anyone.
2013-06-06 10:59:08 +00:00
$pageid = required_param('pageid', PARAM_INT);
$element = new stdClass();
$element->element = required_param('element', PARAM_ALPHA);
Huge refactor 1) Every certificate is a template. Before a user would create a certificate then had the option to save it as a template. This could potentially be chaotic with numerous users creating templates, making the template system a mess. Now, rather than creating a certificate first, then saving it as a template, you are always creating a template. Each template is associated with a context, so depending on where you are creating it the context is different. This means users in the CONTEXT_MODULE context are creating a template specific to that module, where as a user creating a template in the CONTEXT_SYSTEM context would be creating a general template that can be used by others. This meant we can remove the 'customcert_template_*' db tables. Yay - no duplicated tables. 2) Created new helper classes and moved functionality there. 3) Moved files to classes/ for autoloading. 4) General tidy up.
2016-02-16 09:03:34 +00:00
$pageurl = new moodle_url('/mod/customcert/edit_element.php', array('tid' => $tid, 'element' => $element->element,
'pageid' => $pageid, 'action' => $action));
Completely refactored the code for editing a custom certificate The elements for each page are listed in a table below the other page settings, meaning each page has a separate table for listing their elements. Each element is now edited in a pop-up, rather than having all the element settings displayed at once on the form causing it to look overcrowded. There is also no longer any need for the function add_element to add default values for the elements when they are added, as a a form is shown when you click to add an element where you can enter the values before it is created. Note: I did not create a db/upgrade.php script to add the new database columns as this module should not be currently used by anyone.
2013-06-06 10:59:08 +00:00
}
Huge refactor 1) Every certificate is a template. Before a user would create a certificate then had the option to save it as a template. This could potentially be chaotic with numerous users creating templates, making the template system a mess. Now, rather than creating a certificate first, then saving it as a template, you are always creating a template. Each template is associated with a context, so depending on where you are creating it the context is different. This means users in the CONTEXT_MODULE context are creating a template specific to that module, where as a user creating a template in the CONTEXT_SYSTEM context would be creating a general template that can be used by others. This meant we can remove the 'customcert_template_*' db tables. Yay - no duplicated tables. 2) Created new helper classes and moved functionality there. 3) Moved files to classes/ for autoloading. 4) General tidy up.
2016-02-16 09:03:34 +00:00
// Set up the page.
$title = get_string('editelement', 'customcert');
\mod_customcert\page_helper::page_setup($pageurl, $template->get_context(), $title);
Completely refactored the code for editing a custom certificate The elements for each page are listed in a table below the other page settings, meaning each page has a separate table for listing their elements. Each element is now edited in a pop-up, rather than having all the element settings displayed at once on the form causing it to look overcrowded. There is also no longer any need for the function add_element to add default values for the elements when they are added, as a a form is shown when you click to add an element where you can enter the values before it is created. Note: I did not create a db/upgrade.php script to add the new database columns as this module should not be currently used by anyone.
2013-06-06 10:59:08 +00:00
Huge refactor 1) Every certificate is a template. Before a user would create a certificate then had the option to save it as a template. This could potentially be chaotic with numerous users creating templates, making the template system a mess. Now, rather than creating a certificate first, then saving it as a template, you are always creating a template. Each template is associated with a context, so depending on where you are creating it the context is different. This means users in the CONTEXT_MODULE context are creating a template specific to that module, where as a user creating a template in the CONTEXT_SYSTEM context would be creating a general template that can be used by others. This meant we can remove the 'customcert_template_*' db tables. Yay - no duplicated tables. 2) Created new helper classes and moved functionality there. 3) Moved files to classes/ for autoloading. 4) General tidy up.
2016-02-16 09:03:34 +00:00
// Additional page setup.
if ($template->get_context()->contextlevel == CONTEXT_SYSTEM) {
$PAGE->navbar->add(get_string('managetemplates', 'customcert'),
new moodle_url('/mod/customcert/manage_templates.php'));
}
$PAGE->navbar->add(get_string('editcustomcert', 'customcert'), new moodle_url('/mod/customcert/edit.php',
array('tid' => $tid)));
$PAGE->navbar->add($title);
Completely refactored the code for editing a custom certificate The elements for each page are listed in a table below the other page settings, meaning each page has a separate table for listing their elements. Each element is now edited in a pop-up, rather than having all the element settings displayed at once on the form causing it to look overcrowded. There is also no longer any need for the function add_element to add default values for the elements when they are added, as a a form is shown when you click to add an element where you can enter the values before it is created. Note: I did not create a db/upgrade.php script to add the new database columns as this module should not be currently used by anyone.
2013-06-06 10:59:08 +00:00
Huge refactor 1) Every certificate is a template. Before a user would create a certificate then had the option to save it as a template. This could potentially be chaotic with numerous users creating templates, making the template system a mess. Now, rather than creating a certificate first, then saving it as a template, you are always creating a template. Each template is associated with a context, so depending on where you are creating it the context is different. This means users in the CONTEXT_MODULE context are creating a template specific to that module, where as a user creating a template in the CONTEXT_SYSTEM context would be creating a general template that can be used by others. This meant we can remove the 'customcert_template_*' db tables. Yay - no duplicated tables. 2) Created new helper classes and moved functionality there. 3) Moved files to classes/ for autoloading. 4) General tidy up.
2016-02-16 09:03:34 +00:00
$mform = new \mod_customcert\edit_element_form($pageurl, array('element' => $element));
Completely refactored the code for editing a custom certificate The elements for each page are listed in a table below the other page settings, meaning each page has a separate table for listing their elements. Each element is now edited in a pop-up, rather than having all the element settings displayed at once on the form causing it to look overcrowded. There is also no longer any need for the function add_element to add default values for the elements when they are added, as a a form is shown when you click to add an element where you can enter the values before it is created. Note: I did not create a db/upgrade.php script to add the new database columns as this module should not be currently used by anyone.
2013-06-06 10:59:08 +00:00
// Check if they cancelled.
if ($mform->is_cancelled()) {
Huge refactor 1) Every certificate is a template. Before a user would create a certificate then had the option to save it as a template. This could potentially be chaotic with numerous users creating templates, making the template system a mess. Now, rather than creating a certificate first, then saving it as a template, you are always creating a template. Each template is associated with a context, so depending on where you are creating it the context is different. This means users in the CONTEXT_MODULE context are creating a template specific to that module, where as a user creating a template in the CONTEXT_SYSTEM context would be creating a general template that can be used by others. This meant we can remove the 'customcert_template_*' db tables. Yay - no duplicated tables. 2) Created new helper classes and moved functionality there. 3) Moved files to classes/ for autoloading. 4) General tidy up.
2016-02-16 09:03:34 +00:00
$url = new moodle_url('/mod/customcert/edit.php', array('tid' => $tid));
Removed the pop-up when editing an element to conform to Moodle standards
2013-07-23 07:19:55 +00:00
redirect($url);
Completely refactored the code for editing a custom certificate The elements for each page are listed in a table below the other page settings, meaning each page has a separate table for listing their elements. Each element is now edited in a pop-up, rather than having all the element settings displayed at once on the form causing it to look overcrowded. There is also no longer any need for the function add_element to add default values for the elements when they are added, as a a form is shown when you click to add an element where you can enter the values before it is created. Note: I did not create a db/upgrade.php script to add the new database columns as this module should not be currently used by anyone.
2013-06-06 10:59:08 +00:00
}
if ($data = $mform->get_data()) {
// Set the id, or page id depending on if we are editing an element, or adding a new one.
if ($action == 'edit') {
$data->id = $id;
} else {
$data->pageid = $pageid;
}
// Set the element variable.
$data->element = $element->element;
// Get an instance of the element class.
Huge refactor 1) Every certificate is a template. Before a user would create a certificate then had the option to save it as a template. This could potentially be chaotic with numerous users creating templates, making the template system a mess. Now, rather than creating a certificate first, then saving it as a template, you are always creating a template. Each template is associated with a context, so depending on where you are creating it the context is different. This means users in the CONTEXT_MODULE context are creating a template specific to that module, where as a user creating a template in the CONTEXT_SYSTEM context would be creating a general template that can be used by others. This meant we can remove the 'customcert_template_*' db tables. Yay - no duplicated tables. 2) Created new helper classes and moved functionality there. 3) Moved files to classes/ for autoloading. 4) General tidy up.
2016-02-16 09:03:34 +00:00
if ($e = \mod_customcert\element::instance($data)) {
Completely refactored the code for editing a custom certificate The elements for each page are listed in a table below the other page settings, meaning each page has a separate table for listing their elements. Each element is now edited in a pop-up, rather than having all the element settings displayed at once on the form causing it to look overcrowded. There is also no longer any need for the function add_element to add default values for the elements when they are added, as a a form is shown when you click to add an element where you can enter the values before it is created. Note: I did not create a db/upgrade.php script to add the new database columns as this module should not be currently used by anyone.
2013-06-06 10:59:08 +00:00
$e->save_form_elements($data);
}
Removed the pop-up when editing an element to conform to Moodle standards
2013-07-23 07:19:55 +00:00
Huge refactor 1) Every certificate is a template. Before a user would create a certificate then had the option to save it as a template. This could potentially be chaotic with numerous users creating templates, making the template system a mess. Now, rather than creating a certificate first, then saving it as a template, you are always creating a template. Each template is associated with a context, so depending on where you are creating it the context is different. This means users in the CONTEXT_MODULE context are creating a template specific to that module, where as a user creating a template in the CONTEXT_SYSTEM context would be creating a general template that can be used by others. This meant we can remove the 'customcert_template_*' db tables. Yay - no duplicated tables. 2) Created new helper classes and moved functionality there. 3) Moved files to classes/ for autoloading. 4) General tidy up.
2016-02-16 09:03:34 +00:00
$url = new moodle_url('/mod/customcert/edit.php', array('tid' => $tid));
Removed the pop-up when editing an element to conform to Moodle standards
2013-07-23 07:19:55 +00:00
redirect($url);
Completely refactored the code for editing a custom certificate The elements for each page are listed in a table below the other page settings, meaning each page has a separate table for listing their elements. Each element is now edited in a pop-up, rather than having all the element settings displayed at once on the form causing it to look overcrowded. There is also no longer any need for the function add_element to add default values for the elements when they are added, as a a form is shown when you click to add an element where you can enter the values before it is created. Note: I did not create a db/upgrade.php script to add the new database columns as this module should not be currently used by anyone.
2013-06-06 10:59:08 +00:00
}
echo $OUTPUT->header();
Huge refactor 1) Every certificate is a template. Before a user would create a certificate then had the option to save it as a template. This could potentially be chaotic with numerous users creating templates, making the template system a mess. Now, rather than creating a certificate first, then saving it as a template, you are always creating a template. Each template is associated with a context, so depending on where you are creating it the context is different. This means users in the CONTEXT_MODULE context are creating a template specific to that module, where as a user creating a template in the CONTEXT_SYSTEM context would be creating a general template that can be used by others. This meant we can remove the 'customcert_template_*' db tables. Yay - no duplicated tables. 2) Created new helper classes and moved functionality there. 3) Moved files to classes/ for autoloading. 4) General tidy up.
2016-02-16 09:03:34 +00:00
echo $OUTPUT->heading(get_string('editelement', 'customcert'));
Completely refactored the code for editing a custom certificate The elements for each page are listed in a table below the other page settings, meaning each page has a separate table for listing their elements. Each element is now edited in a pop-up, rather than having all the element settings displayed at once on the form causing it to look overcrowded. There is also no longer any need for the function add_element to add default values for the elements when they are added, as a a form is shown when you click to add an element where you can enter the values before it is created. Note: I did not create a db/upgrade.php script to add the new database columns as this module should not be currently used by anyone.
2013-06-06 10:59:08 +00:00
$mform->display();
echo $OUTPUT->footer();
Reference in a new issue Copy permalink