-Known Bugs:
+# Known Bugs:
- Bug ->go or ->visit causes actions which have Args or CaptureArgs called
twice when called via ->go or ->visit.
Test app: http://github.com/bobtfish/catalyst-app-bug-go_chain/tree/master
-Compatibility warnings to add:
-
- - $self->config should warn as config should only ever be called as a
- class method.
-
-Proposed functionality / feature additions:
-
- - Log setup needs to be less lame, so Catalyst::Plugin::Log::* can die
- in a fire. Having $c->log_class would be a good start. kane volunteered
- to do some of this.
-
- Simple example: Catalyst::Plugin::Log::Colorful should just be a
- subclass of Catalyst::Log, no ::Plugin:: needed.
-
- See also: Catalyst::Plugin::Log::Dispatch and
- http://github.com/willert/catalyst-plugin-log4perl-simple/tree
-
- Fixes to component interfaces to deal with anon classes:
-
-22:16 <@mst> t0m: explain what breaks
-22:16 <@mst> I'm not 100% sure we have the same problem in mind
-22:17 <@t0m> well, various shit in Catalyst utils to resolve app from MyApp::Controller::Foo breaks
-22:17 <@mst> Caelum: http://scsys.co.uk:8001/31240
-22:17 <@mst> t0m: the trick would be to not need to do that
-22:17 <@mst> t0m: $self->_application should be fine
-22:18 <@t0m> $action->class can't be fed back into $c->component()
-22:18 <@t0m> which breaks ::REST
-22:18 <@mst> right
-22:18 <@mst> we need to
-22:19 <@mst> (a) add an ->_component_name or similar method to controllers
-22:19 <@mst> (b) pass action objects either that or the controller
-22:20 <@t0m> do you have a controller calling $action->dispatch? Course you must, the action lives in a controller..
-22:21 <@mst> and that doesn't matter anyway
-22:21 <@mst> dispatch has $c
-22:21 <@mst> it needs to do
-22:21 <@mst> $c->component($self->_component_name)
-22:21 <@mst> and that _component_name needs to come from the controller at register_actions time
-22:22 <@t0m> confound: Oi, please to be releasing my Action::REST fixes, I'm about to do more..
-22:22 <@t0m> mst: right, gotcha
-22:22 <@mst> note that needs to happen in core
-22:22 <@mst> then actions can use that instead of $self->class
-22:22 <@mst> and shit will work
+ - Bricas' Exception blog post
+
+ http://bricas.vox.com/library/post/catalyst-exceptionclass.html
+
+ Broken by recent exception refactoring
+
+# Compatibility warnings to add:
+
+ - $self->config should warn as config should only ever be called as a
+ class method.
+
+# Proposed functionality / feature additions:
+
+## Log setup needs to be less lame
+
+So Catalyst::Plugin::Log::* can die
+in a fire. Having $c->log_class would be a good start. kane volunteered
+to do some of this.
+
+Simple example: Catalyst::Plugin::Log::Colorful should just be a
+subclass of Catalyst::Log, no ::Plugin:: needed.
+
+See also: Catalyst::Plugin::Log::Dispatch and
+http://github.com/willert/catalyst-plugin-log4perl-simple/tree
+
+# REFACTORING
+
+## The horrible hack for plugin setup - replacing it:
+
+ * Have a look at the Devel::REPL BEFORE_PLUGIN stuff
+ I wonder if what we need is that combined with plugins-as-roles
+
+## App / ctx split:
+
+ NOTE - these are notes that t0m thought up after doing back compat for
+ _component_class, may be inaccurate, wrong or missing things
+ bug mst (at least) to correct before trying more than the first 2
+ steps. Please knock yourself out on the first two however :)
+
+ - Eliminate actions in MyApp from the main test suite
+ - Uncomment warning in C::C::register_action_methods, add tests it works
+ by mocking out the logging..
+ - Remove MyApp @ISA controller (ask metaclass if it has attributes, and if
+ so you need back compat :/)
+ - Make Catalyst::Context, move the per request stuff in there, handles from
+ main app class to delegate
+ - Make an instance of the app class which is a global variable
+ - Make new instance of the context class, not the app class per-request
+ - Remove the components as class data, move to instance data on the app
+ class (you probably have to do this for _all_ the class data, good luck!)
+ - Make it possible for users to spin up different instances of the app class
+ (with different config etc each)
+ - Profit! (Things like changing the complete app config per vhost, i.e.
+ writing a config loader / app class role which dispatches per vhost to
+ differently configured apps is piss easy)
+
$c->forward(qw/MyApp::Model::DBIC::Foo do_stuff/);
$c->forward('MyApp::View::TT');
-Note that forward implies an C<<eval { }>> around the call (actually
-C<execute> does), thus de-fatalizing all 'dies' within the called
-action. If you want C<die> to propagate you need to do something like:
+Note that L<< forward|/"$c->forward( $action [, \@arguments ] )" >> implies
+an C<< eval { } >> around the call (actually
+L<< execute|/"$c->execute( $class, $coderef )" >> does), thus de-fatalizing
+all 'dies' within the called action. If you want C<die> to propagate you
+need to do something like:
$c->forward('foo');
die $c->error if $c->error;
=head2 $c->detach()
-The same as C<forward>, but doesn't return to the previous action when
-processing is finished.
+The same as L<< forward|/"$c->forward( $action [, \@arguments ] )" >>, but
+doesn't return to the previous action when processing is finished.
When called with no arguments it escapes the processing chain entirely.
=head2 $c->visit( $class, $method, [, \@captures, \@arguments ] )
-Almost the same as C<forward>, but does a full dispatch, instead of just
-calling the new C<$action> / C<$class-E<gt>$method>. This means that C<begin>,
-C<auto> and the method you go to are called, just like a new request.
+Almost the same as L<< forward|/"$c->forward( $action [, \@arguments ] )" >>,
+but does a full dispatch, instead of just calling the new C<$action> /
+C<< $class->$method >>. This means that C<begin>, C<auto> and the method
+you go to are called, just like a new request.
In addition both C<< $c->action >> and C<< $c->namespace >> are localized.
-This means, for example, that $c->action methods such as C<name>, C<class> and
-C<reverse> return information for the visited action when they are invoked
-within the visited action. This is different from the behavior of C<forward>
-which continues to use the $c->action object from the caller action even when
+This means, for example, that C<< $c->action >> methods such as
+L<name|Catalyst::Action/name>, L<class|Catalyst::Action/class> and
+L<reverse|Catalyst::Action/reverse> return information for the visited action
+when they are invoked within the visited action. This is different from the
+behavior of L<< forward|/"$c->forward( $action [, \@arguments ] )" >>, which
+continues to use the $c->action object from the caller action even when
invoked from the callee.
-C<$c-E<gt>stash> is kept unchanged.
+C<< $c->stash >> is kept unchanged.
-In effect, C<visit> allows you to "wrap" another action, just as it
-would have been called by dispatching from a URL, while the analogous
-C<go> allows you to transfer control to another action as if it had
-been reached directly from a URL.
+In effect, L<< visit|/"$c->visit( $action [, \@captures, \@arguments ] )" >>
+allows you to "wrap" another action, just as it would have been called by
+dispatching from a URL, while the analogous
+L<< go|/"$c->go( $action [, \@captures, \@arguments ] )" >> allows you to
+transfer control to another action as if it had been reached directly from a URL.
=cut
=head2 $c->go( $class, $method, [, \@captures, \@arguments ] )
-Almost the same as C<detach>, but does a full dispatch like C<visit>,
+Almost the same as L<< detach|/"$c->detach( $action [, \@arguments ] )" >>, but does a full dispatch like L</visit>,
instead of just calling the new C<$action> /
-C<$class-E<gt>$method>. This means that C<begin>, C<auto> and the
+C<< $class->$method >>. This means that C<begin>, C<auto> and the
method you visit are called, just like a new request.
-C<$c-E<gt>stash> is kept unchanged.
+C<< $c->stash >> is kept unchanged.
=cut
__PACKAGE__->config( { db => 'dsn:SQLite:foo.db' } );
-You can also use a C<YAML>, C<XML> or C<Config::General> config file
-like myapp.conf in your applications home directory. See
+You can also use a C<YAML>, C<XML> or L<Config::General> config file
+like C<myapp.conf> in your applications home directory. See
L<Catalyst::Plugin::ConfigLoader>.
=head3 Cascading configuration
Merges C<@path> with C<< $c->config->{home} >> and returns a
L<Path::Class::Dir> object. Note you can usually use this object as
a filename, but sometimes you will have to explicitly stringify it
-yourself by calling the C<<->stringify>> method.
+yourself by calling the C<< ->stringify >> method.
For example:
$class->setup_finished(1);
}
-=head2 $c->uri_for( $action, \@captures?, @args?, \%query_values? )
-
=head2 $c->uri_for( $path, @args?, \%query_values? )
-=over
-
-=item $action
-
-A Catalyst::Action object representing the Catalyst action you want to
-create a URI for. To get one for an action in the current controller,
-use C<< $c->action('someactionname') >>. To get one from different
-controller, fetch the controller using C<< $c->controller() >>, then
-call C<action_for> on it.
-
-You can maintain the arguments captured by an action (e.g.: Regex, Chained)
-using C<< $c->req->captures >>.
+=head2 $c->uri_for( $action, \@captures?, @args?, \%query_values? )
- # For the current action
- $c->uri_for($c->action, $c->req->captures);
+Constructs an absolute L<URI> object based on the application root, the
+provided path, and the additional arguments and query parameters provided.
+When used as a string, provides a textual URI.
+
+If the first argument is a string, it is taken as a public URI path relative
+to C<< $c->namespace >> (if it doesn't begin with a forward slash) or
+relative to the application root (if it does). It is then merged with
+C<< $c->request->base >>; any C<@args> are appended as additional path
+components; and any C<%query_values> are appended as C<?foo=bar> parameters.
+
+If the first argument is a L<Catalyst::Action> it represents an action which
+will have its path resolved using C<< $c->dispatcher->uri_for_action >>. The
+optional C<\@captures> argument (an arrayref) allows passing the captured
+variables that are needed to fill in the paths of Chained and Regex actions;
+once the path is resolved, C<uri_for> continues as though a path was
+provided, appending any arguments or parameters and creating an absolute
+URI.
+
+The captures for the current request can be found in
+C<< $c->request->captures >>, and actions can be resolved using
+C<< Catalyst::Controller->action_for($name) >>. If you have a private action
+path, use C<< $c->uri_for_action >> instead.
+
+ # Equivalent to $c->req->uri
+ $c->uri_for($c->action, $c->req->captures,
+ @{ $c->req->args }, $c->req->params);
# For the Foo action in the Bar controller
- $c->uri_for($c->controller('Bar')->action_for('Foo'), $c->req->captures);
+ $c->uri_for($c->controller('Bar')->action_for('Foo'));
-=back
+ # Path to a static resource
+ $c->uri_for('/static/images/logo.png');
=cut
$c->stats->profile( end => $info );
}
-=head2 $c->_localize_fields( sub { }, \%keys );
-
-=cut
-
-#Why does this exist? This is no longer safe and WILL NOT WORK.
-# it doesnt seem to be used anywhere. can we remove it?
-sub _localize_fields {
- my ( $c, $localized, $code ) = ( @_ );
-
- my $request = delete $localized->{request} || {};
- my $response = delete $localized->{response} || {};
-
- local @{ $c }{ keys %$localized } = values %$localized;
- local @{ $c->request }{ keys %$request } = values %$request;
- local @{ $c->response }{ keys %$response } = values %$response;
-
- $code->();
-}
-
=head2 $c->finalize
Finalizes the request.
application class name prepended to them.
All components found will also have any
-L<Devel::InnerPackage|inner packages> loaded and set up as components.
+L<inner packages|Devel::InnerPackage> loaded and set up as components.
Note, that modules which are B<not> an I<inner package> of the main
file namespace loaded will not be instantiated as components.
my $suffix = Catalyst::Utils::class2classsuffix( $component );
my $config = $class->config->{ $suffix } || {};
- # Stash _component_name in the config here, so that custom COMPONENT
- # methods also pass it. local to avoid pointlessly shitting in config
- # for the debug screen, as $component is already the key name.
- local $config->{_component_name} = $component;
-
+ $config->{_component_name} = $component; # Put this in args here, rather
+ # than in COMPONENT as there
+ # are lots of custom COMPONENT
+ # methods..
my $instance = eval { $component->COMPONENT( $class, $config ); };
if ( my $error = $@ ) {
=head2 L<Catalyst::Manual> - The Catalyst Manual
-=head2 L<Catalyst::Component>, L<Catalyst::Base> - Base classes for components
+=head2 L<Catalyst::Component>, L<Catalyst::Controller> - Base classes for components
=head2 L<Catalyst::Engine> - Core engine
Geoff Richards
+hobbs: Andrew Rodland <andrew@cleverdomain.org>
+
ilmari: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
jcamacho: Juan Camacho
+jester: Jesse Sheidlower
+
jhannah: Jay Hannah <jay@jays.net>
Jody Belka
jon: Jon Schutz <jjschutz@cpan.org>
+konobi: Scott McWhirter <konobi@cpan.org>
+
marcus: Marcus Ramberg <mramberg@cpan.org>
miyagawa: Tatsuhiko Miyagawa <miyagawa@bulknews.net>
sky: Arthur Bergman
-the_jester: Jesse Sheidlower
-
t0m: Tomas Doran <bobtfish@bobtfish.net>
Ulf Edvinsson
projects / catagits/Catalyst-Runtime.git / commitdiff