Re: [mh] mh http_server - script API (Was New shopping_list.pl)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

David Mark wrote:
> Matthew Williams <mattrwilliams <at> users.sourceforge.net> writes:
> 
> The whole problem I ran into was that when you include a script on the server 
> side, it has no way to get to the querystring (or form) parameters.  

It should be easy to pass along the querystring parameters by adding $arg as
as a new parameter to shtml_include.  You would then add the following lines
to shtml_include:

        @ARGV = '';             # Have to clear previous args
        @ARGV = split(/&&/, $arg) if defined $arg;

and then modify shtml_include to add the new directive that I mentioned
before (script=).  When the eval happens, the scripts would gain access to
the querystring with the same "API" as before, by looking at @ARGV.
include_shtml would automatically strip out all the stuff that you don't
want, like the <head>...</head> section and <html></html> tags.

With my method, you wouldn't have to modify the scripts in any way.  You
centralize the changes required, and they turn out to be quite minor.

> By adding 
> a quick fix to http_server, I was able to expose these to the included 
> script.  I converted a lot of the existing scripts by first changing the way 
> they read their parameters (checks the old way and if nothing is there, checks 
> the newly added environment variable.)  This was pretty easy as the code is 
> always at the top.  Not any more trouble than checking a flag.  Secondly, I 
> cut and pasted the head, title, keywords, etc. to an shtml file (which has a 
> directive to include the script.)  Lastly, I changed the link in IA5 to point 
> to the shtml file, instead of the PERL script.
> 

> The end result is that the modules work with frames and without and are 
> modular in a way that they weren't before.  I like being able to slap together 
> different content to create a more newspaper-like feel.  The IA5 interface 
> seems more like the control panel of a space ship.
> 

The problem I see with your method is that you have to modify every script.
 The modularity can be implemented by the two methods of "calling" the script.

1.  If you want the script to generate a complete page, you simply refer to
its complete address in a frameset or as the target in the browser. (i.e.
<frame src='/bin/shopping_list.pl'>.

2.  If you just want the content, you include the following directive in the
.shtml .  The extra html stuff
gets stripped automatically.

> I think what I need to do is post the one-liner that exposes the parameters 
> and the function I have to retrieve them (which is backwardly compatible with 
> the current method.)  Once the former is in http_server.pm, it will be fairly 
> trivial to update the various scripts.  I've already done most of them, but of 
> course they are not the latest versions.  The biggest bear is the MP3 jukebox 
> and I am hopeful that they have not been heavily modified over the last few 
> months.  That one took a while to get working with or without frames.
> 
>>
>> Another option would be to create a new mh .shtml directive, say "script"
>> that runs the script and then automatically rips out the html tags/sections
>> that only apply when whole pages are being generated, like in framesets.
>>
>> This would provide a standard mechanism for non frame based interfaces to
>> get access to all of the scripts without having to rewrite the scripts
>> themselves.  As well, some of the mh frame bugs could be fixed by
>> encouraging people to generate complete and valid HTML whenever possible.
>>
>> What do people think?
>> Matt

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 