Merge branch 'master' into gsoc_breadboard
[catagits/Catalyst-Runtime.git] / TODO
diff --git a/TODO b/TODO
index 9979345..5e3c68e 100644 (file)
--- a/TODO
+++ b/TODO
@@ -24,14 +24,17 @@ subclass of Catalyst::Log, no ::Plugin:: needed.
 See also: Catalyst::Plugin::Log::Dispatch and
 http://github.com/willert/catalyst-plugin-log4perl-simple/tree
 
-# REFACTORING
+## throw away the restarter and allow using the restarters Plack provides
 
-##  The horrible hack for plugin setup - replacing it:
+## be smarter about how we use PSGI - not every response needs to be delayed
+    and streaming
+
+#  The horrible hack for plugin setup - replacing it:
 
  * Have a look at the Devel::REPL BEFORE_PLUGIN stuff
    I wonder if what we need is that combined with plugins-as-roles
 
-## App / ctx split:
+# App / ctx split:
 
   NOTE - these are notes that t0m thought up after doing back compat for
          catalyst_component_class, may be inaccurate, wrong or missing things
@@ -57,40 +60,118 @@ http://github.com/willert/catalyst-plugin-log4perl-simple/tree
 
 ## GSOC
 
-### Next steps - planned:
-
-  - Test custom container
-    - writing some tests which verify that the models you think should be
-      there are there, and that they received their dependencies as arguments
-    - i.e. Model::Bar should get params { foo => $model_foo } when being
-      constructed, etc
-    - Need to test that if you have a standard component Frotz
-      and a customized component Fnar, and Fnar depends on Frotz
-    - And yeah, some tests that the customised components actually work via
-      $c->model('Foo'), and that COMPONENT is called (or not called)
-      as appropiate and that ACCEPT_CONTEXT is called (or not) as appropriate
-
-  - Kill flush_request_services
-    - we're already passing $ctx in when we locate services so the ::Request
-      lifecycle can just stash the object in, or retrieve the object from the
-      stash
-
-### Next steps - less planned:
-
-  - Creating service()-like sugar for component
-
-  - Test cases for extending the container in an application.
-    - Using the sugar added in the previous item
-    - Test when Model::Foo depends_on Model::Bar
-    - Test for component Foo => ( lifecycle => 'Singleton', class => 'My::External::Class', dependencies => { config => depends_on("config") } )
-    - Fix ^^ so that you can get your component's namespaced config nicely.
-
-  - Tests for using the container outside of Catalyst
-    - Custom container which adds some (very simple) services which are initialized from
-      the application config file (note plain services, not components)
-    - Depend on (and test) these inside Catalyst
-    - Test loading container outside Catalyst, and these services working
-    - Test Catalyst / MyApp is not loaded
+### Final steps for GSOC
+
+##### Things that work:
+
+    - the default container loads all components, calls ACCEPT_CONTEXT() when appropriate, and COMPONENT() when appropriate, behaving like current Catalyst does
+
+    - its possible to create a custom container, and override the components you want. Lifecycle, class, dependencies, all overridable.
+
+    - config files are loaded without Catalyst::Plugin::ConfigLoader
+
+    - per request life cycle somewhat works
+
+    - external modules are loaded just using a custom container, much like Catalyst::Model::Adaptor
+
+##### Things that don't work:
+
+    - expand_component_module
+
+    - Some back compat
+        - wrappers around setup_component, setup_components in Catalyst.pm
+        - $instance->expand_modules
+        - search_extra
+        - Crazy tests for things such as:
+           sub COMPONENT {
+             ...
+             *${appclass}::Model::TopLevel::GENERATED::ACCEPT_CONTEXT = sub { ... };
+             ...
+           }
+
+##### Items for discussion and planning
+# (in no particular order, just numbered to be more easily refered to)
+
+  1) per request life cycle
+
+  2) sugar syntax
+
+  3) when / when not COMPONENT should be called
+
+  4) problems when get_all_components() is called when there is no 'context' yet
+
+  5) Back compat problems:
+     - expand_component_module
+     - $instance->expand_modules
+     - search_extra
+     - what to do when a user overrides the locate_components method?
+
+  6) locate_components service vs setup_components method
+     - can we be more lazy?
+     - should setup_components be a service that things like the ->component lookup
+       can depend on?
+
+  7) $class->log->warn is being used to give warnings, but maybe there is a
+     better way to do it
+
+  8) the ConstructorInjection depends on the application_name, which probably
+     makes app/ctx split harder. We need a way to get the application instance
+     passed properly.
+
+  9) there is a call in Catalyst::Controller to catalyst_component_name class
+     accessor (which doesn't exist anymore).
+
+ 10) make ACCEPT_CONTEXT and COMPONENT optional in Catalyst::IOC::BlockInjection and Catalyst::IOC::ConstructorInjection
+     - Create COMPONENTSingleton life cycle
+
+ 11) we build the service too early, causing the COMPONENT method to be
+     called early, breaking components which build other components (e.g.
+     Model::DBIC::Schema).
+
+ 12) root service has a very ambiguous name - maybe root_dir?
+
+ 13) should _get_component_type_name (in Catalyst::IOC::Container) exist?
+
+ 14) Test cases for extending the container in an application.
+     - Using the sugar added in the previous item
+     - Test when Model::Foo depends_on Model::Bar
+     - Test for component Foo => ( lifecycle => 'Singleton', class => 'My::External::Class', dependencies => { config => depends_on("config") } )
+     - Fix ^^ so that you can get your component's namespaced config nicely.
+
+ 15) Tests for using the container outside of Catalyst
+     - Custom container which adds some (very simple) services which are initialized from
+       the application config file (note plain services, not components)
+     - Depend on (and test) these inside Catalyst
+     - Test loading container outside Catalyst, and these services working
+     - Test Catalyst / MyApp is not loaded
+
+    16) _build_(request|response)_constructor_args need replicating in
+        this branch.
+
+### Next steps
+
+  - Push the config built in the container back up onto the app
+
+  - Find a better way to make path_to work. Current fix is in
+    Catalyst::IOC::Container, subs build_home_service, build_root_service.
+
+  - Improve validation on the 'component' methods in  Catalyst::IOC
+    (check the type of the component, etc)
+
+  - Thigs to test:
+    - Imports getting the importing package in Catalyst::IOC
+    - Back compat for Catalyst.pm moved methods (locate_components)
+    - Custom container
+      - writing some tests which verify that the models you think should be
+        there are there, and that they received their dependencies as arguments
+      - i.e. Model::Bar should get params { foo => $model_foo } when being
+        constructed, etc
+      - Need to test that if you have a standard component Frotz
+        and a customized component Fnar, and Fnar depends on Frotz
+      - And yeah, some tests that the customised components actually work via
+        $c->model('Foo'), and that COMPONENT is called (or not called)
+        as appropiate and that ACCEPT_CONTEXT is called (or not) as appropriate
+
 
 #### Extending my app, notes
 
@@ -101,7 +182,7 @@ and what needs to be done to fix it!
 
 package MyApp::Container;
 use Catalyst::IOC;
-    
+
     container $self, as {
             container model => as {
                 component Foo => (); # As per default!
@@ -109,11 +190,11 @@ use Catalyst::IOC;
                 component Baz => ( lifecycle => 'InstancePerContext );
                 component Quux => ( lifecycle => 'Singleton' ); # ACCEPT_CONTEXT not called
                 # Catalyst::Model::Adaptor example
-                conponent Fnar => ( lifecycle => 'Singleton', class => 'My::External::Class', dependencies => { config => depends_on('config')} );
+                component Fnar => ( lifecycle => 'Singleton', class => 'My::External::Class', dependencies => { config => depends_on('config')} );
                 #                                                                                               ^^ FIXME - gets whole config, not Model::Foo
                 #                                                                                                  There should be a 'nice' way to get the 'standard' config
-            };                    
-            # Note - implementation of BB may need to be changed to support making sure existing 
+            };
+            # Note - implementation of BB may need to be changed to support making sure existing
             # services actually get overridden. not sure how the default container behaves when doing that
             # above code would build the constructor injection as it currently does,
             # defaulting to the class name in the right namespace as declared by the surrounding container
@@ -121,50 +202,3 @@ use Catalyst::IOC;
     };
 
 1;
-
-##### To start with
-
-package MyApp::Container;
-use Moose;
-
-extends 'Catalyst::Container;
-
-after BUILD => sub {
-    my $self = shift;
-    my $model_container = $self->get_sub_container('model');
-    my $service = Catalyst::IOC::ConstructorInjection->new(
-        name      => 'Baz',
-        class     => 'MyApp::Model::Baz',
-        dependencies => [
-            depends_on( '/application_name' ),
-            depends_on( '/config' ),
-            depends_on( '/model/Foo' ),
-        ],
-        lifecycle => 'InstancePerContext',
-    );
-    $model_container->add_service( 'Foo', $service );
-};
-
-### To polish off / t0m review
-
-    locate_components service vs setup_components method
-      - can we be more lazy?
-      - should setup_components be a service that things like the ->component lookup
-        can depend on?
-
-    -    my $accept_context_args = $self->param('accept_context_args');
-    +    my $accept_context_args = $params{accept_context_args};
-    ^^ This (may be) wrong! I am thinking the service should be allowed to mangle the 
-       accept_context args, no?
-       Without this change, the user could make a custom service which mangled the param, and use 
-       Catalyst/IOC/Service/WithAcceptContext.pm, with this change, that module will always see the
-       un-mangled version?? However, without this change, shit doesn't work...
-
-### Known issues
-
-    - Broken $instance->expand_modules() in setup_components and figure
-      out later how to bring it back
-
-    - expand_component_module
-
-    - People wrapping locate_components in Catalyst.pm