On Mon, Apr 5, 2010 at 10:34 AM, Mike Orr <sluggos...@gmail.com> wrote:
> > Philosophically, the model shouldn't have any structural (WSGI- or > HTTP-specific) or UI (HTML-specific) code in it. The input values > are coming from POST parameters, which the model shouldn't know about. > The model should make sense outside a web context. So there should > be at least a thin layer validating/translating the input to generic > arguments. Yeah, I'm no expert, nor zealot, but I like the above. Sometimes by controller methods are pretty large, but sometimes managing/parsing the request is pretty large. And sometimes setting "c" for the templates is pretty large, too. To pull that out into someplace else seems pointless; gluing the request to the "business logic" is what the controller should do. Basically, anything for me that talks to "Request" needs to be in the controller. I see helpers as basically an extension of controllers (for shortcuts) and indeed, try to keep the so-called "business logic" in model/* or even lib/*. Of course, this is in theory; in practice, I tend to work for a panicked client and have to cruft up my controllers and templates Real-Good and think "I'll fix this later" but later rarely comes; there's always some new cruft to make on something else. I noticed one thing that may be worth bringing up... some calm, deliberate forethought about routes.py seems to go a long way to helping keep things nicer later. It's also likely to be the first place for another dev to start learning about the app; good dispatch design will really help keep the controllers nice. FWIW. -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
