Bug #4267
closed
Registration for classes that provide additional fields does not bind those classes to specific task types
Added by Ingo Renner over 15 years ago.
Updated almost 11 years ago.
Description
Current you register a class to provide additional task editing fields like this:
$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['scheduler']['additionalFields'][] = 'tx_solr_scheduler_OptimizeTaskSolrServerField';
This does not bind the class to a specific task and thus the class needs to check whether it's called for the task it is meant to provide the additional fields for. This check can be saved by binding these field providers to respective tasks:
$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['scheduler']['additionalFields']['optimizeTask'][] = 'tx_solr_scheduler_OptimizeTaskSolrServerField';
By doing so we would move the check for additional field providers from external extensions to the scheduler where it makes more sense instead of having each field provider having to check the task. I don't think it'd be a performance issue as there're probably only a limited number of tasks available in an installation, but nevertheless it seems to be cleaner to bind the field provider to their tasks.
Files
Actually I planned it this way originally but eventually didn't do it as there wasn't any example - that I know of - of hook usage in the core. I do that in some of my extensions though.
So I fully agree with that. Just note that the task type is actually the class name of the task class, so for the test task - for example - it would have to be:
$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['scheduler']['additionalFields']['tx_scheduler_testtask'][] = 'EXT:' . $_EXTKEY . '/examples/class.tx_scheduler_testtask_hook.php:&tx_scheduler_testtask_hook';
Francois Suter wrote:
So I fully agree with that. Just note that the task type is actually the class name of the task class,
of course, type was just the wrong term here
- Assignee set to Ingo Renner
when binding those classes to specific tasks we could also simply add that definition to the task's definition in ext_localconf.php itself. Thus we wouldn't need that extra (long) hook definition to register the class.
Ingo Renner wrote:
when binding those classes to specific tasks we could also simply add that definition to the task's definition in ext_localconf.php itself. Thus we wouldn't need that extra (long) hook definition to register the class.
Doh! Sounds so logical, doesn't it?
However in such case we should change the $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['scheduler']['tasks']['scheduler'] array to use the class names as keys instead of some other key (e.g. use "tx_scheduler_testtask" instead of "testtask"). This is possible now that we cleaned up the declaration of the class name, after your remark about autoloading.
Francois Suter wrote:
Ingo Renner wrote:
when binding those classes to specific tasks we could also simply add that definition to the task's definition in ext_localconf.php itself. Thus we wouldn't need that extra (long) hook definition to register the class.
Doh! Sounds so logical, doesn't it?
However in such case we should change the $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['scheduler']['tasks']['scheduler'] array to use the class names as keys instead of some other key (e.g. use "tx_scheduler_testtask" instead of "testtask"). This is possible now that we cleaned up the declaration of the class name, after your remark about autoloading.
right, but then again we don't need the class attribute anymore either :) Oh streamlining is fun :)
right, but then again we don't need the class attribute anymore either :)
Probably, but right now I'm getting a bit lost. Let me clear the crid first and I'll probably do that one afterwards, since I'm already at it.
Oh streamlining is fun :)
Isn't it? ;-)
Francois Suter wrote:
right, but then again we don't need the class attribute anymore either :)
Probably, but right now I'm getting a bit lost. Let me clear the crid first and I'll probably do that one afterwards, since I'm already at it.
sure, should be a different issue anyways
- Status changed from New to Accepted
- Assignee changed from Ingo Renner to Francois Suter
Just for info, I'm currently implementing this and more streamlining (cutting off a couple of dimensions from the registration array) as it's really all connected.
- Status changed from Accepted to Resolved
- % Done changed from 0 to 100
Solved in r1158
That ended up being a mighty cleanup!
The task registration structure has been simplified: the class is used directly as a key. The extension is not used as a key anymore, but is inside the structure, as a reference (it is used for informational purposes only anyway). This gives a structure like:
$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['scheduler']['tasks']['tx_scheduler_testtask'] = array(
'extension' => $_EXTKEY,
'title' => 'LLL:EXT:' . $_EXTKEY . '/locallang.xml:testTask.name',
'description' => 'LLL:EXT:' . $_EXTKEY . '/locallang.xml:testTask.description',
'additionalFields' => 'tx_scheduler_testtask_hook'
);
The task registration structure has been simplified: the class is used directly as a key. The extension is not used as a key anymore, but is inside the structure, as a reference (it is used for informational purposes only anyway). This gives a structure like:
Forgot to mention: I changed all uses of the word "hook" inside the BE module's code as the additional fields provider mechanism doesn't really behave like a TYPO3 hook anymore. I used the word "provider" instead, which is less confusing I think.
I'll do a follow-up issue where I will rename the current "hook" classes file names and class names to use "provider" too.
- Status changed from Resolved to Closed
- Category set to scheduler
- Project changed from 739 to TYPO3 Core
- Category changed from scheduler to scheduler
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by