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
-## PSGI
-
-### Blockers
-
- * Test all the options work on all of the scripts
- * Fix nginx middlewares so that they are generic, or can somehow
- be used by people with their own .psgi files
- * Fix a sane / nicer way to do custom engines.
-
-#### Script survey
-
-##### myapp_web_fastcgi.pl
-
-Looks to me like we are mapping --deamon to --detach but I think the modern Plack FCGI handler prefers --deamonize
-
-Although --pidfile is supported --pid seems to be preferred, and if we are bothering to map, why not map for the future?
-
-##### myapp_web_server.pl
-
---fork, this gets passed and Plack doesn’t complain, but it doesn’t fork. Maybe we could just detect this switch and complain about it (say you should use plackup and Starman, for example?)
-
---keepalive, passed, no complaint but doesn’t really seem to do anything.
-
---pidfile, --background, these also seem to do nothing.
-
-### Nice to have
-
- * <@rafl> i've been thinking of maybe providing
- MyApp->apply_default_middlewares($psgi_app)
- * Capture arguments that the plack engine component was run with somewhere,
- to more easily support custom args from scripts (e.g. Gitalist's
- --git_dir)
- * throw away the restarter and allow using the restarters Plack provides
- * remove per-request state from the engine instance
- * be smarter about how we use PSGI - not every response needs to be delayed
+## be smarter about how we use PSGI - not every response needs to be delayed
and streaming
-## The horrible hack for plugin setup - replacing it:
+# 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
- Profit! (Things like changing the complete app config per vhost, i.e.
writing a config loader / app class role which dispatches per vhost to
differently configured apps is piss easy)
+
+## 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
+
+ - 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
+
+Basically try to implement something like this (starting out without the sugar!), and see how it breaks
+and what needs to be done to fix it!
+
+##### Eventual syntax
+
+package MyApp::Container;
+use Catalyst::IOC;
+
+ container $self, as {
+ container model => as {
+ component Foo => (); # As per default!
+ component Bar => (dependencies => ['/model/Foo']); # Magic!
+ component Baz => ( lifecycle => 'InstancePerContext );
+ component Quux => ( lifecycle => 'Singleton' ); # ACCEPT_CONTEXT not called
+ # Catalyst::Model::Adaptor example
+ 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
+ # 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
+ # as well as adding using the catalyst-specific service class
+ };
+
+1;
projects / catagits/Catalyst-Runtime.git / blobdiff