Re: [Catalyst] My experience porting to CataMoose
On 19 May 2009, at 02:38, Sebastian Willert wrote: . 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. That was brilliant, apologies it's not gone anywhere for a couple of weeks. hkclark++ applied it and yelled at me as part of this round of tutorial updates. I've corrected a few small points, made a couple of changes for best practices, and expanded a little on putting controller actions in roles (as you can now do this!), and munged the previous docs in ::ExtendingCatalyst to be a pointer to the file you added.. Thank you very much for the patch, it'll all be a lot better explained in the new release (which will be soon). Cheers t0m ___ 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
Agreed. Sebastian++ for taking the initiative to do that! Kennedy On Wed, May 27, 2009 at 6:42 PM, Tomas Doran bobtf...@bobtfish.net wrote: On 19 May 2009, at 02:38, Sebastian Willert wrote: . 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. That was brilliant, apologies it's not gone anywhere for a couple of weeks. hkclark++ applied it and yelled at me as part of this round of tutorial updates. I've corrected a few small points, made a couple of changes for best practices, and expanded a little on putting controller actions in roles (as you can now do this!), and munged the previous docs in ::ExtendingCatalyst to be a pointer to the file you added.. Thank you very much for the patch, it'll all be a lot better explained in the new release (which will be soon). Cheers t0m ___ 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/ ___ 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
Tomas Doran wrote: On 13 May 2009, at 16:55, Matt S Trout wrote: Maybe I can whip up some testcases tomorrow .. 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... Cheers t0m ___ 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
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? Great. And yes, that sounds right to me. I'm probably going to do a bit more in ::Upgrading later today, but if you'd like to provide some more comprehensive docs for ::ExtendingCatalyst then that would awesome. Cheers t0m ___ 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, May 13, 2009 at 04:13:06AM +0200, Sebastian Willert wrote: 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. Wrong, sorry. It's an inevitable caveat. The point is that plugin setup changes the app's @ISA, so it simply isn't safe to run modifiers before -setup, or more specifically until after -setup_plugins. 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 :( Fortunately, setup_plugins happens -before- setup_components so you can apply a role any time after that and it'll all work fine. Maybe I can whip up some testcases tomorrow .. Maybe you can whip up some documentation tomorrow? Though it would be nice if modifier application before -setup_plugins produced a warning explaining why that's bad, wrong, and not going to work. -- Matt S Trout Catalyst and DBIx::Class consultancy with a clue Technical Director and a commit bit: http://shadowcat.co.uk/catalyst/ Shadowcat Systems Limited mst (@) shadowcat.co.ukhttp://shadowcat.co.uk/blog/matt-s-trout/ ___ 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
Daisuke Maki wrote: I've switched an application of mine to CataMoose. Thanks for the hard work, it's seems surprisingly stable for such a massive overhaul. Great, thanks a lot, and thanks for the feedback below! I've observed a few glitches / gotchas, they seem like things that probably should be documented, but I'd like to share with the list before writing them up: path_to will return something like /whatever instead of /path/to/MyApp/whatever, because home isn't set. to get around it, you would need to force setup_home() to be called, or say package MyApp; use Moose; use Catalyst; # so import() gets called extends 'Catalyst'; __PACKAGE__-config(...); __PACKAGE__-setup(...); Right, that's a documentation bug.. Fixed in r10091. 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? Cheers t0m ___ 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
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:
package MyApp;
...
before finalize = sub { };
__PACKAGE__-setup( ... );
fails, but
package MyApp;
...
__PACKAGE__-setup( ... );
before finalize = sub { };
works.
looks to me like a Common gotchas documentation.
If you intend to use Moose's method modifiers in your app, do so
/AFTER/ Catalyst-setup has been called.
or some such
--d
___
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/
[Catalyst] My experience porting to CataMoose
Hi,
I've switched an application of mine to CataMoose. Thanks for the hard
work, it's seems surprisingly stable for such a massive overhaul.
I've observed a few glitches / gotchas, they seem like things that
probably should be documented, but I'd like to share with the list
before writing them up:
1. MyApp-config-{home} and Catalyst::Upgrading
Catalyst::Upgrading suggests that the following is possible:
package MyApp;
use Moose;
extends 'Catalyst';
__PACKAGE__-setup( ... );
This is fine, but things gets a bit hairy when you mix this with calls
MyApp-config-{home} BEFORE setup(), for example:
package MyApp;
use Moose;
extends 'Catalyst';
__PACKAGE__-config(
'View::TT' = {
INCLUDE_PATH = __PACKAGE__-path_to('whatever')
}
);
__PACKAGE__-setup( );
path_to will return something like /whatever instead of
/path/to/MyApp/whatever, because home isn't set. to get around it, you
would need to force setup_home() to be called, or say
package MyApp;
use Moose;
use Catalyst; # so import() gets called
extends 'Catalyst';
__PACKAGE__-config(...);
__PACKAGE__-setup(...);
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().
I was doing this in MyApp.pm:
before finalize = sub {
my $c = shift;
$c-handle_exception if @{ $c-error };
};
At that moment, Catalyst::Plugin::Unicode's finalize() stopped from
being called. I fully expected MyApp-finalize() to trigger all the
plugins' finalize(), then Catalyst::finalize(), but it only called
MyApp::finalize() and Catalyst::finalize().
I never got exactly why this happens, but it seems to me like Moose's
Method object interacts oddly with the method dispatch. My fix was to do
override finalize = sub {
my $c = shift;
$c-handle_exception if @{ $c-error };
$c-next::method(@_); # doing super() didn't work here.
};
regards,
--d
P.S. MST: yes, this has been blogged:
http://mt.endeworks.jp/d-6/2009/05/moosification-catalyst-58.html
___
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/
