Feature #4302
closed
Get rid of the "additional parameters"
100%
Description
This is just a thought and I would like your opinion.
A scheduler event is defined by the name of class used to execute it, which is stored (on the database side) in a field called "crid". The class name can be extended with additional parameters, using a syntax like tx_myext_myclass::a=2&b=3. The array ('a' => 2, 'b' => 3) is available as a member variable inside the task's class.
This is a mechanism I introduced into Gabriel a long while ago, when I needed a given task to be called for varying purposes. At the time there was no interface in Gabriel to easily add custom fields when registering a task, so I chose to extend the usage of the crid, since that caused the least changes in Gabriel.
Now there are well-defined way to add fields in the Scheduler task registration form and an API to match. So I'm wondering about dropping that feature of the crid and let it go back to what it used to be, i.e. just the task class name.
The advantages are that the API would be (even) cleaner and the notion of "crid" could removed entirely, being just replaced by "class".
Even for the usage for which I originally introduced this mechanism (extension: external_import) I don't see any real disadvantage.
Opinions?
Updated by Francois Suter about 15 years ago
No feedback, but I will probably go ahead, as I think it's a worthwile cleanup.
Note: seeing a CRID with additional parameters in the list view of the BE module was also useful for distinguishing between various registrations of the same task. To compensate if the CRID is reduced to just the task class, I would add a method to the base task class that can be called by the List module (for example) to display additional information about a given task registration (for example, the test event could return the registered email address). This is just a note, not to forget ;-)
Updated by Francois Suter about 15 years ago
- Status changed from New to Accepted
- Assignee set to Francois Suter
Updated by Francois Suter about 15 years ago
The additional advantage of defining extra fields rather than using the "extended" crid syntax is that a validation is possible on those extra fields, whereas the extended crid syntax could not be checked.
Updated by Francois Suter about 15 years ago
- Status changed from Accepted to Resolved
- % Done changed from 0 to 100
Done in r1151
Note: there's DB and API change => delete all entries in table tx_scheduler_task
Note 2: this patch includes an additional cleanup of method tx_scheduler_module1::listTasks() and its usage. It was just too convenient to do it in the same step (I know, bad boy).
Updated by Francois Suter over 12 years ago
- Status changed from Resolved to Closed
Updated by Michael Stucki almost 11 years ago
- Project changed from 739 to TYPO3 Core
- Category changed from scheduler to scheduler