Bug #4267: Registration for classes that provide additional fields does not bind those classes to specific task types - TYPO3 Core - TYPO3 Forge

Actions

Copy link

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.

Status:

Closed

Priority:

Must have

Assignee:

Francois Suter

Category:

scheduler

Target version:

Start date:

2009-08-18

Due date:

% Done:

100%

Estimated time:

TYPO3 Version:

PHP Version:

Tags:

Complexity:

Is Regression:

Sprint Focus:

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

4267.diff (8.31 KB) 4267.diff

Ingo Renner, 2009-08-28 12:26

Actions

Copy link

Updated by Francois Suter over 15 years ago

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';

Actions

Copy link

Updated by Ingo Renner over 15 years ago

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

Actions

Copy link

Updated by Francois Suter over 15 years ago

Right, go ahead then.

Actions

Copy link

Updated by Ingo Renner over 15 years ago

Assignee set to Ingo Renner

Actions

Copy link

Updated by Ingo Renner over 15 years ago

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.

Actions

Copy link

Updated by Francois Suter over 15 years ago

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.

Actions

Copy link

Updated by Ingo Renner about 15 years ago

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 :)

Actions

Copy link

Updated by Francois Suter about 15 years ago

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? ;-)

Actions

Copy link

Updated by Ingo Renner about 15 years ago

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

Actions

Copy link

#10

Updated by Ingo Renner about 15 years ago

File 4267.diff 4267.diff added

Here's the patch

Actions

Copy link

#11

Updated by Francois Suter about 15 years ago

Status changed from New to Accepted
Assignee changed from Ingo Renner to Francois Suter

Actions

Copy link

#12

Updated by Francois Suter about 15 years ago

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.

Actions

Copy link

#13

Updated by Francois Suter about 15 years ago

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'
    );

Actions

Copy link

#14

Updated by Francois Suter about 15 years ago

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.

Actions

Copy link

#15