Re: Request For Comment: Web Application Plugin Manager

Replies are listed 'Best First'.
Re: Re: Request For Comment: Web Application Plugin Manager by andreychek (Parson) on Oct 02, 2002 at 13:59 UTC
What I not like is get_incoming as method for param. Good question. Lets look away from the Param plugin for a moment, and take a look at the httpheader plugin. With headers, there is a stage where the browser sends headers to the server, and there is a stage where the server sends headers to the browser. To accommodate all of these stages, the httpheader plugin offers the following methods: get_incoming() set_incoming() get_outgoing() set_outgoing() The Cookie plugin's interface is the same as the Httpheader one I just described. Now, lets look at the Params plugin again. You said that the get_incoming() did not seem intuitive. The reason it's like that though is to match the style of the HttpHeader and Cookie plugins. These two plugins couldn't just have a get() method, as they need to differentiate between incoming and outgoing parameters. So, to keep a like style, I named the methods in the Param plugin get_incoming and set_incoming. I feel that by having a like interface across the plugins, it would make OpenPlugin as a whole easier to learn. However, because get_incoming() does seem a bit long, I've been thinking about writing a wrapper function which would work a bit like CGI's or Apache::Request's param() function. Instead of using get_incoming or set_incoming, you could just use incoming(). Behind the scenes, it would call get_incoming or set_incoming based on the amount of parameters you send it. For example: `# Retrieve incoming param (instead of using (get_incoming) $OP->param->incoming( 'param_name' ); # Set an incoming param (instead of using set_incoming) $OP->param->incoming( 'param_name', 'value' );` [download] Again, if I add this, both would still work. If you prefer using get_incoming/set_incoming, us them, if you prefer just using incoming(), you can use that. Any thoughts? -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."	[reply] [d/l]
Re: Re: Re: Request For Comment: Web Application Plugin Manager by uwevoelker (Pilgrim) on Oct 02, 2002 at 16:57 UTC
Okay, the same syntax (here: method names) on similiar plugins is fine. Maybe you then can add 'get' as an alias for get_incoming, it is more DWIM. :-) As a side note: When do you use set_incoming (or $cgi->param('field', $value))? I only use it as "get". The values for the fields are passed to the templating engine. Where is the problem for Perl 5 compatibility? Bye, Uwe	[reply]
Re: Re: Re: Re: Request For Comment: Web Application Plugin Manager by andreychek (Parson) on Oct 02, 2002 at 17:27 UTC
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."	[reply] [d/l]


No such thing as a small change
	PerlMonks