[Catalyst] "Global $r object is not available" error
Hi List, I'm configuring apache mod_perl to work with Catalyst according to the cookbook, but this error showed up when I restarts apache. It occurs when my catalyst application tries to start up by calling "__PACKAGE__->setup;" [error] Global $r object is not available. Set: PerlOptions +GlobalRequest in httpd.conf at /usr/lib/perl5/5.8.6/CGI.pm line 361. Compilation failed in require at (eval 2) line 3. I have dug around internet, but there weren't much info about this error. I have added "PerlOptions" to my conf file, updated CGI.pm to the latest version, but they didn't help. My Apache version is 2.0.55, and modperl is 2.0.2. Some post suspect there's a bug for "PerlOption" in modperl. So, I'm gonna update those next, but hopping someone would know something about it. Thanks, BC This correspondence is from Napster, Inc. or its affiliated entities and is intended only for use by the recipient named herein. This correspondence may contain privileged, proprietary and/or confidential information, and is intended only to be seen and used by named addressee(s). You are notified that any discussion, dissemination,distribution or copying of this correspondence and any attachments, is strictly prohibited, unless otherwise authorized or consented to in writing by the sender. If you have received this correspondence in error, please notify the sender immediately, and please permanently delete the original and any copies of it and any attachment and destroy any related printouts without reading or copying them. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Duplicate entries with C::P::Session::Store::DBIC and MySQL - new findings
On Wed, Aug 27, 2008 at 10:41:11AM +0200, Tobias Kremer wrote: > Quoting Moritz Onken <[EMAIL PROTECTED]>: > > Am 27.08.2008 um 10:19 schrieb Tobias Kremer: > > > Ok, a second glance (after the first coffee) revealed that the > > > separation is indeed there :) The question is, why? > > > > Just guessing: > > not every request has its own session object. There are users with no > > session attached to them. > > That was my first guess, too. But AFAICT each and every user receives a > session > on its first visit - logged-in or not. Only if you write to $c->session. But if you write to $c->flash, then you have to create a cookie, so I guess you're effectively creating a session anyway. So as long as you have to write to one of the two to create a session, I don't really see a problem. -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Directorhttp://www.shadowcat.co.uk/catalyst/ Shadowcat Systems Ltd. Want a managed development or deployment platform? http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] RFC & FYI: HTML::FormFu::ExtJS
Hi, HTML::FormFu::ExtJS uses the validation and processing power of HTML::FormFu and combines it with the great abilities of the JavaScript framework ExtJS to generate more intuitive forms. There is no difference in the form config file. You simply replace HTML::FormFu->new with HTML::FormFu::ExtJS->new and you are done. The result of $form->render is a string of JavaScript which generates a Ext.FormPanel. Have a look at the examples which show the output of FormFu next to FormFu::ExtJS: http://search.cpan.org/src/PERLER/HTML-FormFu-ExtJS-0.01/examples/html/ All FormFu elements are supported. See the docs for more information and caveats. I use this module in a productive project already. But this project does not cover all possible variations of forms so there might be some bugs. There will be a HTML::FormFu::ExtJS::Grid module in the near future which helps you to generate the config parameters for an ExtJS grid view from a formfu config file. Suggestions, comments, bugs are welcome! moritz ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Duplicate entries with C::P::Session::Store::DBIC and MySQL - new findings
Quoting Moritz Onken <[EMAIL PROTECTED]>: > Am 27.08.2008 um 10:19 schrieb Tobias Kremer: > > Ok, a second glance (after the first coffee) revealed that the > > separation is indeed there :) The question is, why? > > Just guessing: > not every request has its own session object. There are users with no > session attached to them. That was my first guess, too. But AFAICT each and every user receives a session on its first visit - logged-in or not. Can we confirm this? --Tobias ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Duplicate entries with C::P::Session::Store::DBIC and MySQL - new findings
Am 27.08.2008 um 10:19 schrieb Tobias Kremer: Quoting Tobias Kremer <[EMAIL PROTECTED]>: Quoting Daniel Westermann-Clark <[EMAIL PROTECTED]>: The "flash:" rows were used for compatibility with Store::DBI. We can break compatibility if people find the it not very useful. I have to admit that I don't understand what compatibility with Store::DBI you're talking about. AFAICT the Store::DBI source doesn't separate between "session" and "flash" (does it support the flash at all?). Maybe you (or Andy) can shed some light on this! Ok, a second glance (after the first coffee) revealed that the separation is indeed there :) The question is, why? Just guessing: not every request has its own session object. There are users with no session attached to them. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Duplicate entries with C::P::Session::Store::DBIC and MySQL - new findings
Quoting Tobias Kremer <[EMAIL PROTECTED]>: > Quoting Daniel Westermann-Clark <[EMAIL PROTECTED]>: > > The "flash:" rows were used for compatibility with Store::DBI. We can > > break compatibility if people find the it not very useful. > I have to admit that I don't understand what compatibility with Store::DBI > you're talking about. AFAICT the Store::DBI source doesn't separate between > "session" and "flash" (does it support the flash at all?). Maybe you (or > Andy) can shed some light on this! Ok, a second glance (after the first coffee) revealed that the separation is indeed there :) The question is, why? --Tobias ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Duplicate entries with C::P::Session::Store::DBIC and MySQL - new findings
Quoting Daniel Westermann-Clark <[EMAIL PROTECTED]>:
> On 2008-08-26 09:47:59 +0200, Tobias Kremer wrote:
> > Please note, that this is ONLY happening with the flash part - my
> > sessions work 100% accurate all the time!
> How are you interacting with the flash vs. your sessions? Could you
> provide some code illustrating the problem? A test would be even
> better.
Hmm .. Nothing special there. The session stuff works just by use'ing the
neccessary plugins (no additional tinkering is done) and the flash stuff is
used like this:
a) In my controllers:
push @{$c->flash->{'messages'}}, "You have a message!";
b) In my wrapper template:
[% flash_messages = Catalyst.flash.messages %]
[% IF flash_messages %]
[% FOR message IN flash_messages %]
[% message %]
[% END %]
[% END %]
It's hard to come up with a test-case for this because it only happens in
moderate to high load situations.
--Tobias
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Duplicate entries with C::P::Session::Store::DBIC and MySQL - new findings
Quoting Daniel Westermann-Clark <[EMAIL PROTECTED]>: > On 2008-08-26 14:18:18 +0200, Tobias Kremer wrote: > > Just out of pure curiosity: Why is it that there are dedicated > > "flash:" entries in the storage for the flash? Wouldn't the > > session be enough? > > The "flash:" rows were used for compatibility with Store::DBI. We can > break compatibility if people find the it not very useful. We definitely should! IMHO five queries per request to the database just for the session and flash stuff is inacceptable. The alternative approach could very well get rid of the race-condition, too. I think it's really worth it. I have to admit that I don't understand what compatibility with Store::DBI you're talking about. AFAICT the Store::DBI source doesn't separate between "session" and "flash" (does it support the flash at all?). Maybe you (or Andy) can shed some light on this! --Tobias ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Win32, Data::Alias, bad idea or my bad?
2008/8/26 Matt S Trout <[EMAIL PROTECTED]> > On Tue, Aug 26, 2008 at 03:20:14PM +0200, Kai Andresen wrote: > > I've been trying to get a nice litle Catalyst application to run on > > developers win32 machines the recent week. > > > > Strawberry, ActiveState and Cygwin. All fail on something, but they all > fail > > on building Data::Alias, which both Configloader and RenderView depends > > upon. > > Yep, previous thought confirmed. force for the moment, there'll be a > Data::Visitor release that doesn't ask for Data::Alias shortly. > > Nice, thanks. It brings me an important step further! Kai ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
