Forgive me if I'm mistaken or coming in overly-late, but would this not
return the output of a run-mode but without the headers?
sub run_mode1
{
my $self = shift;
# LOOKUP DATA STUFF
# DO TEMPLATE STUFF
return $output;
}
sub run_mode2
{
my $self = shift;
# DO STUFF
my $output = $self->run_mode1();
return $output;
}
If called by itself run_mode1 will return it's output with a header as
expected.
If however run_mode2 is called it will call run_mode1 to return the output
(without headers) and save it in $output. It's not until run_mode2 is calls
return $output that control is returned to CGI::APP and the headers are
added.
So things like this should work in most cases:
----
my $output = ($rm_type 'this') ? $self->rm_this() : $self->rm_that();
return $output;
----
Or even this:
----
my $output = $self->select_rm_output( -optional => arguments );
return $output;
sub select_rm_output()
{
my $self = shift;
my %args = @_;
my $output;
$output = $self->rm_this() if ( $args{-this} );
$output = $self->rm_that() if ( $args{-that} );
$output = $self->rm_otherthing() if ( $args{-otherthing} );
$output = $self->rm_something() if ( $args{-something} );
$output = $self->rm_else() if ( $args{-else} );
return $output;
}
----
I don't know if I've just repeated what's already been said or if I'm
missing your point completely.
> This was a very good suggestion and I DID implement it from the last time
> the issue was raised. The problem is that you get an extra set of headers
> (see the subject line).
Something is wrong if this is the case. A header should only be appended
when output leaves a run mode and returns to CGI::Application. If run_mode2
calls run_mode1, when control leaves a run_mode1 and returns to run_mode2
then the only data being passed back should be the data being explicitly
returned by run_mode1.
I use this extensively in my programs and have never run into a case of 2
sets of headers.
<ramble>
Than again, maybe the problem is different. Supose you take 3 standard
operations on an item in a database, add, update and delete. You would need
a seperate run mode to perform each operation, but the output might be
strikingly similar ( 'Your item has been added|updated|saved' ). To put the
output code into each run mode would be a bunch of extra useless lines.
However what if you instead had a sub routine called operation_performed().
This sub routine would not have to be a run mode but it could return the
html output to whatever called it. example:
sub operation_performed
{
my $self = shift;
my $operation = shift;
my $t = load_tmpl('operation_successful.tmpl');
$t->param( 'operation' => $operation );
return $t->output();
}
Obviously this is a stripped down version of the routine, there may be more
things to add to the template, you may not be using HTML::Template, you may
need to make other sub-routine calls inside here, etc, but the principle
remains. Now for each of your run_modes performing and operation, they
should be able to have this at the end:
return $self->operation_performed('Added');
or
return $self->operation_performed('Deleted');
or
return $self->operation_performed('Updated');
I'm still using very simple ideas and assuming the only piece of information
you want to pass to operation_performed is a string containing the operation
that was completed. But the idea is that you've now taken away
responsibility of having your data manipulating run-mode perform output
formatting.
</ramble>
Anyways, those are my ideas. Let me know if I'm out in left field.
===
steve comrie :: senior developer
www.shrinkingplanet.ca
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
