It seems that to create a new hook, all you need to do is add:
where you want it? Is that true?
And, secondly, in the handle routine, is this the preferred format now (calling the plugin dispatch, then re-assigning $in in the routine, )
# ------------------------------------------------------------------
# Determine what to do.
#
my $input = $IN->get_hash;
if ($input->{add_review}) { $PLG->dispatch('review_add', \&add_review) }
elsif ($input->{edit_review}) { $PLG->dispatch('review_edit', \&edit_review) }
elsif ($input->{helpful}) { $PLG->dispatch('review_helpful', \&helpful_review) }
else { $PLG->dispatch('review_search', \&review_search_results) }
return;
}
# ================================================================== Then, in the sub, my $in = $IN->get_hash; ## assign the $in data to the local variable, again
Or, is this way just as acceptable, and in some cases, more logical,
if ($input->{add_review}) { &add_review($input) }
elsif ($input->{edit_review}) { &edit_review($input) }
elsif ($input->{helpful}) { &helpful_review($input) }
else { review_search_results($input) }
return;
sub add_review {
my $in = shift;
$PLG->dispatch('review_add', \&add_review);........
}
Or, basically, make everything go through the handle routine, not bypass it, and
pass the $IN tags into the subroutines, rather than relying on them to get them,
or make "external" requests on their own.
Each sub would "logically" be responsible for checking if it had any plugin actions.
It seems to me that while the first example is "cooler", the second way is more
logical, and all passed-in params are up front, rather than spread throughout the
module.
The second way, also seems more "object oriented" since it's "contained". The call
to the plugin dispatch is not missed if "handle" is bypassed, and $in is passed in
no matter how it's gotten -- whether it's actually from $IN or from another source.
PUGDOG� Enterprises, Inc.
The best way to contact me is to NOT use Email.
Please leave a PM here.
Code:
$PLG->dispatch('hook_name', \&sub_to_run)where you want it? Is that true?
And, secondly, in the handle routine, is this the preferred format now (calling the plugin dispatch, then re-assigning $in in the routine, )
Code:
sub handle { # ------------------------------------------------------------------
# Determine what to do.
#
my $input = $IN->get_hash;
if ($input->{add_review}) { $PLG->dispatch('review_add', \&add_review) }
elsif ($input->{edit_review}) { $PLG->dispatch('review_edit', \&edit_review) }
elsif ($input->{helpful}) { $PLG->dispatch('review_helpful', \&helpful_review) }
else { $PLG->dispatch('review_search', \&review_search_results) }
return;
}
# ================================================================== Then, in the sub, my $in = $IN->get_hash; ## assign the $in data to the local variable, again
Or, is this way just as acceptable, and in some cases, more logical,
Code:
my $input = $IN->get_hash; if ($input->{add_review}) { &add_review($input) }
elsif ($input->{edit_review}) { &edit_review($input) }
elsif ($input->{helpful}) { &helpful_review($input) }
else { review_search_results($input) }
return;
sub add_review {
my $in = shift;
$PLG->dispatch('review_add', \&add_review);........
}
Or, basically, make everything go through the handle routine, not bypass it, and
pass the $IN tags into the subroutines, rather than relying on them to get them,
or make "external" requests on their own.
Each sub would "logically" be responsible for checking if it had any plugin actions.
It seems to me that while the first example is "cooler", the second way is more
logical, and all passed-in params are up front, rather than spread throughout the
module.
The second way, also seems more "object oriented" since it's "contained". The call
to the plugin dispatch is not missed if "handle" is bypassed, and $in is passed in
no matter how it's gotten -- whether it's actually from $IN or from another source.
PUGDOG� Enterprises, Inc.
The best way to contact me is to NOT use Email.
Please leave a PM here.