If you follow the right newsgroups ;-) you will know that there has been a will to make Gabriel a system extension, to provide the TYPO3 core with a scheduling feature. I started working on this during T3DD09 and have now reached near completion.
What happened along the way? Mostly the following:
- the API for declaring events was enhanced to make it more flexible and powerful.
- the new autoloader feature was used whenever possible, as it is very appropriate for such a tool.
The base logic of Gabriel was mostly left untouched, as it was running very well anyway.
What remains to be done is mostly clean up and polishing, and of course testing, which you are more than welcome to do. The Scheduler project can be found here:
This is a short description of the API changes. First of all the registration of an event changed. It used to be a simple line, such as:
$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['gabriel']['include'][$_EXTKEY] = 'class.tx_externalimport_autosync.php';
This has now changed to:
$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['scheduler']['include'][$_EXTKEY] = array( 0 => array( 'class' => 'EXT:scheduler/class.tx_externalimport_autosync.php:tx_externalimport_autosync', 'title' => 'LLL:EXT:' . $_EXTKEY . '/locallang.xml:scheduler.title', 'hasArguments' => true, 'argumentsHelp' => 'LLL:EXT:' . $_EXTKEY . '/locallang.xml:scheduler.argumentsHelp' ) );
First of all, it is not allowed to declare a simple string anymore. It must always be an array.
Second this array has gained an extra dimension, which makes it possible to add much more information during event registration. The information that was entered before is now in the "class" property. The "title" property makes it possible to display a human-readable name for each event class, which is used, in particular, in the add/edit form. The "hasArguments" property is a boolean and defines whether this event class can use additional call arguments in the CRID or not (you may well not know of this feature, as it was never documented). Finally, the "argumentsHelp" property point to a localised string that can contain a help text for setting said additional call arguments.
What is more three hooks are now available in the Scheduler to declare additional fields, if your event class needs some. These hooks are:
- additionalFieldsDefinition: provides a list of fields to add to the add/edit form, complete with labels and CSH
- additionalFieldsValidation: special validation rules for a specific event class (to be used for the extra fields, but may perform other special validations too)
- additionalFieldsStorage: stores the extra fields in the event object, normally as member variables
I think all these improvements make the Scheduler even more powerful and useful than it was before. I hope you will be of the same mind.