[Catalyst] Re: FYI: Recent breakage in Catalyst installation [resolved]
Fixed in Catalyst::Runtime 5.80030, thanks! Florian Ragwitz r...@debian.org wrote: Sebastian Willert will...@gmail.com writes: Some updates in the dependency chain of Catalyst seem to cause a breakage in Catalyst. The dists in question are: - Class::MOP - namespace::clean - Package::Stash with Package::Stash being the most likely culprit, but the dists above depend on the latest Package::Stash. Until someone more knowledgeable than me figures out what is going on, It's kind of hard to figure out what's going on without knowing what breaks for you. I'll make a WAG though: You upgraded Package::Stash to version 0.16 or greater and didn't also upgrade the modules the Makefile.PL output or the output of `package-stash-conflicts' told you were broken by that upgrade. Another guess would be you having upgraded Package::Stash as well as all the conflicting modules and happen to have Package::Stash::XS installed. Catalyst-Runtime used to rely on a bug in the pure-perl version of Package::Stash, which gets exposed by upgrading Package::Stash to a version that loads Package::Stash::XS automatically and having ::XS available. That happens to be fixed in 5.80030. ___ 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] FYI: Recent breakage in Catalyst installation
Some updates in the dependency chain of Catalyst seem to cause a breakage in Catalyst. The dists in question are: - Class::MOP - namespace::clean - Package::Stash with Package::Stash being the most likely culprit, but the dists above depend on the latest Package::Stash. Until someone more knowledgeable than me figures out what is going on, you can download and install old versions of these modules here and install them manually before installing Catalyst::Runtime itself: http://cpan.org/authors/id/D/DR/DROLSKY/Class-MOP-1.11.tar.gz http://cpan.org/authors/id/F/FL/FLORA/namespace-clean-0.18.tar.gz http://cpan.org/authors/id/D/DO/DOY/Package-Stash-0.13.tar.gz Hope that helps, Sebastian ___ 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] [ANN] MME - The Mason Mockup Engine
MME is a single-file, pure-perl webserver primarily intended to be used
by HTML coders during template development. Great care has been taken to
make usage as unintrusive as possible, all you need is perl 5.8.1+
installation on (hopefully) any platform that is supported by perl (at
least Linux, Mas OS X and Strawberry Perl on WinXP should work out of
the box).
TEMPLATES:
Templates are handled by HTML::Mason 1.42 (without dhandler support) but
currently there is no way to influence parameters, so you are stuck with
defaults for autohandler_name and so on.
ARGS EMULATION:
Neither body nor query parameters are passed on to the templates (give
me a holler when you need that), instead you can place an
[component_file].%args file beside any component file to specify
(additional) args passed to it. You are free to use either JSON (parsed
by JSON::PP) or YAML (parsed by YAML::Tiny) format for this file. The
args are filtered through Data::AsObject, so you can easily say:
%args $my_value /%args
Value: % $my_value-deep-deep-magic %
# for ( $my_value-members ) { $m-print( $_ ) }
Component args take precedence over autohandler args in the request
component.
SECURITY CONSIDERATIONS:
Never EVER use this for any purpose other than local template
development. I don't think it will eat kittens if left alone, but on the
other hand, I didn't spend ANY time trying to figure out if it might.
You have been warned!
DEVELOPMENT
Currently, this program does exactly what I need, so expect no further
development in terms of features. If you have an itch to scratch, I'll
happily accept patches (or even better pull requests), though.
I won't bother to build stand-alone binaries (with embedded perl), but
if anyone will, I'll find a place to host them.
The repository resides at:
http://github.com/willert/mason-mockup-engine
Cheers,
Sebastian
___
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] Handling configuration outside the Catalyst application
On Fri, 2009-08-28 at 12:10 +1000, Daniel Austin wrote: Hello How are you handling configuration for applications or code that run outside of Catalyst? [snip] If you are just trying to emulate Catalyst's config loading mechanism to connect the schema yourself then have a look at Config::JFDI on CPAN, it does (or at least advertises to do) exactly what you want. Hint: maybe use Catalyst::Utils for appprefix and home HTH, Sebastian ___ 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] My experience porting to CataMoose
On Fri, 2009-05-15 at 15:09 +0100, Tomas Doran wrote:
Sebastian Willert wrote:
I'll give it a try this weekend, having 5.80004 is enough
encouragement ;)
I guess the main body should go into Extending Catalyst while having a
pointer to this in Upgrading?
OK, after stumbling through Moose-ifying my first Catalyst app I figured
a larger manual would be in order. Here is my first stab at creating
such a thing. Please bear in mind that English is not my native language
and this is my first dab into Moose so this document is probably rife
with factual and grammatical errors.
Without further ado, I hope a few people find this helpful.
Cheers,
Sebastian
=head1 NAME
Catalyst::Manual::CatalystAndMoose - How Catalyst 5.8+ and Moose relate
=head1 DESCRIPTION
Since version 5.8 the core of Catalyst is based on LMoose. Although the
developers went through great lengths to allow for a seamless transition,
there are still a few rough edges when trying to exploit the power of LMoose
in your Catalyst application.
This document provides you with a short overview of common caveats and best
practices to use LMoose-based classes within Catalyst.
=head1 THE CONTEXT CLASS
A Moose-ified version of the context class should look like this:
package MyApp;
use Moose;
use Catalyst;
$app-config( name = 'MyApp' );
$app-setup(
# your roles and plugins
);
# method modifiers must be created after setup because otherwise they will
# conflict with plugin overrides
after 'finalize' = sub{
my $c = shift;
$c-log-info( 'done!' );
}
You should also be aware, that roles in C $c-setup are applied after the
last plugin with all the benefits of using a single C with() statement in
an ordinary LMoose class and that your class is automatically made immutable
for you after the call to setup (method modifiers in your class will work,
though).
CAVEAT: using roles in C $c-setup was implemented in Catalyst version
5.80004. In prior versions you might get away with
after 'setup_plugins' = sub{ with(
# your roles
)};
$app-setup(
# your plugins
);
but this is discouraged and you should upgrade to 5.80004 anyway, because it
fixes a few important regression against 5.71
[Q: COULD THIS BE USED TO RESOLVE CONFLICTS IN ROLES?].
=head2 ACCESSORS
Most of the request specific attributes like C$c-gt;stash,
C$c-gt;request and C$c-gt;response have been converted to LMoose
attributes but without type constraints, attribute helpers or builder
methods. This ensures that Catalyst 5.8 is fully backwards compatible to
applications using the published API of Catalyst 5.7 but slightly limits
the gains that could be had by wielding the full power of LMoose attributes.
Most of the accessors to information gathered during compile time is managed
by CCatalyst::ClassData, which is a LMoose-aware version of
LClass::Data::Inheritable but not compatible with LMooseX::ClassAttribute.
=head2 ROLES AND METHOD MODIFIERS
Since the release of Catalyst version 5.8 the only reason for creating a
Catalyst extension as a plugin is to provide backward compatibility to
applications still using version 5.7 but even then you should consider
building your plugin using LMoose and take advantage of
LMoose::Manual::MethodModifiers|method modifiers instead of overriding
methods to alter Catalyst's request lifecycle behavior.
If backward compatibility is of no concern to you, you could as easily rewrite
your plugins as roles and enjoy all the benefits of automatic method
re-dispatching of C before and C after method modifiers, naming
conflict detecting and generally cleaner code.
Plugins and roles should never use
after 'setup' = sub { ... } # wrong
but rely on
after 'setup_finalize' = sub { ... } # this will work
to run their own setup code if needed. If they need to influence the setup
process itself, they can modify C setup_dispatcher() ,
C setup_engine(), C setup_stats() , C setup_components()
and C setup_actions() , but this should be done with due consideration and
as late as possible.
=head1 CONTROLLERS
To activate Catalyst's action attributes, Moose-ified controller classes
need to extend LCatalyst::Controller at compile time before the actions
themselves are declared:
package Catalyst::Controller::Root;
use Moose;
BEGIN{
extends 'Catalyst::Controller';
with(
# your controller roles
);
}
[MORE TO BE DONE!]
___
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] My experience porting to CataMoose
On Fri, 2009-05-15 at 14:54 +0100, Tomas Doran wrote: Tomas Doran wrote: On 13 May 2009, at 16:55, Matt S Trout wrote: Maybe you can whip up some documentation tomorrow? Any news on a hand with the documentation anyone? As far as I can see, this is the only thing which really needs sorting out before 5.80004 is ready to ship now... I'll give it a try this weekend, having 5.80004 is enough encouragement ;) I guess the main body should go into Extending Catalyst while having a pointer to this in Upgrading? Cheers, Sebastian ___ 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] My experience porting to CataMoose
On Wed, 2009-05-13 at 07:21 +0900, Daisuke Maki wrote: 2. Hooking to methods that Plugins use via method modifiers breaks method dispatch I got bit by this while depending on Catalyst::Plugin::Unicode, and trying to hook a custom error handling mechanism at finalize(). snip explanation Hmm, that certainally looks like a bug to me.. Any chance that I could get you to write a test case or two for this issue? I get it now, it has to do with when setup() and method modifiers run: snip example code If you intend to use Moose's method modifiers in your app, do so /AFTER/ Catalyst-setup has been called. or some such First of all: thanks for the pointer, you have ended a lot of hair pulling for me. But IMO this is not just a common gotcha but a serious bug. I have a few plugins I am trying to convert to Moose::Role's that desperately need both before 'setup_components' and after 'finalize' This just isn't going to work one way or the other :( Maybe I can whip up some testcases tomorrow .. Cheers, Sebastian ___ 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] Similar attribute appears twice despite a single POST (submit) request.
On Wed, 2009-04-29 at 21:22 +1000, kakim...@tpg.com.au wrote: Hi, everyone, I have come across something interesting. 5) The web form contains the following: a) 'name' = Text box for subscription alias b) 'nominated_agent_code' = Text box for nominated agent code c) 'id' = Hidden value which has the id of the current subscription in question This is just a stab in the dark, but I guess your form tag is missing an action attribute and thus resends to the same URI, thus keeping the id query parameter. This is according to specification: nothing in HTTP disallows using GET-Parameters in POST requests IIRC. Cheers, Sebastian ___ 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] Using Test::Log4perl, testing cat log output only works after firing initial request
On Mon, 2009-03-23 at 15:22 +, Tomas Doran wrote:
Anthony Gladdish wrote:
Has anyone else experienced this problem?
Should this be happening in this way and is there a fix or workaround?
I'm trying to test and iron this out prior to rolling out into production.
I certainly haven't seen this sort of behavior in my applications.
I am noticing this with the latest versions of Log::Log4perl and
Catalyst::Log::Log4perl. The strangest thing is that the problem
goes as soon as you use
Log::Log4perl-get_logger('CatLog4perlTest.Controller.TestLogger')
You dont even have to start the request.
Looks like a bug in the interaction between Test::Log4perl and
Log::Log4perl to me but I haven't found anything in the respective
change logs that would warrant such a change in behavior.
I guess Anthony is on the safe side, just issuing the get_logger command
above before starting the tests.
Hope that helps,
Sebastian
___
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] Using Test::Log4perl, testing cat log output only works after firing initial request
On Mon, 2009-03-23 at 15:22 +, Tomas Doran wrote:
Anthony Gladdish wrote:
Has anyone else experienced this problem?
Should this be happening in this way and is there a fix or workaround?
I'm trying to test and iron this out prior to rolling out into production.
I certainly haven't seen this sort of behavior in my applications.
Can you try reducing the behavior that you're seeing to a test case for
the Catalyst::Log::Log4perl distribution?
And here are your test cases (against C::L::Log4perl 1.03 and Log4perl
1.20). Unfortunately it seems like we can't do anything about this on
our side ...
Cheers,
Sebastian
#!/usr/bin/perl
use strict;
use warnings;
use FindBin;
use lib ( $FindBin::Bin/lib, $FindBin::Bin/../lib );
use Catalyst::Test 'MockApp';
use Test::More;
BEGIN {
eval use Test::Log4perl;;
if ($@) {
plan skip_all = 'Test::Log4perl required for testing logging';
} else {
plan tests = 2;
}
}
my $tlogger = Test::Log4perl-get_logger(MockApp.Controller.Root);
TODO: {
local $TODO = 'First request without prev. get_logger fails';
Test::Log4perl-start();
$tlogger-warn (root/foo);
get('/foo');
Test::Log4perl-end('Got all log messages');
}
Test::Log4perl-start();
$tlogger-warn (root/foo);
get('/foo');
Test::Log4perl-end('The second request send all log messages');
#!/usr/bin/perl
use strict;
use warnings;
use FindBin;
use lib ( $FindBin::Bin/lib, $FindBin::Bin/../lib );
use Catalyst::Test 'MockApp';
use Test::More;
BEGIN {
eval use Test::Log4perl;;
if ($@) {
plan skip_all = 'Test::Log4perl required for testing logging';
} else {
plan tests = 1;
}
}
my $tlogger = Test::Log4perl-get_logger(MockApp.Controller.Root);
Log::Log4perl-get_logger(MockApp.Controller.Root);
Test::Log4perl-start();
$tlogger-warn(root/foo);
get('/foo');
Test::Log4perl-end('Got log messages after initial get_logger call');
#!/usr/bin/perl
use strict;
use warnings;
use FindBin;
use lib ( $FindBin::Bin/lib, $FindBin::Bin/../lib );
use Catalyst::Test 'MockApp';
use Test::More;
BEGIN {
eval use Test::Log4perl;;
if ($@) {
plan skip_all = 'Test::Log4perl required for testing logging';
} else {
plan tests = 2;
}
}
my $tlogger = Test::Log4perl-get_logger(MockApp.Controller.Root);
Log::Log4perl-get_logger(MockApp);
TODO: {
local $TODO = 'First request with get_logger in root category fails';
Test::Log4perl-start();
$tlogger-warn (root/foo);
get('/foo');
Test::Log4perl-end('Got all log messages');
}
Test::Log4perl-start();
$tlogger-warn (root/foo);
get('/foo');
Test::Log4perl-end('The second request send all log messages');
___
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] Opportunity to submit an article to a leading german computer maagazine
Hi all, I just got a request for an Catalyst article that will be published in a special edition of the iX magazine. I wont have time myself so I thought maybe here might be some folks from Germany interested in taking up the offer to promote Catalyst and earn a few bucks. I've written an article few years back and I'd be happy to provide you with the text as reference (don't know if I am legally allowed to provide it as basis for a new article by another author). You can find the request (in German) below, please contact me for details. Cheers, Sebastian Willert Forwarded Message Subject: Perl-Webframework(s) Date: Thu, 05 Feb 2009 15:15:51 +0100 Hallo zusammen, Wir planen, im Frühjahr (Mai/Juni) ein Sonderheft zum Thema Web on Rails zu bringen, dass sich mit Webframeworks für verschiedene Sprachen beschäftigt. Hätten Sie Lust/Zeit, ein Update auf Ihren damaligen Artikel zu verfassen und dabei auf eventuelle Konkurrenz zu Catalyst hinzuweisen? Zum Zeitrahmen: Ich müsste Ihren Artikel im Laufe des April hier haben... Ich würde mich freuen :-) iX - Magazin fuer professionelle Informationstechnik ___ 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] FirePHP::Dispatcher and Catalyst::Plugin::FirePHP
Hi all, I've been working on a perl module that displays messages in the FirePHP[1] console and bindings for the Catalyst logging universe. The only thing you need to do to start using FirePHP is to include Catalyst::Plugin::FirePHP in your plugin list. Everything else should happen automatically, no other config should be needed (at least when using C::Log or C::Log::Log4perl). The current (quite usable) implementation can be found at http://github.com/willert/firephp-perl/ . I'd like to invite you to test, break, criticize to your heart's content. Cheers, Sebastian --- [1] FirePHP enables you to log to your Firebug Console using a simple PHP. All data is sent via response headers and will not interfere with the content on your page. (taken from http://www.firephp.org/) ___ 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] Intermittent blank pages
Tobias Kremer wrote: Two days ago I suddenly started receiving intermittent blank pages. Immediately reloading the page led to the expected response. Looking at the error logs of the past two days I can see loads of the following error: Use of uninitialized value in concatenation (.) or string at /usr/local/lib/perl5/site_perl/5.8.8/Catalyst/Engine/FastCGI.pm line 169. It appears that there just isn't any body data to process. This error was absolutely non-existent until a few days ago. AFAICT the only things that have changed since then is the session table now being InnoDB instead of MyISAM and Rose::HTML::Form has been updated to the latest version (5.7014). Due to there being no additional error messages or warnings I don't know how to debug this. Does anybody here have an idea what could be going wrong? I'm using Catalyst 5.7010. Are you using Perlbal in front of FastCGI? Perlbal is prone to deliver blank pages if the back-end times out. Unfortunately I haven't found a way to avoid this behavior, but maybe someone on the list can help out ... Cheers, Sebastian ___ 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] Re: Patch for Catalyst::View::Mason
On Sat, 2008-03-08 at 07:26 +0100, Aristotle Pagaltzis wrote: * Christopher H. Laco [EMAIL PROTECTED] [2008-03-07 22:25]: I go one stranger. No extensions ever. Instead, I rely on directories assuming I might switch. templates/tt/controller/action templates/mason/controller/action That’s the best approach. The only reason I don’t do it that way is syntax highlighting. Though I suppose I could litter all my files with modelines… Guessing you are on Emacs you could simply put those lines in your config (untestet, and I am not very fluent in elisp): ;; mmm-mode for mason (require 'mmm-auto) (autoload 'html-mode xml-html-mode Load html-mode t) (setq auto-mode-alist (cons '(\\/templates/mason/ 'xml-html-mode) auto-mode-alist)) (mmm-add-mode-ext-class nil \\/templates/mason/ 'mason ) Cheers Sebastian ___ 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/
