Name Justin Hunter
Email justin.d.hunter@gmail.com
GoogleID jdh
Project title Rework component setup code to be based on Bread::Board and allow for more customization

Abstract
I will remove the current component loading and instance initialization code within Catalyst and replace it with the Bread::Board inversion of control (IOC) framework. Currently, the Catalyst component loader is inflexible, as it is based around a hard coded set of Model, View and Controller namespaces. Component instances are loaded from fixed namespaces, and initialized with configuration which directly corresponds to those namespaces. A fixed set of accessors are provided on the application context object for service location within the application.

This mandates that application configuration (which should be able to be performed by system adminstrators, for instance), is inherently mingled with static data about application specific component customization. In addition, it implies that for each component in the application, a skeleton class be generated, whose entire purpose is to subclass a publicly available component, and receive application startup time configuration.

Applications with many similar components require repeated individual configurations to be fully specified, and framework extensions which want to take advantage of configuration to load delegate objects; for example, the Catalyst::Plugin::Authentication framework, which loads one or more 'Catalyst::Authentication::Realm' objects, which in turn each load a 'Catalyst::Authentication::Store' and 'Catalyst::Authentication::Credential' object - are forced to re-implement the loading of their sub-components, and ensure the appropriate configuration is passed to them. This is entirely functionality that should be common for all framework extensions.

Updating the framework to provide 'full' inversion of control, using the Bread::Board framework would entirely sove these problems, and also provide the significant benefit of decoupling Catalyst from it's components. As a specific example of the utility of this, it would allow parts of an application (for example the database and authentication model), to be seamlessly reused by code which exists outside of a web application context (for example a batch script run from a crontab).

Currently - to write such a script and reuse an application model; people who favour a 'pure' approach tend to re-implement the subset of component and configuration loading and initialization that they require outside of a web application context, where as other people load the entire Catalyst application, and mock a web request to the application. Both of these approaches have severe disadvantages, either in terms of code-reuse, or application architecture.

Benefits to the Perl/Open Source Community

Using Bread::Board to 'wire-in' Catalyst components will allow easier reuse and configuration of Catalyst components.

Relieve some of the config headache associated with Catalyst

authentication:
     realms:
         LDAP:
             store:
                 ldap_server: ldap.foo.bar

would just become

ldap_server: ldap.foo.bar

Allow simple creation of Model/View/Controller without [Model/View/Controller]/Foo.pm (instead of CatalystX::DynamicComponent::ModelsFromConfig)

model Foo => DBIC_Schema => { schema_class => 'My::Schema::Foo' };

and not need a Model/Foo.pm at all

Allow for easier component dependency specification

Deliverables

• Removal of custom component loading and initialization mechanism and replacement with Bread::Board
• Rewrite/refactor of current Catalyst::Plugin::ConfigLoader/component loading to become a core component of Catalyst.
• Test applications merging from the two projects, and expanding.
• Extension API for framework extensions
• Test application mocking out a use of the extension API by 3rd party components extending the framework (e.g. Catalyst::Plugin::Authentication)
• Documentation to detail how to use the framework extension API

Project Details
Currently, the Catalyst component/config loading require a sometimes complex and clumsy setup. It does not lend itself to easy, straightforward setups nor towards easy reuse. I will start with familiarizing myself with exactly how Catalyst components are loading and how Bread::Board can be optimally used. I will then implement a ConfigLoader in Bread::Board that implements Catalyst's component instanciation. Then I wll create an application to test this ConfigLoader and finally put the ConfigLoader into Catalyst itself..

Project Schedule
Preparation, Apr 26th to May 23rd
Familiarize self with Bread::Board and Catalyst component loading system

First phase, May 24th to July 16th
Implement 'ConfigLoader' in Bread::Board (create container that implements Catalyst's component instanciation)

Second phase, July 17th to August 16th
Generate an application to use this new ConfigLoader and put into Catalyst itself

Mentors
Florian Ragwitz <flora@cpan.org>
Tomas Doran <bobtfish@bobtfish.net>

References
Matt S Trout <m.trout@shadowcat.co.uk>

License
You may distribute this code under the same terms as Perl itself.

Bio I am a 27 year old student and Perl developer located in the United States. I utilize and contribute to many perl open source projects (Catalyst, DBIx::Class, SQL::Abstract, Moose, various MooseX modules)

I completed Google Summer of Code 2009, SQL::Translator

Eligibility
I am currently a part-time student at Arizona State University and can provide documentation upon request.