[Catalyst-dev] Moose + Catalyst port

[Guillermo Roditi]

>  COMPONENT is for instantiating a Component at Catalyst startup time.
>  ACCEPT_CONTEXT is for instantiating a Component at request time.  This
>  model doesn't need to change.

And it won't. But my main issue was that I couldn't strip NEXT out of Component
until I read your last message. My new sub looks like this :

sub COMPONENT {
    my ( $self, $c ) = @_;
    # Temporary fix, some components does not pass context to constructor
    my $arguments = ( ref( $_[-1] ) eq 'HASH' ) ? $_[-1] : {};
    return $self->new( $c, $arguments );
}

Which should work because since this will be the base, the old next
behavior can just be achieved with "around COMPONENT => sub {...};"


>  > I think the biggest thing to think about is plugins, since that's a
>  > major piece of how Catalyst works. It'd be nice if plugins could be
>  > defined in a way that didn't involve jamming a bazillion roles into
>  > the Catalyst namespace ;)
>
>  Most of the things that are plugins shouldn't be.  Sessions and
>  Authentication will both be models.  That leaves plugins for things
>  like:

Yeahhh. we'll see. For the time being I'd like to keep some sort of
compat until we have a critical mass of converted plugins. mst will
help, as evidenced by the following:

14:53 <@mst> I'll do that part if others won't
14:53 <@mst> I -enjoy- compat hacking

Well volunteered!

>   package MyApp;
>   use Catalyst qw(DebugRequest);  # this is now one of those clever
>                                   # Moose->import_to things

Class level or instance level? quick, pick one! I vote class-level.

>  It should be possible to apply Plugins to the other classes:

Then those classes should be pluggable themselves?

>   * config (let's make this a class; a plugin can then load config
>     files, etc.)

How exactly do you propose this one works? I just don't see what you
mean. I like it just fine as an accessor to a hashref, I think it
works nicely.

>   * request
>   * response
>   * logger (maybe standardize on MX::LogDispatch)
>   * application (that's the above thing)
>   * context

Notice the App / CTX split is not done yet and is outside the scope of
this project. if someone figures out the details with that I'd be glad
to merge the patches to the moose port, but I am not putting my hands
in that mess just yet.

>   * stash (?) # the idea here is to impose some structure on $c->stash
>               # on a per-request basis

Again, I am not disagreeing, but I think those things are outside the
scope of this port and can be developed separately and then merged in.
One bite at a time.

>  This is easy enough to implement:
>   package Catalyst;
>   has logger => (
>     is      => 'ro',
>     isa     => 'Catalyst::Log',
>     default => sub {
>         Moose::Meta::Class->create_anon_instance(
>             superclasses => ['Catalyst::Log'],
>             roles        => [$self->_logger_roles],
>     };
>   );

There's other ways to do it as well, but yeah, it can work like that.
My idea to make the other classes pluggable would have worked
something like:

around _build_logger => sub {
  my $logger = shift->(@_);
  $logger->load_plugin("My::Role::Plugin");
};

But then again, it's too early for this kind of talk. APIs should be
designed more carefully and with more input.


-- 
Guillermo Roditi (groditi)