- Test cases for extending the container in an application.
- Using the sugar added in the previous item
- Test when Model::Foo depends_on Model::Bar
+ - Test for component Foo => ( lifecycle => 'Singleton', class => 'My::External::Class', dependencies => { config => depends_on("config") } )
+ - Fix ^^ so that you can get your component's namespaced config nicely.
- Tests for using the container outside of Catalyst
- Custom container which adds some (very simple) services which are initialized from
package MyApp::Container;
use Catalyst::IOC;
- container $self, as {
+ container $self, as {
container model => as {
component Foo => (); # As per default!
component Bar => (dependencies => ['/model/Foo']); # Magic!
component Baz => ( lifecycle => 'InstancePerContext );
component Quux => ( lifecycle => 'Singleton' ); # ACCEPT_CONTEXT not called
+ # Catalyst::Model::Adaptor example
+ conponent Fnar => ( lifecycle => 'Singleton', class => 'My::External::Class', dependencies => { config => depends_on('config')} );
+ # ^^ FIXME - gets whole config, not Model::Foo
+ # There should be a 'nice' way to get the 'standard' config
};
# Note - implementation of BB may need to be changed to support making sure existing
# services actually get overridden. not sure how the default container behaves when doing that
### To polish off / t0m review
+ locate_components service vs setup_components method
+ - can we be more lazy?
+ - should setup_components be a service that things like the ->component lookup
+ can depend on?
+
- my $accept_context_args = $self->param('accept_context_args');
+ my $accept_context_args = $params{accept_context_args};
^^ This (may be) wrong! I am thinking the service should be allowed to mangle the