[Catalyst] Another thread about porting to CataMoose

[J. Shirley]

On Mon, May 18, 2009 at 6:27 PM, Tomas Doran <bobtfish at bobtfish.net> wrote:

> J. Shirley wrote:
>
>> While an obvious blunder to make while coding, I wasn't alerted to
>> anything and the application started with no warnings and no indication =
that
>> something was wrong.  The only thing is that my 'rpx' method no longer w=
as
>> dispatchable.
>>
>> Oops.
>>
>
> Hmm, I think that this is actually by design:
>
>
> http://search.cpan.org/~drolsky/Moose-0.79/lib/Moose/Manual/FAQ.pod#I_cre=
ated_an_attribute,_where_are_my_accessors<http://search.cpan.org/%7Edrolsky=
/Moose-0.79/lib/Moose/Manual/FAQ.pod#I_created_an_attribute,_where_are_my_a=
ccessors>
> ?
>
> I'm sure there is a better explanation somewhere, but I can't find it rig=
ht
> now.
>

I was/am actually populating much more than just 'is' -- I was mostly
talking about the failure of a warning.  I would like to see something like
the subroutine redefine warning... as you mentioned :)


>
>
>  So, I'm pretty far out of my depth for 5.8 but I'd be happy to commit a
>> failing test case -- is the proper test case a situation like this, and
>> failing if the method doesn't define a dispatchable path or something el=
se?
>>  I can imagine this is something that could commonly come up and bite pe=
ople
>> who aren't careful (or working with thick controllers)
>>
>
> I don't think there's any great way to get around this which I can think =
of
> right now.
>
> The best solution I could come up with is to make Catalyst::Controller
> apply a default attribute trait which warned when (Moose) attributes were
> added which overrode methods with (perl) attributes.
>
> If you'd like to commit TODO tests (there is already a Moose specific
> controller in the test suite) which test for an appropriate warning being
> emitted during app startup, then I'll have a crack at seeing if I can do
> something sane enough to be maintainable..
>

I'll see what I can do about this and try not to forget... I'm traveling a
far distance this week, so if I drop the ball on this you can kick me next
week if you remember.


>
> > package MyApp::Controller::Auth;
> >
> > use parent 'Catalyst::Controller';
> >
> > use Moose;
> >
> > has 'rpx' =3D> ( is =3D> 'rw' );
> >
> > sub rpx : Chained('/') Args(0) { }
> >
> > 1;
>
> Note this pattern works, but is mildly disrecommended going forwards. The=
re
> are tests in the test suite that it works in basic cases, but it's not wh=
at
> people are using - so I wouldn't be confident it will stay working for
> non-trivial cases (I have already fixed bugs with doing it this way round=
).
>
> My Moose native controllers look like this:
>
> package MyApp::Controller::Auth;
> use Moose;
> use namespace::autoclean;
>
> BEGIN { extends 'Catalyst::Controller'; }
>
> # Attributes and actions
>
> __PACKAGE__->meta->make_immutable; # Note this returns true, so is good f=
or
> the last line
>
> I did scribble _some_ stuff in Catalyst::Manual::ExtendingCatalyst about
> this, but if you'd like to add anything (or at least tell us what it's
> missing currently), that'd be awesome?
>
>
I assume you mean Upgrade (since Catalyst::Manual is still at 5.7x) -
http://search.cpan.org/~flora/Catalyst-Runtime-5.80003/lib/Catalyst/Upgradi=
ng.pod#Components_which_inherit_from_Moose::Object_before_Catalyst::Compone=
nt

If so... uhm, why :)  I'm curious how the BEGIN block makes the attributes
work (and bypasses Moose::Object), if you don't mind being Professor Tom for
a bit, that is.

Thanks,
-J
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090518/b6780=
df2/attachment.htm