I'd say it's reasonable for an average smallish web project to have a few javascript files (Mochi/Prototype/Scriptaculous maybe), one or two css stylesheets and a few images for page headers/icons/buttons etc. The current structure provides for this nicely. Your tree example includes the addition of widgets and js/css files closely grouped. Quickstart can't predict exactly which widgets you'll want so shouldn't create widget directories (there may be dozens of widgets in the library). If I get around to using widgets in my app I'll structure them just as you have done. :-)
I'd also say it's likely to have a number of controllers, several models and a bunch of views (templates). I've already stated my own preference for having controller/model directories and the reasons behind it so there's not much point repeating that. However, here are some observations born out of looking at several recent emails: I think this (quickstart structure) debate is symptomatic of TurboGears origins as component glue rather than being extracted from a reasonably sized existing product (yes, I'm talking about BaseCamp and Rails). For an app the size of BaseCamp it would have been insane to stuff all the controllers and models into a single file. So they provided a simple structure that worked from small and large applications alike that takes care of 80%+ cases. They didn't go out to please everybody with Rails, just to get a good % either side of their flagship app. You can't underestimate that kind of focus because it makes decision making a lot easier. Gears people (me included) might be sick of hearing about Rails but it doesn't hurt to consider some of the reasons why they got it right. In TurboGears we have to imagine this kind of product because it doesn't exist and the problem is everyone imagines a different thing so it becomes highly subjective rather than being born out of a production quality pragmatic use-case. I did wonder if quickstart warrented such a lengthy discussion but after all it's the first interface point with new users so I guess it really is important. > > From: "BJörn Lindqvist" <[EMAIL PROTECTED]> > Date: 2006/03/09 Thu AM 08:53:46 GMT > To: [email protected] > Subject: [TurboGears] Re: bike shed #2: controllers.py vs. controllers > > > > 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. > > If it was up to discussion I would complain about that. I don't like > it that TG creates directories for me that for the foreseeable future > will be empty or only contain one file. In the TG source there are a > few static directories that doesn't follow the quick start model and > contain both javascript and css in the same directory. I also don't > like that the static hierarchy is divided by file type. I code my page > layouts mostly using javascript widgets and therefore I want it > divided by my widget classes, like: > > static/ > content.css > utils.js > formwidget/ > formwidget.js > formwidget.css > tabpane/ > tabpane.js > tabpane.css > > I think that one size does not fit em all so it's best to try and be > as simple as possible. I would prefer if most of the cruft that quick > start generated was opt in features instead. For example, how many > here have read the README.txt file that TG generates? How many have > modified it and actually written something worthwhile in it? YAGI - > you aren't gonna need it. > > > 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. > > > > > 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 > > > > > > > > > > > -- > mvh Björn > > > ----------------------------------------- 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 -~----------~----~----~----~------~----~------~--~---
