Commit | Line | Data |
77d892df |
1 | # Known Bugs: |
cdb34619 |
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 | |
77d892df |
8 | # Compatibility warnings to add: |
9 | |
10 | - $self->config should warn as config should only ever be called as a |
5d94e8f9 |
11 | class method (TESTS). |
77d892df |
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 |
5d94e8f9 |
37 | catalyst_component_class, may be inaccurate, wrong or missing things |
77d892df |
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) |
19c64905 |
57 | |
58 | ## GSOC |
59 | |
4af15971 |
60 | ### Final steps for GSOC |
61 | |
62 | ##### Things that work: |
63 | |
878cfbf2 |
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 | |
4af15971 |
74 | ##### Things that don't work: |
75 | |
878cfbf2 |
76 | - expand_component_module |
77 | |
878cfbf2 |
78 | - sugar is still not completely implemented |
79 | |
80 | - Some back compat |
81 | - wrappers around setup_component, setup_components, locate_components in Catalyst.pm |
82 | - $instance->expand_modules |
83 | - search_extra |
84 | - Crazy tests for things such as: |
85 | sub COMPONENT { |
86 | ... |
87 | *${appclass}::Model::TopLevel::GENERATED::ACCEPT_CONTEXT = sub { ... }; |
88 | ... |
89 | } |
90 | |
4af15971 |
91 | ##### Need planning, have questions: |
92 | |
878cfbf2 |
93 | - per request life cycle |
94 | |
95 | - sugar - we should discuss the syntax with rafl and edenc |
96 | |
97 | - when / when not COMPONENT should be called |
98 | |
99 | - locate_components service vs setup_components method |
100 | - can we be more lazy? |
101 | - should setup_components be a service that things like the ->component lookup |
102 | can depend on? |
103 | |
104 | - There are a few more FIXMEs, idk if any relevant here |
105 | |
4cb56916 |
106 | ### Next steps - planned: |
107 | |
4af15971 |
108 | - some imports need to get the importing package in Catalyst::IOC |
9527a3af |
109 | - done - needs testing |
4af15971 |
110 | |
4af15971 |
111 | - Back compat for Catalyst.pm moved methods (locate_components) |
9527a3af |
112 | - done - needs testing |
4af15971 |
113 | |
4cb56916 |
114 | - Test custom container |
115 | - writing some tests which verify that the models you think should be |
116 | there are there, and that they received their dependencies as arguments |
117 | - i.e. Model::Bar should get params { foo => $model_foo } when being |
118 | constructed, etc |
119 | - Need to test that if you have a standard component Frotz |
120 | and a customized component Fnar, and Fnar depends on Frotz |
121 | - And yeah, some tests that the customised components actually work via |
122 | $c->model('Foo'), and that COMPONENT is called (or not called) |
123 | as appropiate and that ACCEPT_CONTEXT is called (or not) as appropriate |
124 | |
a43734f6 |
125 | ### Next steps - less planned: |
731a4757 |
126 | |
47500a27 |
127 | - make ACCEPT_CONTEXT and COMPONENT optional in Catalyst::IOC::BlockInjection and Catalyst::IOC::ConstructorInjection |
128 | - Create COMPONENTSingleton life cycle |
129 | |
334eb9fb |
130 | - Creating service()-like sugar for component |
131 | |
731a4757 |
132 | - Test cases for extending the container in an application. |
334eb9fb |
133 | - Using the sugar added in the previous item |
134 | - Test when Model::Foo depends_on Model::Bar |
2bf1bef6 |
135 | - Test for component Foo => ( lifecycle => 'Singleton', class => 'My::External::Class', dependencies => { config => depends_on("config") } ) |
136 | - Fix ^^ so that you can get your component's namespaced config nicely. |
731a4757 |
137 | |
88e5cd24 |
138 | - Tests for using the container outside of Catalyst |
139 | - Custom container which adds some (very simple) services which are initialized from |
140 | the application config file (note plain services, not components) |
141 | - Depend on (and test) these inside Catalyst |
142 | - Test loading container outside Catalyst, and these services working |
143 | - Test Catalyst / MyApp is not loaded |
4634d3ad |
144 | |
f5dbaa05 |
145 | #### Extending my app, notes |
146 | |
147 | Basically try to implement something like this (starting out without the sugar!), and see how it breaks |
148 | and what needs to be done to fix it! |
149 | |
150 | ##### Eventual syntax |
151 | |
152 | package MyApp::Container; |
153 | use Catalyst::IOC; |
154 | |
2bf1bef6 |
155 | container $self, as { |
f5dbaa05 |
156 | container model => as { |
157 | component Foo => (); # As per default! |
158 | component Bar => (dependencies => ['/model/Foo']); # Magic! |
159 | component Baz => ( lifecycle => 'InstancePerContext ); |
160 | component Quux => ( lifecycle => 'Singleton' ); # ACCEPT_CONTEXT not called |
2bf1bef6 |
161 | # Catalyst::Model::Adaptor example |
162 | conponent Fnar => ( lifecycle => 'Singleton', class => 'My::External::Class', dependencies => { config => depends_on('config')} ); |
163 | # ^^ FIXME - gets whole config, not Model::Foo |
164 | # There should be a 'nice' way to get the 'standard' config |
f5dbaa05 |
165 | }; |
166 | # Note - implementation of BB may need to be changed to support making sure existing |
167 | # services actually get overridden. not sure how the default container behaves when doing that |
168 | # above code would build the constructor injection as it currently does, |
169 | # defaulting to the class name in the right namespace as declared by the surrounding container |
170 | # as well as adding using the catalyst-specific service class |
171 | }; |
172 | |
173 | 1; |