X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=TODO;h=aa8e0b6236f2379161ad39d5aa98806680a18d3f;hb=47500a27183d93021ff85c6c29a6f6c6f2dd2cdb;hp=9979345c6c44665f089ef877ebccf1fbe3be30df;hpb=4cb569168526c501fb3db8c0d75d3132fa8db42b;p=catagits%2FCatalyst-Runtime.git

diff --git a/TODO b/TODO
index 9979345..aa8e0b6 100644
--- a/TODO
+++ b/TODO
@@ -57,8 +57,64 @@ http://github.com/willert/catalyst-plugin-log4perl-simple/tree
 
 ## GSOC
 
+### 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
+
+    - loading two containers simultaneously
+
+    - sugar is still not completely implemented
+
+    - Some back compat
+        - wrappers around setup_component, setup_components, locate_components in Catalyst.pm
+        - $instance->expand_modules
+        - search_extra
+        - Crazy tests for things such as:
+           sub COMPONENT {
+             ...
+             *${appclass}::Model::TopLevel::GENERATED::ACCEPT_CONTEXT = sub { ... };
+             ...
+           }
+
+##### Need planning, have questions:
+
+    - per request life cycle
+
+    - sugar - we should discuss the syntax with rafl and edenc
+
+    - when / when not COMPONENT should be called
+
+    - 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?
+
+    - There are a few more FIXMEs, idk if any relevant here
+
 ### Next steps - planned:
 
+  - some imports need to get the importing package in Catalyst::IOC
+
+  - test values directly instead of serializing them over http in t/lib/TestCustomContainer.pm
+
+  - 16:01 < shadowpaste> "t0m" at 217.168.150.38 pasted "more explicit? thoughts?" (13 lines) at http://paste.scsys.co.uk/131520
+
+  - Back compat for Catalyst.pm moved methods (locate_components)
+
   - 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
@@ -70,13 +126,11 @@ http://github.com/willert/catalyst-plugin-log4perl-simple/tree
       $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:
 
+  - make ACCEPT_CONTEXT and COMPONENT optional in Catalyst::IOC::BlockInjection and Catalyst::IOC::ConstructorInjection
+    - Create COMPONENTSingleton life cycle
+
   - Creating service()-like sugar for component
 
   - Test cases for extending the container in an application.
@@ -121,50 +175,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