I don't see any problem with breaking up your controller if you find it more manageable. Note, if you have utility functions that are needed by multiple controllers, you can also put them in a model file. Or if you prefer modules but want to make your db and auth instances more easily available, you can add them to the 'current' object. In a model (or wherever it is defined):
current.app.db = db And then in a module, you can import 'current' via: from gluon import * # imports entire API, including 'current' Then you have access to the db via current.app.db (note, the '.app' isn't required -- just a way to avoid potential namespace issues in case the framework decides to add more items to 'current'). See http://web2py.com/book/default/chapter/04#Accessing-the-API-from-Python-modules. BTW, is this for http://game.savzombies.com/hvz/default/? I like the video. The old site was nice -- it's listed on http://web2py.com/poweredby/. Anthony On Monday, December 5, 2011 2:57:18 AM UTC-5, Ryan DowlingSoka wrote: > > Hi there! I started creating a website for a game at my college with > web2py last winter, and this winter I am cleaning up a lot of the > things I did rushed, and making it something that others can use... > > IE: not so reliant on me creating one time use controllers, or going > straight to the shell to fix things. > > With that in mind, my default controller has become what appears to be > a bloated beast of a python file and I'm wondering if I am right that > I need to do something about it, or if I should just clean it up where > I can and keep it all together. > > A big part of me loves compartmentalized modules, with a couple of > functions in each, and I feel like for what I am doing it seems weird > that I am writing what i would consider utility functions in the > controller that also does page logic. > > For example, in the game the site is for a database has to often be > checked to see what team the user is on, this can change rapidly and > is needed in lots of places, so I created a utility function called > "zombieTest()" with an optional argument for an inputted id number. > > In my mind I want this to be in the 'modules' folder and imported in. > In practice this raised a bit of problems for me. When I finally > started doing just that i realized a couple of things: first off db's > have to be passed in, so it just adds another layer to using the > zombieTest. It seems like I would always be putting in zombieTest(db), > and if I want to test the current user id zombieTest(db, auth) > Or maybe always requiring auth.user.id to be passed in directly for > the id number. > And while I could do that it just seems like a step backwards.... > > > ... > > So I come to the much more experienced people at this than myself, and > ask: > > "Is the default controller being around 100kb a real issue?" > "Is it wrong to create utility like functions like the one above that > aren't ever meant to support views in the controller?" > > and if so- > > "How do I keep similar functionality, but put them in the correct > place, or seperate the controllers." > > and if not: > > "When should I seperate the controllers- or should I only do that for > parts of the site that are practically seperate for eachother?" > > > Thanks! I just realized that I might be making my life harder rather > than easier so I thought I would ask before I go much farther. > > >
