3 - Bug ->go or ->visit causes actions which have Args or CaptureArgs called
4 twice when called via ->go or ->visit.
6 Test app: http://github.com/bobtfish/catalyst-app-bug-go_chain/tree/master
8 # Compatibility warnings to add:
10 - $self->config should warn as config should only ever be called as a
13 # Proposed functionality / feature additions:
15 ## Log setup needs to be less lame
17 So Catalyst::Plugin::Log::* can die
18 in a fire. Having $c->log_class would be a good start. kane volunteered
21 Simple example: Catalyst::Plugin::Log::Colorful should just be a
22 subclass of Catalyst::Log, no ::Plugin:: needed.
24 See also: Catalyst::Plugin::Log::Dispatch and
25 http://github.com/willert/catalyst-plugin-log4perl-simple/tree
29 ## The horrible hack for plugin setup - replacing it:
31 * Have a look at the Devel::REPL BEFORE_PLUGIN stuff
32 I wonder if what we need is that combined with plugins-as-roles
36 NOTE - these are notes that t0m thought up after doing back compat for
37 catalyst_component_class, may be inaccurate, wrong or missing things
38 bug mst (at least) to correct before trying more than the first 2
39 steps. Please knock yourself out on the first two however :)
41 - Eliminate actions in MyApp from the main test suite
42 - Uncomment warning in C::C::register_action_methods, add tests it works
43 by mocking out the logging..
44 - Remove MyApp @ISA controller (ask metaclass if it has attributes, and if
45 so you need back compat :/)
46 - Make Catalyst::Context, move the per request stuff in there, handles from
47 main app class to delegate
48 - Make an instance of the app class which is a global variable
49 - Make new instance of the context class, not the app class per-request
50 - Remove the components as class data, move to instance data on the app
51 class (you probably have to do this for _all_ the class data, good luck!)
52 - Make it possible for users to spin up different instances of the app class
53 (with different config etc each)
54 - Profit! (Things like changing the complete app config per vhost, i.e.
55 writing a config loader / app class role which dispatches per vhost to
56 differently configured apps is piss easy)
60 ### Next large steps, planned:
62 For all components that have been discovered, in whatever way, we create a service:
63 - that's a catalyst component service
64 - which is basically just a constructor injection
65 - except the constructor name is COMPONENT
66 - and we're "implicitly" passing along some constructor args
67 - Lifecycle => Singleton
69 - Fix B::B so that Service::WithParametrs' parameters attribute has a builder
70 - Fix ConstructorInjection so that default parameters are supplied (for accept_context_args)
71 - Fix ConstructorInjection's 'suffix' - should be called 'config_key' or something, and
72 should be an attribute on the service (as it never changes), rather than a parameter
75 - We make a 'components' sub container in the main container.
76 - This gets the ConstructorInjection COMPONENT services, as model_Foo.
77 - Lifecycle of these services is Singleton
78 - This simplifies the code for MyApp->components, as it need only list one sub-container
80 - We create a second service (depending on the first one) for ACCEPT_CONTEXT
81 - This has a custom service which calls ACCEPT_CONTEXT when the instance is fetched
82 - Not Singleton lifecycle
84 Note - ACCEPT_CONTEXT can be called on app values - if you have a Model::Foo, with an ACCEPT_CONTEXT
85 and you call MyApp->model('Foo') then ACCEPT_CONTEXT gets invoked with a $c of 'MyApp' (this is not\
86 the normal case, but we need to preserve for compat)
88 ### Next steps - less planned:
90 - Creating service()-like sugar for component
92 - Test cases for extending the container in an application.
93 - Using the sugar added in the previous item
94 - Test when Model::Foo depends_on Model::Bar
97 #### Extending my app, notes
99 Basically try to implement something like this (starting out without the sugar!), and see how it breaks
100 and what needs to be done to fix it!
102 ##### Eventual syntax
104 package MyApp::Container;
107 container $self, as {
108 container model => as {
109 component Foo => (); # As per default!
110 component Bar => (dependencies => ['/model/Foo']); # Magic!
111 component Baz => ( lifecycle => 'InstancePerContext );
112 component Quux => ( lifecycle => 'Singleton' ); # ACCEPT_CONTEXT not called
114 # Note - implementation of BB may need to be changed to support making sure existing
115 # services actually get overridden. not sure how the default container behaves when doing that
116 # above code would build the constructor injection as it currently does,
117 # defaulting to the class name in the right namespace as declared by the surrounding container
118 # as well as adding using the catalyst-specific service class
125 package MyApp::Container;
128 extends 'Catalyst::Container;
132 my $model_container = $self->get_sub_container('model');
133 my $service = Catalyst::IOC::ConstructorInjection->new(
135 class => 'MyApp::Model::Baz',
137 depends_on( '/application_name' ),
138 depends_on( '/config' ),
139 depends_on( '/model/Foo' ),
141 lifecycle => 'InstancePerContext',
143 $model_container->add_service( 'Foo', $service );
146 ### To polish off / t0m review
148 - + $class->container->get_sub_container('model')->make_single_default;
149 + $class->container->get_sub_container('view')->make_single_default;
151 get_components_names_types
155 +# FIXME - t0m, how do you feel about this name?
156 +# also, do you think I should draw it here, or just return the data structure?
157 +sub get_components_names_types {
159 +Same as L<build_model_subcontainer>, but for controllers. The difference is
160 +that there is no ACCEPT_CONTEXT for controllers.
163 - my $accept_context_args = $self->param('accept_context_args');
164 + my $accept_context_args = $params{accept_context_args};
165 ^^ This (may be) wrong! I am thinking the service should be allowed to mangle the
166 accept_context args, no?
167 Without this change, the user could make a custom service which mangled the param, and use
168 Catalyst/IOC/Service/WithAcceptContext.pm, with this change, that module will always see the
169 un-mangled version?? However, without this change, shit doesn't work...
171 accept_context_args - where does this come from?
173 + $purity = $purity // 1;
178 - Broken $instance->expand_modules() in setup_components and figure
179 out later how to bring it back
181 - expand_component_module