Hy!
First of all, I agree with those who think htat unicode support should
be part of catalyst core, but this message is about discussing my
impressions on how catalyst may can better support plugins.
The whole thing started with the problem that C::P::Unicode::Encoding
don't decodes action arguments (and action names, really the entire uri
before query parameters). I have made a test case for the argument part
of the issue (committed[1] as rev #13007).
I've been digging into the code to find out how we solve that problem,
and it seems pretty hard...
The problem is that to touch the arguments we may need to hook methods
in the dispatcher, or in the engine. For this, because the plugins
loaded before both engine and dispatcher, we should hook setup_engine /
_dispatcher to then hook the engine / dispatcher when they loaded.
This should work but really complicated..
One solution may be to load plugins after the two, but it *may* break
existing plugins, if they do something simlar described above. (and I
don't even know if there is a good reason for this loading order)
Another and maybe better solution is to have a list of roles that shoild
be applied to engines / dispatcher as soon as they loaded, so plugins
simply populate the lists at their loading time, and setup_engine /
_dispatcher will take care of the rest! This may be a far more elegant
method than every plugin implement their role loadings into engine /
dispatcher classes!
Cheers!
u-foka
P.S.: Please forgive me if I understand something wrond, because, even
if I already found some time to read the code, catalyst is relatively
new to me.
[1] http://dev.catalystframework.org/svnweb/Catalyst/revision?rev=13007
First of all, I agree with those who think htat unicode support should
be part of catalyst core, but this message is about discussing my
impressions on how catalyst may can better support plugins.
The whole thing started with the problem that C::P::Unicode::Encoding
don't decodes action arguments (and action names, really the entire uri
before query parameters). I have made a test case for the argument part
of the issue (committed[1] as rev #13007).
I've been digging into the code to find out how we solve that problem,
and it seems pretty hard...
The problem is that to touch the arguments we may need to hook methods
in the dispatcher, or in the engine. For this, because the plugins
loaded before both engine and dispatcher, we should hook setup_engine /
_dispatcher to then hook the engine / dispatcher when they loaded.
This should work but really complicated..
One solution may be to load plugins after the two, but it *may* break
existing plugins, if they do something simlar described above. (and I
don't even know if there is a good reason for this loading order)
Another and maybe better solution is to have a list of roles that shoild
be applied to engines / dispatcher as soon as they loaded, so plugins
simply populate the lists at their loading time, and setup_engine /
_dispatcher will take care of the rest! This may be a far more elegant
method than every plugin implement their role loadings into engine /
dispatcher classes!
Cheers!
u-foka
P.S.: Please forgive me if I understand something wrond, because, even
if I already found some time to read the code, catalyst is relatively
new to me.
[1] http://dev.catalystframework.org/svnweb/Catalyst/revision?rev=13007
Attached Files:
-
smime.p7s (4.70 KB)