On 12/20/05, Peter Hunt <[EMAIL PROTECTED]> wrote:
> - Change TG's controller style slightly. In Subway, we opted for
> multiple .py files with functions rather than classes with methods.
> This is _not_ the big picture, however. The important thing was that
> Subway automatically assembled the tree of controllers rather than
> forcing the user to add attributes to their root controller manually.
> On my hacked up local SVN of TurboGears, I implemented a minor change
> which allows the user to write classes like this:
>
> class MyRoot(controllers.Controller):
> mount_path = "/"
> # methods would go here
>
> and they would be automatically assembled via a metaclass. I'd also
> propose making controllers a package and not a module, since a lot of
> code will go in there and it would be easier to split up into multiple
> .py files. In addition, using the new mount_path system would let us
> just do a "from controllers import *" to set up the controller tree. I
> can post my updated code if anyone's interested.
Frankly, I don't see the advantage here, and I see disadvantages. I
may be misunderstanding the full mechanism, though. It's one line of
code in the normal CherryPy way or the Subway way. (It may be two
lines of code in the CherryPy way if you have imports to do.)
Let's look at a scenario in both Subway style and TurboGears style:
class MyRoot(controllers.Controller):
mount_path = "/"
# normal CherryPy methods come below
class ABlog(controllers.Controller):
mount_path = "/blog"
# normal CherryPy methods come below
---
class ABlog:
# normal CP stuff
class Root(controllers.Root):
blog = ABlog()
# normal CP stuff
The difference is whether the parent controls the relationship or the
child does. Here are what I see as disadvantages to having the child
control it:
* two controllers could be configured on the same path (admittedly
easy to flag an error for)
* not as pythonic for composing apps together
I know that you've been thinking along the lines of a "product API".
What I've been shooting for is the ability to compose applications
using standard Python mechanisms. Install an egg, import the class and
hook up an instance to your tree... that would hardly even need
documentation, because it's just the "python way". There were some
problems with configuration and such that made this not work properly
with CP2.1. I believe those problems are resolved in CP2.2.
Kevin
