@x00: Thanks again for the example. However, I decided to take a simpler route for the moment. The Cron Plugin will simply fire all registered Cron tasks at every run. User will just have to schedule a call to the appropriate menu item (e.g. /cronplugin/execute) and that's it.
I'm at the very beginning of designing it and I'm not even using a Model yet, just an associative array. Plenty of refactoring to be done, but, right now, it actually works!
Thank you very much for your (late night) help. GMT time zone here, it was late for me too.
The model would be to give the cron task somewhere to store persistent key/values, however they could deal with what entire on their own, or simply not rely on any persistent data.
I was tempted just to have a config store, but I though that was too crude of an example.
It's a good idea to have something persistent, although the "Unregister" phase would have to be handled as well. For simplicity, I simply allow plugin to register themselves at runtime, it's anyway a fairly cheap operation (an "add" to an array). This way, if client plugin is active, its Cron will be called. If not, it will not be called. Easy.
well the register could be per prequest, it doesn't mean you are storing the register.
However the task and the taskcondition may need some persistent data to work.
Say you only want to cron on the 5 day of the month, but you don't want to be doing the task over over on the 5th you have to make a record the task has been performed.
x00 said:
well the register could be per prequest, it doesn't mean you are storing the register.
However the task and the taskcondition may need some persistent data to work.
Say you only want to cron on the 5 day of the month, but you don't want to be doing the task over over on the 5th you have to make a record the task has been performed.
@x00: you're spot on, the ability of deciding what to run and when would be great. However, for the moment, I won't let my CronPlugin handle this yet, it will be the next version. Every Cron Run will fire each and every registered event, every time, and it will be up to the plugin to decide what to do. After all, there aren't plugins using it yet, therefore there's no point in adding features before the core functionality has been tested.
Next step will be "how to do Unit Testing in Vanilla".
Answers
the function was meant to be:
static public function OnFifthOfMonth($Cron){ if($Cron->Model->Get('MyPlugin','FifthOfMonth')<strtotime('YYYY-MM-05') && intval(date('d'))==5){ $Cron->Model->Set('MyPlugin','FifthOfMonth',strtotime('YYYY-MM-05')); return true; }else{ return false; } }grep is your friend.
ok I hope that is clearer.
grep is your friend.
sorry I was tired last night it should be
strtotime(date('Y-m-05'))notstrtotime('YYYY-MM-05');grep is your friend.
@x00: Thanks again for the example. However, I decided to take a simpler route for the moment. The Cron Plugin will simply fire all registered Cron tasks at every run. User will just have to schedule a call to the appropriate menu item (e.g. /cronplugin/execute) and that's it.
I'm at the very beginning of designing it and I'm not even using a Model yet, just an associative array. Plenty of refactoring to be done, but, right now, it actually works!
Thank you very much for your (late night) help. GMT time zone here, it was late for me too.
My shop | About Me
The model would be to give the cron task somewhere to store persistent key/values, however they could deal with what entire on their own, or simply not rely on any persistent data.
I was tempted just to have a config store, but I though that was too crude of an example.
grep is your friend.
It's a good idea to have something persistent, although the "Unregister" phase would have to be handled as well. For simplicity, I simply allow plugin to register themselves at runtime, it's anyway a fairly cheap operation (an "add" to an array). This way, if client plugin is active, its Cron will be called. If not, it will not be called. Easy.
My shop | About Me
well the register could be per prequest, it doesn't mean you are storing the register.
However the task and the taskcondition may need some persistent data to work.
Say you only want to cron on the 5 day of the month, but you don't want to be doing the task over over on the 5th you have to make a record the task has been performed.
grep is your friend.
of course you could make a more exact taskcondition but as this is per request the is good chance you might miss the cron.
grep is your friend.
@x00: you're spot on, the ability of deciding what to run and when would be great. However, for the moment, I won't let my CronPlugin handle this yet, it will be the next version. Every Cron Run will fire each and every registered event, every time, and it will be up to the plugin to decide what to do. After all, there aren't plugins using it yet, therefore there's no point in adding features before the core functionality has been tested.
Next step will be "how to do Unit Testing in Vanilla".
My shop | About Me