Catalyst-Runtime

 view release on metacpan or  search on metacpan

Changes  view on Meta::CPAN

  - Require the latest version of B::Hooks::EndOfScope (0.10) to avoid an
    issue with new versions of Module::Runtime (0.012) on perl 5.10
    which stopped Catalyst::Controller from compiling.

  - In Catalyst::Test, don't mangle headers of non-HTML responses. RT#79043

5.90008 - TRIAL 2012-02-06 20:49:00

 New features and refactoring:
  - Much of the Catalyst::Engine code has been moved into Catalyst::Request
    and Catalyst::Response, to be able to better support asynchronous web
    servers such as Twiggy, by making the application engine more reenterant.

    This change is as a prequel to full asynchronous support inside Catalyst
    for AnyEvent and IO::Async backends, which allow highly scaleable streaming
    (for applications such as multi-part XML HTTPRequests, and Websockets).

 Deprecations:
  - This means that the $c->engine->env method to access the PSGI environment
    is now deprecated. The accessor for the PSGI env is now on Catalyst::Request
    as per applications which were using Catalyst::Engine::PSGI

    Catalyst::Engine::PSGI is now considered fully deprecated.

lib/Catalyst/Engine.pm  view on Meta::CPAN

=head1 DESCRIPTION

=head1 METHODS


=head2 $self->finalize_body($c)

Finalize body.  Prints the response output as blocking stream if it looks like
a filehandle, otherwise write it out all in one go.  If there is no body in
the response, we assume you are handling it 'manually', such as for nonblocking
style or asynchronous streaming responses.  You do this by calling L</write>
several times (which sends HTTP headers if needed) or you close over
C<< $response->write_fh >>.

See L<Catalyst::Response/write> and L<Catalyst::Response/write_fh> for more.

=cut

sub finalize_body {
    my ( $self, $c ) = @_;
    my $res = $c->response; # We use this all over

lib/Catalyst/Response.pm  view on Meta::CPAN

writer, this proxy object knows any application wide encoding, and provides a method
C<write_encoded> that will properly encode your written lines based upon your
encoding settings.  By default in L<Catalyst> responses are UTF-8 encoded and this
is the encoding used if you respond via C<write_encoded>.  If you want to handle
encoding yourself, you can use the C<write> method directly.

Encoding only applies to content types for which it matters.  Currently the following
content types are assumed to need encoding: text (including HTML), xml and javascript.

We provide access to this object so that you can properly close over it for use in
asynchronous and nonblocking applications.  For example (assuming you are using a supporting
server, like L<Twiggy>:

    package AsyncExample::Controller::Root;

    use Moose;

    BEGIN { extends 'Catalyst::Controller' }

    sub prepare_cb {
      my $write_fh = pop;

lib/Catalyst/Upgrading.pod  view on Meta::CPAN

modify the error stack so if you are relying on that not being changed you should try something
like @{$c->errors}[-1] instead.  Since this method is relatively new and the cases when the
error stack actually has more than one error in it, we feel the exposure is very low, but bug
reports are very welcomed.

=head1 Upgrading to Catalyst 5.90090

L<Catalyst::Utils> has a new method 'inject_component' which works the same as the method of
the same name in L<CatalystX::InjectComponent>.  You should start converting any
use of the non core method in your code as future changes to Catalyst will be
synchronized to the core method first.  We reserve the right to cease support
of the non core version should we reach a point in time where it cannot be
properly supported as an external module.  Luckily this should be a trivial
search and replace.  Change all occurrences of:

    CatalystX::InjectComponent->inject(...)

Into

    Catalyst::Utils::inject_component(...)

lib/Catalyst/Utils.pm  view on Meta::CPAN


    Catalyst::Utils::inject_component( into => $myapp, component => 'MyRootV', as => 'Controller::Root' );

Will inject Controller, Model, and View components into your Catalyst application
at setup (run)time. It does this by creating a new package on-the-fly, having that
package extend the given component, and then having Catalyst setup the new component
(via $app->setup_component).

B<NOTE:> This is basically a core version of L<CatalystX::InjectComponent>.  If you were using that
you can now use this safely instead.  Going forward changes required to make this work will be
synchronized with the core method.

B<NOTE:> The 'traits' option is unique to the L<Catalyst::Utils> version of this feature.

B<NOTE:> These injected components really need to be a L<Catalyst::Component> and a L<Moose>
based class.

=cut

sub inject_component {
    my %given = @_;



( run in 0.498 second using v1.01-cache-2.11-cpan-05444aca049 )