TYPO3 Core

This is not good enough I fear, it doesn't state what kind of provider it is - Internet Provider? It must at least be FieldProvider or better AdditionalFieldProvider otherwise it's very confusing.

OK, fair enough. I'll look at that later.

I tried to change the name of the classes to e.g. tx_scheduler_sleeptask_AdditionalFieldProvider but the autoloader was complaining that the class was not found. It works with tx_scheduler_sleeptask_additionalfieldprovider, so it seems like it doesn't like camel case, but I'm surprised. Have you ever experienced something similar?

Working on this made me think of something else: when this was a true hook, it made sense to have a separate class for the task itself and for the additional fields. Now that the additional fields thingy is an interface, it could very well be implemented in the same class as the task. This could be optional or mandatory. What do you think?

More digging into this: it seems like the TYPO3 autoloader is case-sensitive whereas PHP isn't. I changed my class name to "tx_scheduler_sleeptask_AdditionalFieldProvider". If I declare it in camel case in the ext_autoload.php file, like this:

'tx_scheduler_sleeptask_AdditionalFieldProvider'    => t3lib_extMgm::extPath('scheduler', 'examples/class.tx_scheduler_sleeptask_additionalfieldprovider.php')

I get an error. But if I declare it all lowercase:

'tx_scheduler_sleeptask_additionalfieldprovider'    => t3lib_extMgm::extPath('scheduler', 'examples/class.tx_scheduler_sleeptask_additionalfieldprovider.php')

it works fine. So I'm going to go ahead with the change as I have now a working solution, but I think the autoloader should be patched to be case-insensitive. Is that correct? Shall I open a bug report for this?

Francois Suter wrote:

Working on this made me think of something else: when this was a true hook, it made sense to have a separate class for the task itself and for the additional fields. Now that the additional fields thingy is an interface, it could very well be implemented in the same class as the task. This could be optional or mandatory. What do you think?

After more thinking, let's leave this as it is. If people want to use a single class they can or they can use two classes. It's flexible, it's fine. It is getting late to change the API and there wouldn't be much benefit in this case.

Francois Suter wrote:

I tried to change the name of the classes to e.g. tx_scheduler_sleeptask_AdditionalFieldProvider but the autoloader was complaining that the class was not found. It works with tx_scheduler_sleeptask_additionalfieldprovider, so it seems like it doesn't like camel case, but I'm surprised. Have you ever experienced something similar?

yes I noticed that too with other classes, seems to be a bug to me.

Working on this made me think of something else: when this was a true hook, it made sense to have a separate class for the task itself and for the additional fields. Now that the additional fields thingy is an interface, it could very well be implemented in the same class as the task. This could be optional or mandatory. What do you think?

true it could be implemented by the task itself, one would just have to set the same class name for the additional fields option. Don't know whether that be good or bad though. It is possible anyways.