[cgiapp] params, params, params...
Ron Savage
ron at savage.net.au
Tue Feb 12 04:08:56 EST 2008
On Mon, 2008-02-11 at 10:03 +0000, Mark Knoop wrote:
Hi Mark
> Ok. This is as I thought but it is very useful to have it confirmed in such
> a clear and concise manner.
Thanx.
> stuff so I would be interested to know if this is a common practice or if it
> is considered overkill. I have gone down this route and it is working for me
> but I'm not sure it is a good example of encapsulation, loose coupling etc
It sure sounds like overkill to me.
Having said that, I can understand you might want a variable whose value
happens to come from one of several sources. I think such logic would
fit in your super class, and be stored in CGI::App's param() cache,
rather than inventing another (4th) location for such a cache. That 4
alone tells you it's overkill.
> For example is there another tidy way to make all the params from the
> CGI::App, query and session available in external class methods? Apologies
> if I am being ludicrous due to my lack of understanding of this kind of
> thing but I only learn by asking dumb questions!
The struggle to understand new concepts affects us all, so no, there is
no need to apologize. All you have to do is persist until the situation
is clear. Of course, if it seems clear but really isn't, then you'll
really have something to worry about...
As for external classes, I've had to deal with that. The solution is
simple. At some time you pass the CGI::App object to the other class's
object - either in it's new or just to some particular method of that
object. Then from within that other object you do (using the 2nd
approach):
package OtherClass;
sub metho
{
my($self, $cgi_obj) = @_;
...
my($value) = $cgi_obj -> param('variable_name');
...
}
--
Ron Savage
ron at savage.net.au
http://savage.net.au/index.html
More information about the cgiapp
mailing list