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 | |
a43734f6 |
60 | ### Next large steps, planned: |
61 | |
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 |
68 | |
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 |
73 | |
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 |
77 | |
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) |
81 | |
82 | ### Next steps - less planned: |
731a4757 |
83 | |
334eb9fb |
84 | - Creating service()-like sugar for component |
85 | |
731a4757 |
86 | - Test cases for extending the container in an application. |
334eb9fb |
87 | - Using the sugar added in the previous item |
88 | - Test when Model::Foo depends_on Model::Bar |
731a4757 |
89 | |
4634d3ad |
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! |
99 | }; |
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 |
105 | } } |
106 | }; |
4634d3ad |
107 | |
a43734f6 |
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) |
112 | |
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 |
116 | |
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? |
119 | |
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 |
123 | |
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 |
126 | |
127 | my hopes of not needing any sugar at all, i guess |
4634d3ad |
128 | |
a43734f6 |
129 | only a couple of new lifecycles to be registered with the container - ?? |
4634d3ad |
130 | |
19c64905 |
131 | |
a43734f6 |
132 | ### To polish off / t0m review |
19c64905 |
133 | |
19c64905 |
134 | - + $class->container->get_sub_container('model')->make_single_default; |
a43734f6 |
135 | + $class->container->get_sub_container('view')->make_single_default; |
136 | |
137 | get_components_names_types |
138 | |
139 | locate_components |
140 | |
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 { |
144 | |
145 | + MyApp->config->{ 'Plugin::ConfigLoader' }->{ substitutions } = { |
146 | |
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. |
150 | +has instance => ( |
151 | + is => 'rw', |
152 | |
153 | # This is ok?? |
154 | +my $applevel_config = TestAppContainer->container->resolve(service => 'config')->{applevel_config}; |
155 | +__PACKAGE__->config(applevel_config => 'foo'); |
156 | |
157 | |
158 | accept_context_args - where does this come from? |
4634d3ad |
159 | |
160 | ### Known issues |
161 | |
162 | - Broken $instance->expand_modules() in setup_components and figure |
163 | out later how to bring it back |
164 | |
165 | - expand_component_module |
166 | |