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     - 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
  91 ##### Need planning, have questions:
  92
  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
 106 ### Next steps - planned:
 107
 108   - some imports need to get the importing package in Catalyst::IOC
 109     - done - needs testing
 110
 111   - Back compat for Catalyst.pm moved methods (locate_components)
 112     - done - needs testing
 113
 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
 125 ### Next steps - less planned:
 126
 127   - make ACCEPT_CONTEXT and COMPONENT optional in Catalyst::IOC::BlockInjection and Catalyst::IOC::ConstructorInjection
 128     - Create COMPONENTSingleton life cycle
 129
 130   - Creating service()-like sugar for component
 131
 132   - Test cases for extending the container in an application.
 133     - Using the sugar added in the previous item
 134     - Test when Model::Foo depends_on Model::Bar
 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.
 137
 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
 144
 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
 155     container $self, as {
 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
 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
 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;