Hello fellow developers,
I knoooow I am a cranky little man and I know this branch has been left
untouched for quite some time, but I'd like to pick up the pieces. Starting
next week, I will be dedicating 15-20 hours a week, as time allows, to
bringing this branch back up to speed and getting it merged. It's been a
while since I took a look at it though, so I am taking
comments/questions/suggestions. I helped zby work on this late last year,
but then things sort of fell off. I know t0m had some involvement in here,
but I don't remember if anyone else participated.
For now, my immediate goals are (in this order):
1. Create some sort of back-compat layer that uses CMOP to split plugins
and reapply the provided subs / attrs / modifiers to MyApp and the
MyApp::Context.
2. Backport bugfixes, features that have been added since the branch
3. Test it out and see what breaks, fix, repeat
4. Hopefully merge
I would like to publicly ask for any help anyone might be able to provide,
whether it be wrt architecture and planning, coding, testing, documentation
or arguments for or against any design choices.
My very first steps will be:
- Change the context_class default to be MyApp::Context
- Make sure MyApp loads *context_class* or, if it doesn't exist, create
it automatically as an empty subclass of Catalyst::Context. Once this is
cemented as desirable behavior, I'll update C-Devel to also create that
MyApp::Context at catalyst.pl time.
- Change *Catalyst::setup_plugins *to be smart enough to know where and
how to apply role plugins and spit some temporary debug output
- Change *Catalyst::_register_plugin* to be smart enough to pull out the
right methods from superclass-type plugins and apply them where they belong
I'll have to think of a semi-sane behavior to use when I have no sane way of
knowing where methods should actually go. and then write a comprehensive
HOWTO on updating existing plugins.
But, I still need help figuring out how we are going to want people to use
plugins across app and ctx. Should we make uses use "with
CatalystX::Plugin::SomeRole::App" && "with
CatalystX::Plugin::SomeRole::Ctx" respectively or will people complain about
this being way too much typing? Should plugins all be centralized into MyApp
with the plugin itself overriding something like _build_context_plugins so
MyApp applies all the plugins to the context class or should this be the
responsibility of the user?
How much mixing do we need to support between strict back-compat syntax and
new syntax? (could affect plugin application order)
I look forward to hearing any and all of your ideas, and hopefully some help
with the coding too.
--
Guillermo Roditi (groditi)
I knoooow I am a cranky little man and I know this branch has been left
untouched for quite some time, but I'd like to pick up the pieces. Starting
next week, I will be dedicating 15-20 hours a week, as time allows, to
bringing this branch back up to speed and getting it merged. It's been a
while since I took a look at it though, so I am taking
comments/questions/suggestions. I helped zby work on this late last year,
but then things sort of fell off. I know t0m had some involvement in here,
but I don't remember if anyone else participated.
For now, my immediate goals are (in this order):
1. Create some sort of back-compat layer that uses CMOP to split plugins
and reapply the provided subs / attrs / modifiers to MyApp and the
MyApp::Context.
2. Backport bugfixes, features that have been added since the branch
3. Test it out and see what breaks, fix, repeat
4. Hopefully merge
I would like to publicly ask for any help anyone might be able to provide,
whether it be wrt architecture and planning, coding, testing, documentation
or arguments for or against any design choices.
My very first steps will be:
- Change the context_class default to be MyApp::Context
- Make sure MyApp loads *context_class* or, if it doesn't exist, create
it automatically as an empty subclass of Catalyst::Context. Once this is
cemented as desirable behavior, I'll update C-Devel to also create that
MyApp::Context at catalyst.pl time.
- Change *Catalyst::setup_plugins *to be smart enough to know where and
how to apply role plugins and spit some temporary debug output
- Change *Catalyst::_register_plugin* to be smart enough to pull out the
right methods from superclass-type plugins and apply them where they belong
I'll have to think of a semi-sane behavior to use when I have no sane way of
knowing where methods should actually go. and then write a comprehensive
HOWTO on updating existing plugins.
But, I still need help figuring out how we are going to want people to use
plugins across app and ctx. Should we make uses use "with
CatalystX::Plugin::SomeRole::App" && "with
CatalystX::Plugin::SomeRole::Ctx" respectively or will people complain about
this being way too much typing? Should plugins all be centralized into MyApp
with the plugin itself overriding something like _build_context_plugins so
MyApp applies all the plugins to the context class or should this be the
responsibility of the user?
How much mixing do we need to support between strict back-compat syntax and
new syntax? (could affect plugin application order)
I look forward to hearing any and all of your ideas, and hopefully some help
with the coding too.
--
Guillermo Roditi (groditi)