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 ### 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:
  83
  84   - Creating service()-like sugar for component
  85
  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
  89
  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         };
 107
 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
 128
 129   only a couple of new lifecycles to be registered with the container - ??
 130
 131
 132 ### To polish off / t0m review
 133
 134   - +    $class->container->get_sub_container('model')->make_single_default;
 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?
 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