[EMAIL PROTECTED] wrote: > 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.
Yes, it does portray TG's origins, but not as glue, but rather as a web-*application* framework. I for one very much appreciate that (in fact it was the reason that lured me to it). I suppose it might be of use to have several quickstart strategies/templates/scripts (choose your buzzword ;)) with simplest being the default. For example: tg-admin quickstart --strategy=super_duper_complex_project.py Cheers, Simon --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
