X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?p=catagits%2FCatalyst-Runtime.git;a=blobdiff_plain;f=lib%2FCatalyst%2FUpgrading.pod;h=0d1a60b521db8272022af123bc77643cb1365683;hp=5a5a85706b3f4db5b9628e5d8449a0574705bb46;hb=044e7667c0cb0cd8dac8b33df1d503abdab0d70c;hpb=ec4d72594fb7a701c2f36e85ecf9a680ca1abba2

diff --git a/lib/Catalyst/Upgrading.pod b/lib/Catalyst/Upgrading.pod
index 5a5a857..0d1a60b 100644
--- a/lib/Catalyst/Upgrading.pod
+++ b/lib/Catalyst/Upgrading.pod
@@ -21,6 +21,75 @@ Into
 and we expect everything to work the same (we'd consider it not working the same
 to be a bug, and please report it.)
 
+We also cored features from L<CatalystX::RoleApplicator> to compose a role into the
+request, response and stats classes.  The main difference is that with L<CatalystX::RoleApplicator>
+you did:
+
+    package MyApp;
+
+    use Catalyst;
+    use CatalystX::RoleApplicator;
+
+    __PACKAGE__->apply_request_class_roles(
+      qw/My::Request::Role Other::Request::Role/);
+
+Whereas now we have three class attributes, 'request_class_traits', 'response_class_traits'
+and 'stats_class_traits', so you use like this (note this value is an ArrayRef)
+
+
+    package MyApp;
+
+    use Catalyst;
+
+    __PACKAGE__->request_class_traits([qw/
+      My::Request::Role
+      Other::Request::Role/]);
+
+(And the same for response_class_traits and stats_class_traits.  We left off the
+traits for Engine, since that class does a lot less nowadays, and dispatcher.  If you
+used those and can share a use case, we'd be likely to support them.
+
+Lastly, we have some of the feature from L<CatalystX::ComponentsFromConfig> in
+core.  This should mostly work the same way in core, except for now the
+core version does not create an automatic base wrapper class for your configured
+components (it requires these to be catalyst components and injects them directly.
+So if you make heavy use of custom base classes in L<CatalystX::ComponentsFromConfig>
+you might need a bit of work to use the core version (although there is no reason
+to stop using L<CatalystX::ComponentsFromConfig> since it should continue to work
+fine and we'd consider issues with it to be bugs).  Here's one way to map from
+L<CatalystX::ComponentsFromConfig> to core:
+
+In L<CatalystX::ComponentsFromConfig>:
+
+    MyApp->config(
+      'Model::MyClass' => {
+          class => 'MyClass',
+          args => { %args },
+
+      });
+
+and now in core:
+
+    MyApp->config(
+      inject_components => {
+        'Model::MyClass' => { from_component => 'My::Class' },
+      },
+      'Model::MyClass' => {
+        %args
+      },
+    );
+
+Although the cored behavior requires more code, its better separates concerns
+as well as plays more into core Catalyst expections of how configuration shoul
+look.
+
+Also we added a new develop console mode only warning when you call a component
+with arguments that don't expect or do anything meaningful with those args.  Its
+possible if you are logging debug mode in production (please don't...) this 
+could add verbosity to those logs if you also happen to be calling for components
+and passing pointless arguments.  We added this warning to help people not make this
+error and to better understand the component resolution flow.
+
 =head1 Upgrading to Catalyst 5.90085
 
 In this version of Catalyst we made a small change to Chained Dispatching so