On Feb 19, 2009, at 8:43 AM, Jonathan Vanasco wrote:
is that the 'controller' argument isn't actually the name of the controller. its the name of the package that the controller is in. (?!?)
Right, its just the package name. This is mainly due to Rails legacy, as thats how they handle it as well. It wouldn't make sense for the controller (which appears in the URL in many cases) to be the class itself, because Python convention for classes is title case, and I think it'd be really ugly to have:
/admin.Admin/view/4 As a URL, vs having: /admin/view/4Note that if this upsets you, you are of course free to alter how the controller is looked up by subclassing PylonsApp and changing the appropriate method:
http://pylonshq.com/docs/en/0.9.7/modules/wsgiapp/#pylons.wsgiapp.PylonsApp.__call__Just override the find_controller method to look it up as desired, its a short method so this should be pretty trivial. I don't expect the system to make everyone perfectly happy, which is precisely why its easy to tweak little things like this. :)
Note that the resolve() method calls find_controller with the string from Routes, that too can be changed by replacing resolve, ie, if you didn't want to use Routes at all.
Also, your criticism is a little off, as Routes is not the one that is actually determining what is done with the dictionary Routes returns, PylonsApp is the one taking that string, and then looking up a module and pulling a class reference out of it. You could for example give Routes function references and have it dispatch to the functions like Django does, here's a sample where the controller class is directly provided to Routes:
http://pylonshq.com/pasties/791That also has the advantage of easily allowing multiple controller classes in a single module.
Customize as desired. :) Cheers, Ben
smime.p7s
Description: S/MIME cryptographic signature
