Ubuntu Manpages

Catalyst::Delta

Overview of changes between versions of Catalyst

This is an overview of the user-visible changes to Catalyst between major Catalyst releases.

VERSION 5.90053

We are now clarifying the behavior of log, plugins and configuration during the setup phase. Since Plugins might require a log during setup, setup_log must run BEFORE setup_plugins. This has the unfortunate side effect that anyone using the popular ConfigLoader plugin will not be able to supply configuration to custom logs since the configuration is not yet finalized when setup_log is run (when using ConfigLoader, which is a plugin and is not loaded until later.)

As a workaround, you can supply custom log configuration directly into the configuration:

    package MyApp;
    use Catalyst;
    __PACKAGE__->config(
      my_custom_log_info => { %custom_args },
    );
    __PACKAGE__->setup;

If you wish to configure the custom logger differently based on ENV, you can try:

    package MyApp;
    use Catalyst;
    use Catalyst::Utils;
    __PACKAGE__->config(
      Catalyst::Utils::merge_hashes(
        +{ my_custom_log_info => { %base_custom_args } },
        +{ do __PACKAGE__->path_to( $ENV{WHICH_CONF}."_conf.pl") },
      ),
    );
    __PACKAGE__->setup;

Or create a standalone Configuration class that does the right thing.

Basically if you want to configure a logger via Catalyst global configuration you can't use ConfigLoader because it will always be loaded too late to be of any use. Patches and workaround options welcomed!

VERSION 5.9XXXX 'cataplack'

The Catalyst::Engine sub-classes have all been removed and deprecated, to be replaced with Plack handlers.

Plack is an implementation of the PSGI specification, which is a standard interface between web servers and application frameworks.

This should be no different for developers, and you should not have to migrate your applications unless you are using a custom engine already.

This change benefits Catalyst significantly by reducing the amount of code inside the framework, and means that the framework gets upstream bug fixes in Plack, and automatically gains support for any web server which a PSGI compliant handler is written for.

It also allows you more flexibility with your application, and allows the use of cross web framework 'middleware'.

Developers are recommended to read Catalyst::Upgrading for notes about upgrading, especially if you are using an unusual deployment method.

Documentation for how to take advantage of PSGI can be found in Catalyst::PSGI, and information about deploying your application has been moved to Catalyst::Manual::Deployment.

Updated modules:

A number of modules have been updated to pass their tests or not produce deprecation warnings with the latest version of Catalyst. It is recommended that you upgrade any of these that you are using after installing this version of Catalyst.

These extensions are:

This is now deprecated, see Catalyst::Upgrading.
Has been updated to not produce deprecation warnings, upgrade recommended.
Has been updated to fix failing tests (although older versions still function perfectly with this version of Catalyst).
Has been updated to fix failing tests (although older versions still function perfectly with this version of Catalyst).
Has been updated to fix failing tests (although older versions still function perfectly with this version of Catalyst).

VERSION 5.8XXXX 'catamoose'

Deprecations

Please see Catalyst::Upgrading for a full description of how changes in the framework may affect your application.

Below is a brief list of features which have been deprecated in this release:

::[MVC]:: style naming scheme has been deprecated and will warn
__PACKAGE__->mk_accessors() is supported for backward compatibility only, use Moose attributes instead in new code.

New features

Dispatcher

Restarter

The development server restarter has been improved to be compatible with immutable Moose classes, and also to optionally use B::Hooks::OP::Check::StashChange to handle more complex application layouts correctly.

$c->uri_for_action method.

Give a private path to the Catalyst action you want to create a URI for.

Logging

Log levels have been made additive.

Catalyst::Test

Catalyst::Response

  • New print method which prints @data to the output stream, separated by $,. This lets you pass the response object to functions that want to write to an IO::Handle.
  • Added code method as an alias for "$res->status"

Consequences of the Moose back end

  • Components are fully compatible with Moose, and all Moose features, such as method modifiers, attributes, roles, BUILD and BUILDARGS methods are fully supported and may be used in components and applications.
  • Many reusable extensions which would previously have been plugins or base classes are better implemented as Moose roles.
  • MooseX::MethodAttributes::Role::AttrContainer::Inheritable is used to contain action attributes. This means that attributes are represented in the MOP, and decouples action creation from attributes.
  • There is a reasonable API in Catalyst::Controller for working with and registering actions, allowing a controller sub-class to replace subroutine attributes for action declarations with an alternate syntax.
  • Refactored capturing of $app from Catalyst::Controller into Catalyst::Component::ApplicationAttribute for easier reuse in other components.
  • Your application class is forced to become immutable at the end of compilation.

Bug fixes

  • Don't ignore SIGCHLD while handling requests with the development server, so that system() and other ways of creating child processes work as expected.
  • Fixes for FastCGI when used with IIS 6.0
  • Fix a bug in uri_for which could cause it to generate paths with multiple slashes in them.
  • Fix a bug in Catalyst::Stats, stopping garbage being inserted into the stats if a user calls begin => but no end