Apologies, my example was purposefully extreme in order to highlight why
it's an anti-pattern to have monolithic source files. It was in
response to a previous post asking me to explain.
Finally: I was imagining the framework automatically importing files
from a model and controller directory. However given that the current
model.py and controller.py files can be used to contain very simple
stuff OR import files from user created model and controller directories
then I guess that covers both bases like you say. In fact I've just
rigged a project to do this and it works a treat.
Ended up with something like:
controller.py
model.py
...
controllers/
kuser_controller.py
blog_controller.py
...
models/
kuser_model.py
blog_model.py
...
Using considerably less keystrokes than used on this thread. :-) Guess
it's up to TurboGear developers to do whatever feels right (Pythonic?).
As long as I can continue to do the above that's me happy.
> 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...
>
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
