See also: Catalyst::Plugin::Log::Dispatch and
http://github.com/willert/catalyst-plugin-log4perl-simple/tree
-# REFACTORING
-
-## 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
+## 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)
-Looks to me like we are mapping --deamon to --detach but I think the modern Plack FCGI handler prefers --deamonize
+## throw away the restarter and allow using the restarters Plack provides
-Although --pidfile is supported --pid seems to be preferred, and if we are bothering to map, why not map for the future?
+## remove per-request state from the engine instance
-##### myapp_web_server.pl
+## be smarter about how we use PSGI - not every response needs to be delayed
+ and streaming
---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?)
+# The horrible hack for plugin setup - replacing it:
---keepalive, passed, no complaint but doesn’t really seem to do anything.
+ * Have a look at the Devel::REPL BEFORE_PLUGIN stuff
+ I wonder if what we need is that combined with plugins-as-roles
---pidfile, --background, these also seem to do nothing.
+# PSGI
-### Nice to have
+## To do at release time
- * <@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
- and streaming
+ - Release psgi branch of Catalyst-Devel
+ - Release new Task::Catalyst
+ - Release 5.9 branch of Catalyst-Manual
+ - Release Catalyst::Engine::HTTP::Prefork with deprecation notice
+ + exit in Makefile.PL if Catalyst > 5.89 is installed.
-## The horrible hack for plugin setup - replacing it:
+## Blockers
- * Have a look at the Devel::REPL BEFORE_PLUGIN stuff
- I wonder if what we need is that combined with plugins-as-roles
+ * I've noticed a small difference with Catalyst::Test. The latest stable
+ version include two headers, 'host' and 'https'. They are missing from
+ this version - Pedro Melo on list
+ ^^ Cannot replicate this? Mailed back to ask for tests..
-## 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
+
+ - 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
+ - done - needs testing
+
+ - Back compat for Catalyst.pm moved methods (locate_components)
+ - done - needs testing
+
+ - 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
+
+### Next steps - less planned:
+
+ - make ACCEPT_CONTEXT and COMPONENT optional in Catalyst::IOC::BlockInjection and Catalyst::IOC::ConstructorInjection
+ - Create COMPONENTSingleton life cycle
+
+ - 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
+
+#### 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
+ conponent 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