I use /models as a script folder and I always try to avoid the use of this.
Controllers are for me only a point of entry, the place where I route and where I got argumuments and I decide about the template rendering. All the rest of logic goes in sub modules, handlers, helpers and datamodels. http://zerp.ly/rochacbruno Em 13/05/2012 17:06, "Sebastian E. Ovide" <sebastian.ov...@gmail.com> escreveu: > Yarin, I see... I know what you mean... I had a quick glance into > compileapp.py line 555... (I guess that it the right place to look at)... > and it looks like that inheritance is not part of it... > > filename = os.path.join(folder, 'controllers/%s.py' >> % controller) > > > nevertheless, about *modules*, why do you think that the controller logic > doesn't fit in modules ? Modules are just that: modules.... you can place > there anything you want without breaking any layer of your design..... > > I have not done any BIG job with web2py, so we should ask to people whom > have done something big to be fair... but I would put under controllers > only just that: controllers... as small as possible.... leaving all the the > complex logic in the modules.... same for the models.... just those models > that you need ALL the time.... and leave other model in modules (in the > right path of course)... > > well... I'm not saying that this is the best way... just my personal taste > ;) > > > > On Sun, May 13, 2012 at 8:00 PM, Yarin <ykess...@gmail.com> wrote: > >> Sebastian- I already have class hierarchies for my model/module stuff. >> What I'm talking about using classes to handle controller logic- assembling >> views, controlling access, processing forms, managing redirection, etc - >> that stuff belongs in controllers, not modules. But the flat, one >> function-per-controller design means the power of classes can't easily be >> applied to that stuff. Sure, I could write a controller class hierarchy and >> pull it into each function, but that seems like a lot of grunt work for >> what frameworks like kohana and web.py have out of the box with controller >> classes. >> >> PBreit- I'm doing this too, but again, lacks the organization of classes. >> >> I'm not saying the web2py way is wrong- I'm sure Massimo has a reason for >> setting things up this way, as almost everything I've seen is incredibly >> well thought out- but I just don't see the upside of this approach, and as >> my project has grown large I've found myself wishing I had controllers I >> could subclass.. >> >> On Sunday, May 13, 2012 2:18:21 PM UTC-4, sebastian wrote: >> >>> in Java (say for example Java EE 6), you would have your own Classes >>> hierarchy (as extended as needed), and then you would inject what you need >>> in your "controllers" (backing beans)... in web2py you can do exactly the >>> same. Create your own hierarchy of classes (as extended as needed) and then >>> just import the modules that you need in your controllers.... >>> >>> On Sun, May 13, 2012 at 7:07 PM, Yarin wrote: >>> >>> That's what I've already been doing, but making decisions in the model >>>> on which code to run based on the request controller turns into a hot mess >>>> of distributed logic and violates the most basic principles of MVC (Models >>>> knowing about Controllers?) >>>> >>>> >>>> On Sunday, May 13, 2012 1:58:25 PM UTC-4, simon wrote: >>>>> >>>>> You can put common controller functionality in the model. This is >>>>> executed on each request before the controllers. You can check which >>>>> controller is called in request.controller. >>>>> >>>>> On Sunday, 13 May 2012 17:31:22 UTC+1, Yarin wrote: >>>>>> >>>>>> I've always liked the idea of controllers as classes, allowing for >>>>>> subclassing of controllers, and thereby providing an easy means of >>>>>> handling >>>>>> common controller functionality. I'm curious as to why web2py didn't >>>>>> follow >>>>>> this approach? Is there a recommended way of handling code that is common >>>>>> to a group of controllers (besides sticking it at the top of a controller >>>>>> file)? >>>>> >>>>> >>> >>> >>> -- >>> Sebastian E. Ovide >>> >>> >>> >>> >>> > > > -- > Sebastian E. Ovide > > > > >
