You are here: Foswiki>Tasks Web>Item337 (29 Nov 2008, GilmarSantosJr)Edit Attach

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

pencil
Priority: Urgent
Current State: Closed
Released In: 1.0.0
Target Release: patch
Applies To: Engine
Component:
Branches:
Reported By: Foswiki:Main.KennethLavrsen
Waiting For:
Last Change By: GilmarSantosJr
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.

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.

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.

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.

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

ItemTemplate edit

Summary Plugins such as HolidaylistPlugin does not work in trunk because of Func::getCgiQuery() no longer returning a CGI object
ReportedBy Foswiki:Main.KennethLavrsen
Codebase foswiki(trunk)
SVN Range TWiki-4.2.3, Wed, 06 Aug 2008, build 17396
AppliesTo Engine
Component
Priority Urgent
CurrentState Closed
WaitingFor
Checkins distro:8279a5bb244e distro:224b268a1902
TargetRelease patch
ReleasedIn 1.0.0
Topic revision: r7 - 29 Nov 2008, GilmarSantosJr
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy