Last modified: 2008-04-05 09:19:39 UTC
The job queue should be able to accept any type of job command, not be limited
to internally-defined commands. This is necessary because some extensions may
need to modify many articles or perform additional time-consuming activities
after an edit is performed.
There are two issues that need be resolved
1) The ability to define a custom job to run
2) The ability to run a defined custom job
The solution to #1 could be done utilizing the ArticleSave hook. However, it
might be easier if a new hook was introduced in Article::editUpdates(). (It is
worth noting that the ArticleEditUpdatesDeleteFromRecentchanges hook could be
used for this, but that hook's description has nothing to do with what we are
trying to accomplish).
There are two solutions to #2. Both involve modifying JobQueue::factory() so
the default: case in the switch block attempts to call a user-defined function.
1) Use a hook to obtain an instance of the Job class suitable to handle a
specified command. This means creating a skeleton job class and passing it to
the hook and testing to see if the object was re-casted as a different object
type by any hooks that were run.
2) Rely on the __autoload functionality to try to instantiate an instance of a
class named 'Job_$command' or something similar.
#2 is probably the preferred way to do this, at least from an object-oriented
Created attachment 3648 [details]
Skeleton class for custom jobs
Created attachment 3649 [details]
modified factory method to enable the jobqueue for custom jobs
(In reply to comment #0)
I absolutely agree with Gregory that there is a need for custom jobs and I think the second option (autoload) is a good mechanism to enable the JobQueue to handle them.
Find my suggestion for the JobQueue::factory() method in the attached file (factory.txt).
Basically, it uses Autoloader::__autoload($classname) to get the class.
The only thing one has to keep in mind is that the $command has to match the job's classname from now on.
I wrote several custom jobs and it worked fine for me.
For the sake of completeness I attached the DummyJob class (DummyJob.txt).
I think this should be fixed with $wgJobClasses, added in 1.11. For example, renameuser extension use a job to update revisions to the new user name. Marking bug as resolved.