Justin Johnson <[EMAIL PROTECTED]> writes: > As an application grows it is natural to split it out into modules or > sub-systems - purely for maintenence purposes if nothing else. For a > website you can imagine modules that deal with administration, a > blogging module, forum module, photo gallery module - that kind of > thing. In this scenario it's likely we'll have a number of classes in > each module addressing various aspects of our websites functionality.
This is where entry points and separate eggs come in, isn't it? Each independent part is an application by itself and you plug them in your big system. This is how it works for lots of Enterprise Class systems and even simple ones (you have modules for Squirrelmail! Why citing some J2EE application when a simple webmail does the same?)... > So, why not just shove it all in one file? Flat is better than nested > right? This is taking to the extreme. Imagine the horror of coming to > the system where it's just a 50k+ lines file. It's not an 8 or 80 thing. We have, today, 44. ;-) An average solution that is very good in quality and allows complete flexibility. Applications can grow easily, even though they start small. > It's worse than that though. Because all classes are lumped into a > single file it affects the way you extend the app. In a flat app > everything is on tap - no need to worry about separation of concerns, > module developement etc. Access anything from anywhere. Soon it > becomes an untanglable mess requiring a huge amount of refactoring. This is not reality today, so it is not what should be debated here. You have separation and you have VERY EASY means to separate more. > Heaven forbid you're app goes large and has a sizable team working on > it. 20+ programmers hacking and diffing/merging away on a monolithic > source file. My app is very large. And TG is supplying all what I need. It has, for now, more than 60 tables on the database and will have many more depending on what the client demands for his needs. So, guessing what I or other users are doing today is no good as well... It isn't just about huge apps, small apps are also being written in TG. See those blogs, for example: 4 or 5 classes, 2 or 3 views, 1 or 2 controllers and that's it. Nothing more. Is it an irrelevant application? No, I don't think so. Their authors found it worth writing. > So, encouraging modular design is a good thing. It's about > managability, ecouraging development of reusable components/libraries > and a path way to scaling. It is encouraged. You can simply create a new controller, import it in controllers.py and voi là! Everything is there and in a separate file. In fact, my controllers.py has 101 lines, including blank lines and comments. And it is importing 35 other modules -- i.e., 35 other controllers. And nothing is preventing me from using this same idea that works with any python script. And nothing prevents me from having drafts on the same directory without stopping my code from running. Just separating the code won't make in more clear that new files should be created and the user shouldn't edit "controllers/controller.py" or "controllers/__init__.py". What would prevent him from doing that? Anyway, I'm getting off of this thread... I made my point: -1 on both. I don't see how it will help scaling in a way that is impossible today. And I don't see total newbies writing applications with 100 controllers, 500 database tables, etc. without having other kind of problems that wouldn't be much harder than writing a simple import as of today or creating a module themselves... -- Jorge Godoy <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
