Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Catalyst: Users

My experience porting to CataMoose

 

 

Catalyst users RSS feed   Index | Next | Previous | View Threaded


daisuke at endeworks

May 11, 2009, 8:16 PM

Post #1 of 13 (1617 views)
Permalink
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 [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


jshirley at gmail

May 12, 2009, 2:08 AM

Post #2 of 13 (1553 views)
Permalink
Re: My experience porting to CataMoose [In reply to]

2009/5/12 Daisuke Maki <daisuke [at] endeworks>

> 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')
> }
> );
>

[snip]

My opinion on this is that this configuration style is inferior to using
'__path_to(whatever)__', which is handled via ConfigLoader. The main reason
is that I often times find myself cutting out and copying configuration into
(conf|yml) files.

Not that this is an excuse for the issue you have, but I just wanted to
offer my (hopefully helpful) two cents.

Thanks for the time you've spent, as well as blogging about it.

-J


bobtfish at bobtfish

May 12, 2009, 5:00 AM

Post #3 of 13 (1551 views)
Permalink
Re: My experience porting to CataMoose [In reply to]

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 [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


daisuke at endeworks

May 12, 2009, 3:21 PM

Post #4 of 13 (1533 views)
Permalink
Re: My experience porting to CataMoose [In reply to]

>> 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 [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


willert at gmail

May 12, 2009, 7:13 PM

Post #5 of 13 (1523 views)
Permalink
Re: My experience porting to CataMoose [In reply to]

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 [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


dbix-class at trout

May 13, 2009, 8:55 AM

Post #6 of 13 (1512 views)
Permalink
Re: My experience porting to CataMoose [In reply to]

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.uk http://shadowcat.co.uk/blog/matt-s-trout/

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


bobtfish at bobtfish

May 13, 2009, 3:38 PM

Post #7 of 13 (1509 views)
Permalink
Re: My experience porting to CataMoose [In reply to]

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

http://dev.catalystframework.org/svnweb/Catalyst/revision?rev=10137

I started some basic docs (the Moose section), but thinking about it
- this should probably be in Catalyst::Manual::ExtendingCatalyst or
somewhere - what do people think, and where should it be linked from?

And if you could flesh-out my explanation somewhat, possibly with
examples, that'd be awesome?

Cheers
t0m



_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


bobtfish at bobtfish

May 15, 2009, 6:54 AM

Post #8 of 13 (1484 views)
Permalink
Re: My experience porting to CataMoose [In reply to]

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 [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


willert at gmail

May 15, 2009, 7:04 AM

Post #9 of 13 (1483 views)
Permalink
Re: My experience porting to CataMoose [In reply to]

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 [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


bobtfish at bobtfish

May 15, 2009, 7:09 AM

Post #10 of 13 (1486 views)
Permalink
Re: My experience porting to CataMoose [In reply to]

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 [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


willert at gmail

May 18, 2009, 6:38 PM

Post #11 of 13 (1355 views)
Permalink
Re: My experience porting to CataMoose [In reply to]

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
Attachments: catalyst-manual-moose (3.73 KB)


bobtfish at bobtfish

May 27, 2009, 3:42 PM

Post #12 of 13 (1208 views)
Permalink
Re: My experience porting to CataMoose [In reply to]

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 [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


hkclark at gmail

May 27, 2009, 4:05 PM

Post #13 of 13 (1203 views)
Permalink
Re: My experience porting to CataMoose [In reply to]

Agreed. Sebastian++ for taking the initiative to do that!

Kennedy

On Wed, May 27, 2009 at 6:42 PM, Tomas Doran <bobtfish [at] bobtfish> 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 [at] lists
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
> Dev site: http://dev.catalyst.perl.org/
>

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

Catalyst users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.