-
-
Save edenc/1093469 to your computer and use it in GitHub Desktop.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| 1 - Test 1 or 2 more apps | |
| 2 - write tests for getting default_model / default_view from config? | |
| 3 - move block from sub controller to Catalyst::Utils | |
| 4 - kill components class data | |
| 4.1 - kill initialization in sub setup | |
| 4.2 - kill duplication: http://paste.scsys.co.uk/123648 | |
| 4.3 - create a sub components that returns all components | |
| 4.4 - merge with around components => sub {} | |
| 4.5 - locked hash (Hash::Util) | |
| 5 - block inside sub setup: | |
| Fix me to be a method on the container? (Or at least get a) data | |
| structure back from the container!! | |
| ( t0m: My only thought really is that maybe it should call | |
| $c->container->something, | |
| rather than $c->components, which is/will be implemented in terms of | |
| $c->container->something anyway ) | |
| 6 - kill $c->comp('MyApp') (confirm with t0m) | |
| 6.1 - Catalyst::Exception "You called $c->comp('MyApp') and deserve to | |
| die in a fire" :) | |
| 6.2 - fix unit_core_plugin.t | |
| 7 - kill myapp as controller | |
| 7.1 - sub MODIFY_CODE_ATTRIBUTES { die("Catalyst applications (aka | |
| MyApp) cannot be controllers any more.. etc etc") } | |
| 8 - move _find_component to container | |
| 9 - 'This behavior is going to be deprecated in future releases' -> | |
| 'This behavior is deprecated, and will be removed in a future release' | |
| 10 - deprecate ->component returning list | |
| 10.1 - create sub component_list? | |
| 11 - take a look at setup_component. sub COMPONENT being called twice. | |
| 12 - fix helper (order of statements) | |
| 13 - write tests for apps using ConfigLoader and ConfigLoader::* | |
| 14 - ->comp(qr/::M::/) will search ->components | |
| 15 - mv live_view_warnings.t => live_mvc_warnings.t (model and controller | |
| too) | |
| 15.1 - fix the test so that it looks for the correct warning | |
| 16 - kill search_extra (also confirm with t0m. Some people answered they | |
| were using it, right?) | |
| Aside from that, next big steps would be: | |
| 17 - Write documentation | |
| 18 - Move stuff in setup / setup_component / setup_components / | |
| locate_components down to the Container | |
| 19 - make BB handle plugins | |
| 19.1 - replace C::P::PluginLoader | |
| instead of Catalyst::Plugin::PluginLoader support something like | |
| config for MyApp::Web, maybe have a key like plugins, roles, etc? (container | |
| role, or something similar) | |
| 20 - make hard things easy (models that share the same config) | |
| On this last item, are these things below (from the proposal) possible | |
| already? If not, how could I do them? | |
| - It would make it easier to separate application code from the specific | |
| Catalyst bits. That way, the code can be wired to Catalyst as a webapp just | |
| as easily as to a crontab script. | |
| - Users of the Catalyst framework, that is, application developers, will | |
| be able to define how components are instantiated, and their lifetime. That | |
| would remove the need for Catalyst::Component::InstancePerContext and | |
| Catalyst::Model::Adaptor, for example. Also, it would be possible to define | |
| components without the actual file existing, as implemented in | |
| CatalystX::DynamicComponent::ModelsFromConfig. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment