[Catalyst-dev] Plugins vs. Engines, Dispatchers...

Tomas Doran bobtfish at bobtfish.net
Sun Mar 7 21:30:02 GMT 2010

On 6 Mar 2010, at 19:43, Eisenberger Tamás wrote:

> 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.

Good stuff, so do I :)

The reason it isn't there yet is that people haven't yet worked on it.

Please feel free to branch and start, people will be happy to be  
pestered with questions/help you out. :_)

> 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..

Yup. And when you look into Catalyst::Plugin::Unicode::Encoding, what  
it's already doing messes with the internal state of several things.  
Not very pretty.

This and the invasiveness as what convinced me that the only way to do  
it correctly was to move unicode handling into core.

> 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!

I see what you're getting at here.

The current best solution is to forcibly use CatalystX::RoleApplicator  
on the application after setup_finalize.. Which isn't amazing, but  
nobody has tried to propose a better API really.

> 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.

No, I think you're spot on with your conclusions here.

> [1] http://dev.catalystframework.org/svnweb/Catalyst/revision? 
> rev=13007

Thanks for the reminder (again), I'm going to have a look into this now.


More information about the Catalyst-dev mailing list