HolidaylistPlugin does not work in trunk because of Func::getCgiQuery() no longer returning a CGI object

Same may apply to other plugins.

The issue is that the Foswiki::Response does not implement a complete replacement of CGI.

What is the action now? Making Response a complete CGI replacement seems a near impossible solution.

Fixing the plugins on SVN still leaves private plugins not working.

Plugin authors that used Func::getCgiQuery() followed official API and were in good faith when they called CGI methods.

This is a major problem introduced by the Foswiki Stand Alone (former TWiki Stand Alone) code.

It is urgent that we find a solution to this one. Blocks 1.0.0 release.

• KennethLavrsen - 29 Nov 2008

Hi Kenneth,

When I wrote Foswiki::Response I made it the most compatible with CGI as I could. However some CGI methods don't make sense in the new context. The particular issue with HolidaylistPlugin is that it uses the returned object to build HTML. One solution is to modify it to use, e.g. CGI::a instead of $cgi->a. Another possibility is to make Foswiki::Request call CGI's HTML build methods.

• GilmarSantosJr - 29 Nov 2008

I added use CGI qw(:standard) on top of Foswiki::Request, so HTML build methods are imported and the cases like HolidaylistPlugin works. However this adds some overhead and ideally it could be done lazily. Unfortunately I can't do it now.

• GilmarSantosJr - 29 Nov 2008

Thanks for dealing with this one Gilmar. I know you are busy these days.

There is an issue with the solution.

When you use the plugin the page is full of Foswiki::Request=HASH(0x879df10) HASH(0x9434c34) and similar.

• KennethLavrsen - 29 Nov 2008

Also, Crawford reported about warnings of functions redefinition.

The problem with the redefinition is due to :form and :cgi (included by :standard) import functions with the same name as some Foswiki::Request methods.

The other problem is at CGI's structure: the HTML build methods can be called like in print CGI::p("some text") or, when the script use CGI qw(:standard), print p("some text") or even print CGI->p("some text"). Internally all HTML build methods call CGI::self_or_default, that tests if the first parameter is the static text CGI or if it's a CGI object. When this test fails, a default object is built and used. Here where the problem arises: th method, for example, takes a hashref as parameter. And HolidaylistPlugin calls it $cgi->th(...), that is translated into CGI::th($default_cgi_object, $foswiki_request_object, ...), then the $foswiki_request_object is used as an ordinary hashref...

The solution to both problems is to make Foswiki::Request be a derived class from CGI. This also fix many other problems where Foswiki::Request doesn't implement CGI methods. The danger is: with engines other than CGI or FastCGI the unimplemented methods may lead to unpredictable results...

• GilmarSantosJr - 29 Nov 2008