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 - We make a 'components' sub container in the main container.
70 - This gets the ConstructorInjection COMPONENT services, as model_Foo.
71 - Lifecycle of these services is Singleton
72 - This simplifies the code for MyApp->components, as it need only list one sub-container
74 - We create a second service (depending on the first one) for ACCEPT_CONTEXT
75 - This has a custom service which calls ACCEPT_CONTEXT when the instance is fetched
76 - Not Singleton lifecycle
78 Note - ACCEPT_CONTEXT can be called on app values - if you have a Model::Foo, with an ACCEPT_CONTEXT
79 and you call MyApp->model('Foo') then ACCEPT_CONTEXT gets invoked with a $c of 'MyApp' (this is not\
80 the normal case, but we need to preserve for compat)
82 ### Next steps - less planned:
84 - Creating service()-like sugar for component
86 - Test cases for extending the container in an application.
87 - Using the sugar added in the previous item
88 - Test when Model::Foo depends_on Model::Bar
90 a) configure additional services in that container
91 - super simple container $default_container => as { more services };
92 class MyApp::Container extends Catalyst::Container {
93 use Bread::Board; # Or our own sugar?
94 method BUILD { container $self => as {
95 service model => ...; # some constructor injection to MyApp::Model or something
96 container Model => as {
97 component Foo => (dependencies => ['/model']); # As per default!
98 component Bar => (dependencies => ['/model/Foo']); # Magic!
100 # Note - implementation of BB may need to be changed to support making sure existing
101 # services actually get overridden. not sure how the default container behaves when doing that
102 # above code would build the constructor injection as it currently does,
103 # defaulting to the class name in the right namespace as declared by the surrounding container
104 # as well as adding using the catalyst-specific service class
108 let's consider the usage patterns we actually want to enable by doing the whole B::B thing
109 what happens if i make the "per-app" service for a component life only for the duration of the request?
110 or be instanciated every time i look up the component?
111 (or scoping it per session, or having a block injection, or something)
113 say you override the app service to be per-request
114 now the wrapper for the per-request variant doesn't make sense anymore. does it?
115 because you're only overriding one half of what has been generated automatically
117 ah, so you have basically ended up with getting a request scoped thing to be used to construct a request scoped thing, which is pointless? Would/could you not just override the
118 service which is actually getting looked up instead, and make it not depend on the auto-generated per-app scope service, which will then just never be built?
120 yes, you could. but then you'd have to be aware of the distinction
121 which is what i hoped to be a barely visible backcompat thing
122 but which i'm afraid it won't be if we go for two actual separate services
124 what stops the sugar we give from not just making you specify the lifecycle, and giving you the obvious name / wiring?
125 i.e. everything looks like 'Foo', so you don't have to know COMPONENT/Foo exists
127 my hopes of not needing any sugar at all, i guess
129 only a couple of new lifecycles to be registered with the container - ??
132 ### To polish off / t0m review
134 - + $class->container->get_sub_container('model')->make_single_default;
135 + $class->container->get_sub_container('view')->make_single_default;
137 get_components_names_types
141 +# FIXME - t0m, how do you feel about this name?
142 +# also, do you think I should draw it here, or just return the data structure?
143 +sub get_components_names_types {
145 + MyApp->config->{ 'Plugin::ConfigLoader' }->{ substitutions } = {
147 +# FIXME - just till I understand how it's supposed to be done
148 +# Made this so that COMPONENT is executed once,
149 +# and ACCEPT_CONTEXT every call.
154 +my $applevel_config = TestAppContainer->container->resolve(service => 'config')->{applevel_config};
155 +__PACKAGE__->config(applevel_config => 'foo');
158 accept_context_args - where does this come from?
162 - Broken $instance->expand_modules() in setup_components and figure
163 out later how to bring it back
165 - expand_component_module