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();

[download]
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 :-)
-Eric

--
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."

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

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.