Apologies for the delays in my replies - I've had a busy couple of days.
Looking at this code, I'm not sure why your submission event isn't being called at present. It looks correct to me at a glance.
I assume you've tried stepping through with the JS debugger to make sure that the event is actually added. If you add a breakpoint on the eventHandlers.push and walk over, you can be sure. You can also run the following in your JS console to see those handlers (you'll need to be paused in the correct context in order to do so):
this.eventHandlers
My first guess though would be that you're not providing the correct formid to the init function. If you add a breakpoint at the this.form line, and then check what formid you're getting I think you'll find that formid is an object containing a formid. Normally we call this params, or args, or something. Personally, I quite like using the Y.Base class which includes a feature called Y.Attribute, but we'll leave that for another time for the moment as it complicates things somewhat.
So perhaps, try changing your code to:
init: function(args) {
console.log(args);
this.form = Y.one('#' + args.formid);
if (!this.form) {
Y.log('The form identified by ' + args.formid + ' could not be found. Bailing', 'warn', 'moodle-mod_mediasite-search');
return;
}
// Add the submission events:
this.eventHandlers.push(
this.form.on('submit', this.handleSubmission, this);
);
},
handleSubmission: function(e) {
Y.log('Handling a submission event', 'debug', 'moodle-mod_mediasite-search');
// We must prevent the default browser action, otherwise the browser will redirect.
e.preventDefault();
}
You'll notice that I've used Y.log in a few places here. Y.log is filtered by YUI such that messages are not displayed when you do not have DEBUG_DEVELOPER set as your Moodle DEBUG setting. You may also know this setting as:
$CFG->debug = (E_ALL | E_STRICT);
The second argument to Y.log is the log category/level - choices are debug, info, warn, and error. The third argument is the source - this should be the module name. I'm writing some changes to make debugging easier at the moment which will utilise these more. It will mean that when your'e debugging your own module, you only get the messages you care about which should make life much easier.
You'll also notice that I've called preventDefault() on the event in handleSubmission. Without this, the page will submit anyway. See https://developer.mozilla.org/en-US/docs/Web/Reference/Events/submit for more information on the submit event.
Regarding your other question on how to use Y.io to submit the form, I've not tried this myself, but there is documentation on the YUI docs page. See http://yuilibrary.com/yui/docs/io/#serializing-html-form-as-data for more information. You're particularly interested in the form object being passed in the configuration. This is documented at http://yuilibrary.com/yui/docs/api/classes/IO.html#method_send.
You'll also want to take a peek at how we handle errors returned by IO requests. Here's an example of how we do so in Moodle in other places: https://github.com/moodle/moodle/blob/master/lib/yui/src/tooltip/js/tooltip.js#L372.
In order for the JS to realistically parse the content, you need to return a JSON object structure. This is easily achieved with a combination of adding the following to your AJAX script (the PHP side) before you require the Moodle configuration:
define('AJAX_SCRIPT', true);
And when you output content, add your return data to an Array or stdClass and return it with
echo json_encode($return);
Again, you can see an example of a basic Moodle AJAX script at https://github.com/moodle/moodle/blob/master/lib/help_ajax.php.
By doing this, you'll see that any Exceptions thrown by Moodle are correctly encoded and displayed in a dialogue to the user. Additionally, if the return value is not JSON, a message is displayed to the user.
Hope that this helps,
Andrew
