Sep 3rd, 2010, 9:11 AM
Hi Aluwe,
Great! Sounds like you're making progress.
Yes, I'd drop the or die(mysql_error()) bit now. It's generally not a good idea to have die()'s in your production code.
Regarding triggering the Pre-Parser rule, hmm... I wonder what would be the best approach here...
Here's the thing: the Submission Pre-Parser was designed to attach your code to the Core Form Tools events - adding, editing and deleting submissions within the Form Tools UI. Since you're doing it manually, you'd need to either manually trigger that even and fool the module into thinking it just occurred in the Core, or simply cut & paste the PHP code in your rule.
Despite the code redundancy, the copy-paste method may actually be a better approach. The reason is that it will ensure your code continues to work even if the Submission Pre-Parser module changes somewhere down the road. But it's judgement call. Feel free to disagree with me.
If you'd rather try to trigger the Pre-Parser rule directly, I'd try something like this:
It's untested, but I think the idea is sound. First, it includes the main code for the module, then it compiles a list of data needed for the spp_parse() function.
That spp_parse function calls all rules that have been defined for that event (updating a submission) on that form (ID #99).
However: it *won't* include other info, like the submission ID - which you may be using in your rule. You'll need to locate and add that to the $info var in order to use it in your Pre-Parser rule. That's the drawback: the core function adds in that info for you, but by manually doing it like this, you'll need to construct it manually.
It's a bit complicated, but hopefully the general approach makes sense.
Let me know how it goes! Good luck!
- Ben
Great! Sounds like you're making progress.
Yes, I'd drop the or die(mysql_error()) bit now. It's generally not a good idea to have die()'s in your production code.
Regarding triggering the Pre-Parser rule, hmm... I wonder what would be the best approach here...
Here's the thing: the Submission Pre-Parser was designed to attach your code to the Core Form Tools events - adding, editing and deleting submissions within the Form Tools UI. Since you're doing it manually, you'd need to either manually trigger that even and fool the module into thinking it just occurred in the Core, or simply cut & paste the PHP code in your rule.
Despite the code redundancy, the copy-paste method may actually be a better approach. The reason is that it will ensure your code continues to work even if the Submission Pre-Parser module changes somewhere down the road. But it's judgement call. Feel free to disagree with me.
If you'd rather try to trigger the Pre-Parser rule directly, I'd try something like this:
PHP Code:
require_once("/path/to/module/submission_pre_parser/library.php");
$info = array(
"form_tools_calling_function" => "ft_update_submission",
"form_id" => 99
);
spp_parse($info);
It's untested, but I think the idea is sound. First, it includes the main code for the module, then it compiles a list of data needed for the spp_parse() function.
That spp_parse function calls all rules that have been defined for that event (updating a submission) on that form (ID #99).
However: it *won't* include other info, like the submission ID - which you may be using in your rule. You'll need to locate and add that to the $info var in order to use it in your Pre-Parser rule. That's the drawback: the core function adds in that info for you, but by manually doing it like this, you'll need to construct it manually.
It's a bit complicated, but hopefully the general approach makes sense.
Let me know how it goes! Good luck!
- Ben