Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW

Re: Re: Re: Re: Request For Comment: Web Application Plugin Manager

by andreychek (Parson)
on Oct 02, 2002 at 17:27 UTC ( #202331=note: print w/replies, xml ) Need Help??

in reply to Re: Re: Re: Request For Comment: Web Application Plugin Manager
in thread Request For Comment: Web Application Plugin Manager

Maybe you then can add 'get' as an alias for get_incoming

Hmm... fair enough, it would be pretty simply to alias get_incoming() as just get(), and the same thing for set_incoming/set.

When do you use set_incoming (or $cgi->param('field', $value))?

Heh.. another excellent question. I personally think you shouldn't :-) In the case of OpenPlugin, set_incoming is called for you when the plugin is initially invoked.

Alas, the rest of the world doesn't think like me yet ;-), and some people feel that there are certain cases where it is appropriate to change the values of parameters that were sent to your script from the browser.

I read some reasoning for this somewhere before, but I can no longer find the documentation. However, one reason had something to do with the fact that some folks like to run all their parameters through a filter of some kind first. After the filter is complete, they wish to make their programs believe that the filtered data is what was really sent by the browser. Some feel that the best way to achieve this effect is to change the values of the parameters which were passed in.

Personally, I think it would be better to create a hash of all the data that was sent to the browser, and filter the data in the hash. I tend to look at parameters sent by the browser as read-only -- it's what was sent by the browser, you should leave it that way. And it's trivial to create a new set of data.

But, TMTOWTDI always applies, and who am I to suggest that my way is better than somebody elses :-) Both CGI and Apache::Request offer methods of altering the incoming parameter values, so people are definitely using that functionality.

Where is the problem for Perl 5 compatibility?

For everyone reading this, uwevoelker is referencing something I sent him in an email -- OpenPlugin, as of version 0.06, only works with Perl 5.6.0 or higher.

Where is the problem? I'm currently trying to figure that out :-) There are little things throughout the code that are causing a few issues, and I'm making my way through right now trying to fix them all.

For instance, the following is code I had been using, which I recently found out is illegal under 5.005:
# Breaks under 5.005 $self->$plugin->method_name(); # Works under 5.005 and 5.6.0 $self->$plugin()->method_name();
I had thought when I was coding this module, that I was using syntax that should work fine in older Perl versions. I just downloaded an older version to test with though, and it proved me incorrect :-)

Lucy: "What happens if you practice the piano for 20 years and then end up not being rich and famous?"
Schroeder: "The joy is in the playing."
  • Comment on Re: Re: Re: Re: Request For Comment: Web Application Plugin Manager
  • Download Code

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://202331]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (7)
As of 2020-10-01 09:06 GMT
Find Nodes?
    Voting Booth?
    If at first I donít succeed, I Ö

    Results (177 votes). Check out past polls.