Gossamer Forum: Products: Gossamer Links: Development, Plugins and Globals: CGI.pm & GT::CGI conflict

Feb 27, 2005, 10:29 PM

webmaster33

Veteran (2312 posts)

Feb 27, 2005, 10:29 PM

Post #1 of 7

Shortcut

CGI.pm & GT::CGI conflict

What would you do, if you would need to use both GT::CGI and the standard CGI.pm library?

I tried, and if both GT::CGI and CGI.pm is used, then CGI.pm will not working correctly, as it doesn't get the form inputs.
This line is causing the result, that CGI.pm will not able to get/parse the form input.

GT::CGI.pm, v1.140

Code:
line 97:                   read(STDIN, my $data, $content_length, 0);

This is somehow causing conflict between standard CGI.pm and GT::CGI Frown

THis is the code I use to get input params:

Code:
my $q = new CGI(); 
print "\$q: " . Dumper(\$q) . "\n\n"; 
local (%in) = $q->Vars;

I also found a similar thread about GT::CGI and CGI.pm problem, but got no idea, what the problem is:
http://www.gossamer-threads.com/...i?post=109584#109584

Any idea, how to fix that compatibility problem?

Best regards,
Webmaster33

Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...

Feb 28, 2005, 7:19 AM

rocco

User (77 posts)

Feb 28, 2005, 7:19 AM

Post #2 of 7

Shortcut

Re: [webmaster33] CGI.pm & GT::CGI conflict In reply to

I'm not surprised it doesn't work, there's only one source of input from which these modules parse the input (from both POST and GET methods). So, the first CGI module will read the form input and starve the second. Just curious though....are you running this under mod_perl ?

You really need to use either one or the other, not both in the same processing action. I would only use GT's of course..... Wink

But, if I have it all wrong, maybe a GT staff member will enlighten us all...... Smile

Regards,
Peter Puglisi
www.ausfreedom.com
Ultimate Freedom is our game.

Feb 28, 2005, 8:08 AM

webmaster33

Veteran (2312 posts)

Feb 28, 2005, 8:08 AM

Post #3 of 7

Shortcut

Re: [rocco] CGI.pm & GT::CGI conflict In reply to

I would not like to use both. I would like to use just CGI.pm. However in init_use() code flow, the GT::CGI object is initialized, and it reads from STDIN in this process.
So, no matter, that I don't use GT::CGI, LSQL needs to initialize it.

And no, I don't use mod_perl, yet.

That's what Alex says in the mentioned post:
http://www.gossamer-threads.com/...i?post=109637#109637

Quote:

Under mod_perl, yes GT::CGI would be loaded as well as CGI.pm, but it's only an extra 30kb of memory per child, not much. They don't conflict with each other at all.

Interesting, that they still are conflicting...

Best regards,
Webmaster33

Feb 28, 2005, 8:37 AM

Paul_Wilson

Novice (15 posts)

Feb 28, 2005, 8:37 AM

Post #4 of 7

Shortcut

Re: [webmaster33] CGI.pm & GT::CGI conflict In reply to

If you are only using CGI.pm for $obj->Vars then use GT::CGI's get_hash method...

my %in = %{$IN->get_hash()};

...instead.

Feb 28, 2005, 8:49 AM

webmaster33

Veteran (2312 posts)

Feb 28, 2005, 8:49 AM

Post #5 of 7

Shortcut

Re: [Paul_Wilson] CGI.pm & GT::CGI conflict In reply to

Code:
local (%in) = %{$IN->get_hash()};

Yes, that's exactly what I do now, as a workaround.
But the original confrict is still true. I would like to find answer for the origin of the problem.

Best regards,
Webmaster33

Last edited by:

webmaster33: Feb 28, 2005, 8:52 AM

Mar 1, 2005, 4:45 AM

rocco

User (77 posts)

Mar 1, 2005, 4:45 AM

Post #6 of 7

Shortcut

Re: [webmaster33] CGI.pm & GT::CGI conflict In reply to

Actually, I was suggesting that you use the faster GT::CGI object for everything. It should be easy to replace your CGI.pm calls with GT::CGI ones.

Cheers,

Regards,
Peter Puglisi
www.ausfreedom.com
Ultimate Freedom is our game.

Mar 1, 2005, 5:11 AM

webmaster33

Veteran (2312 posts)

Mar 1, 2005, 5:11 AM

Post #7 of 7

Shortcut

Re: [rocco] CGI.pm & GT::CGI conflict In reply to

I can't really avoid using CGI.pm. I use some features of it, like:
- $CGI::POST_MAX, which has a similar feature, $GT::CGI::MAX_READS, but it's not the same
- upload feature,
- header feature,
- maybe some others, which I don't remember...

I do a serious upgrade now, which takes a lot time.
So I don't have time left for unnecessary changes, like downgrading to the faster GT::CGI.
Speed is not the most important thing now. Speed changes will be only considered later, when benchmarking, profiling, and speed optimizations will be done (if needed at all).

Best regards,
Webmaster33