what works | what doesn't work | what needs planning
[catagits/Catalyst-Runtime.git] / TODO
1 # Known Bugs:
2
3    - Bug ->go or ->visit causes actions which have Args or CaptureArgs called
4      twice when called via ->go or ->visit.
5
6      Test app: http://github.com/bobtfish/catalyst-app-bug-go_chain/tree/master
7
8 # Compatibility warnings to add:
9
10   - $self->config should warn as config should only ever be called as a
11     class method (TESTS).
12
13 # Proposed functionality / feature additions:
14
15 ## Log setup needs to be less lame
16
17 So Catalyst::Plugin::Log::* can die
18 in a fire. Having $c->log_class would be a good start. kane volunteered
19 to do some of this.
20
21 Simple example: Catalyst::Plugin::Log::Colorful should just be a
22 subclass of Catalyst::Log, no ::Plugin:: needed.
23
24 See also: Catalyst::Plugin::Log::Dispatch and
25 http://github.com/willert/catalyst-plugin-log4perl-simple/tree
26
27 # REFACTORING
28
29 ##  The horrible hack for plugin setup - replacing it:
30
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
33
34 ## App / ctx split:
35
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 :)
40
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)
57
58 ## GSOC
59
60 ### Final steps for GSOC
61
62 ##### Things that work:
63
64     - the default container loads all components, calls ACCEPT_CONTEXT() when appropriate, and COMPONENT() when appropriate, behaving like current Catalyst does
65
66     - its possible to create a custom container, and override the components you want. Lifecycle, class, dependencies, all overridable.
67
68     - config files are loaded without Catalyst::Plugin::ConfigLoader
69
70     - per request life cycle somewhat works
71
72     - external modules are loaded just using a custom container, much like Catalyst::Model::Adaptor
73
74 ##### Things that don't work:
75
76     - expand_component_module
77
78     - loading two containers simultaneously
79
80     - sugar is still not completely implemented
81
82     - Some back compat
83         - wrappers around setup_component, setup_components, locate_components in Catalyst.pm
84         - $instance->expand_modules
85         - search_extra
86         - Crazy tests for things such as:
87            sub COMPONENT {
88              ...
89              *${appclass}::Model::TopLevel::GENERATED::ACCEPT_CONTEXT = sub { ... };
90              ...
91            }
92
93 ##### Need planning, have questions:
94
95     - per request life cycle
96
97     - sugar - we should discuss the syntax with rafl and edenc
98
99     - when / when not COMPONENT should be called
100
101     - locate_components service vs setup_components method
102       - can we be more lazy?
103       - should setup_components be a service that things like the ->component lookup
104         can depend on?
105
106     - There are a few more FIXMEs, idk if any relevant here
107
108 ### Next steps - planned:
109
110   - some imports need to get the importing package in Catalyst::IOC
111
112   - test values directly instead of serializing them over http in t/lib/TestCustomContainer.pm
113
114   - 16:01 < shadowpaste> "t0m" at 217.168.150.38 pasted "more explicit? thoughts?" (13 lines) at http://paste.scsys.co.uk/131520
115
116   - make ACCEPT_CONTEXT and COMPONENT optional in Catalyst::IOC::BlockInjection and Catalyst::IOC::ConstructorInjection
117     - Create COMPONENTSingleton life cycle
118
119   - Back compat for Catalyst.pm moved methods (locate_components)
120
121   - Test custom container
122     - writing some tests which verify that the models you think should be
123       there are there, and that they received their dependencies as arguments
124     - i.e. Model::Bar should get params { foo => $model_foo } when being
125       constructed, etc
126     - Need to test that if you have a standard component Frotz
127       and a customized component Fnar, and Fnar depends on Frotz
128     - And yeah, some tests that the customised components actually work via
129       $c->model('Foo'), and that COMPONENT is called (or not called)
130       as appropiate and that ACCEPT_CONTEXT is called (or not) as appropriate
131
132 ### Next steps - less planned:
133
134   - Creating service()-like sugar for component
135
136   - Test cases for extending the container in an application.
137     - Using the sugar added in the previous item
138     - Test when Model::Foo depends_on Model::Bar
139     - Test for component Foo => ( lifecycle => 'Singleton', class => 'My::External::Class', dependencies => { config => depends_on("config") } )
140     - Fix ^^ so that you can get your component's namespaced config nicely.
141
142   - Tests for using the container outside of Catalyst
143     - Custom container which adds some (very simple) services which are initialized from
144       the application config file (note plain services, not components)
145     - Depend on (and test) these inside Catalyst
146     - Test loading container outside Catalyst, and these services working
147     - Test Catalyst / MyApp is not loaded
148
149 #### Extending my app, notes
150
151 Basically try to implement something like this (starting out without the sugar!), and see how it breaks
152 and what needs to be done to fix it!
153
154 ##### Eventual syntax
155
156 package MyApp::Container;
157 use Catalyst::IOC;
158     
159     container $self, as {
160             container model => as {
161                 component Foo => (); # As per default!
162                 component Bar => (dependencies => ['/model/Foo']); # Magic!
163                 component Baz => ( lifecycle => 'InstancePerContext );
164                 component Quux => ( lifecycle => 'Singleton' ); # ACCEPT_CONTEXT not called
165                 # Catalyst::Model::Adaptor example
166                 conponent Fnar => ( lifecycle => 'Singleton', class => 'My::External::Class', dependencies => { config => depends_on('config')} );
167                 #                                                                                               ^^ FIXME - gets whole config, not Model::Foo
168                 #                                                                                                  There should be a 'nice' way to get the 'standard' config
169             };                    
170             # Note - implementation of BB may need to be changed to support making sure existing 
171             # services actually get overridden. not sure how the default container behaves when doing that
172             # above code would build the constructor injection as it currently does,
173             # defaulting to the class name in the right namespace as declared by the surrounding container
174             # as well as adding using the catalyst-specific service class
175     };
176
177 1;