Interesting point about one model file - suppose a lot boils down to expected usage of SQLObject objects.
I thought the idea was to treat them similar to normal classes in that you'd be supplying various methods to implement functionality using the object data. I'm really trying not to sound too preachy here (it's hard :-) ) but keeping lot's of classes inside a single file is just ... bad practice. I think the bottom line is that if quickstart had been written to create model and controller directories in the first place this wouldn't be an issue and you probably wouldn't be putting all your SQLObjects into a single source file. Nobody is complaining about the static directory. This actually points out the reason to get things right at this stage and the reason why, even though it's a bike shed argument, it's worth beefing out. These issues can seem innocuous enough to begin with but can get ugly quickly and have a negative effect on development. Ah, for example. In my web project I have several dozen SQLObject derived classes modelling my data with varying degrees of functionality in methods. Having that all in one file would be a very bad idea for a number of very well know anti-pattern reasons. Having fewer SQLObjects in one file seems ok but is just bad practice with the consequences waiting to happen. Of course, if your project never grows beyond a handful of model files then this won't bite you. Well, guess it's up to Kevin to weigh it all up. I've just had really bad experience in the past by projects starting out wrong at this seemingly simple level. > > From: Jonathan LaCour <[EMAIL PROTECTED]> > Date: 2006/03/08 Wed PM 03:43:07 GMT > To: [email protected] > Subject: [TurboGears] Re: bike shed #2: controllers.py vs. controllers > directory > > > > The project created by quickstart is intentionally very simple. > > Clearly, though, as a project grows you might need more than just > > model.py and are very likely to need more than controllers.py. > > > > Through the import statement, it's very easy to add more modules and > > get those names into the "standard" namespaces if you want them there. > > Given the near inevitability that you'll probably need more than just > > a single controllers module, would people prefer to have a controllers > > package set up by quickstart instead? How about the model? Do you find > > yourself outgrowing a single file there? > > I am finally getting around to this, so I will offer my votes: > > +1 for a controllers package > -1 for a models package > > I am all about the default matching likely structure for most > applications. IMO, most applications will need several controllers, > but only one model. I don't really care for the symmetry argument, > as it has nothing to do with what people actually do. > > -- > Jonathan LaCour > http://cleverdevil.org > > > > > ----------------------------------------- Email sent from www.ntlworld.com Virus-checked using McAfee(R) Software Visit www.ntlworld.com/security for more information --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~----------~----~----~----~------~----~------~--~---
