Re: [TurboGears] Re: bike shed #2: controllers.py vs. controllers
just...@ntlworld.com
The main idea behind having a quickstart is that it creates an initial structure that is ready for filling with application specific content. We make things quicker and easier for the user by providing the places to put their app files. If a user is going to moan because there is model, view and controller directory where we expect them to put their, erm, model, view and controller(!) files, then I think this is going to be the least of our problems with them.
Realistically then, having model, view and controller quickstart generated directories isn't going to put new users off anymore than the current static/css+images+javascript structure does. It's reasonable to assume that as a project grows it may have many model elements, controllers and views. Having a starting structure that supports growth and organization is just the right thing to do.
Sure, we can save new people a second or two in eyeball time but they'll pay later when their project starts turning to mush and they have to reorganise anyway. Then we end up with every user having different directory structures for no good reason.
Incidentally I'd probably also rename the 'templates' directory to 'views' too. That way it fits in properly with the Model, View and Controller terminology. :-)
I don't know if the django guys have gone overboard with their structure but Rails certainly hasn't and it's just a no-brainer there.
>
> From: "Michele Cella" <michel...@gmail.com>
> Date: 2006/03/08 Wed AM 10:31:29 GMT
> To: "TurboGears" <turbo...@googlegroups.com>
> Subject: [TurboGears] Re: bike shed #2: controllers.py vs. controllers
> directory
>
>
> Ian Bicking wrote:
> > Michele Cella wrote:
> > > If we go down this path IMHO it would also be nice to provide some
> > > basic conventions (over configuration, rails marketing hype :D), note
> > > that we should not enforce them, and use a tool like paster to add a
> > > new controller along with tests (like pylons) for example or a new
> > > template that extends master.kid and so on.
> >
> > I don't like hierarchy, and I never use more than one file for my
> > SQLObject classes (which is a subset of all the models in a system, but
> > that's just tedious semantics ;). But this is probably the best
> > argument for separate files -- or, more generally, tool support. I
> > assume the model designer will work much more easily with a models
> > package as well.
> >
>
> Yes, the big advantage of having a single model.py and controllers.py
> is that you can dive in immediately, providing tools means that you
> must teach how to use them and why to use them, this increases the
> "learning fast" delay but probably gives more benefits on the long run
> (during the project life time and the development of other projects)?
> dunno...
>
> It's a matter of finding the right balance, I should admit that when I
> tried Pylons/RoR while searching for the supposed way to add a new
> controller I've found myself slowed down in respect to TG, for example
> Django guys some times ago discussed the possibility of reducing the
> base structure of a new project to something like TG.
>
> > In a similarly veign, Pylons (and PasteWebKit) both create templates
> > with controllers, including creating the boilerplate template. As an
> > added convention, if there is a file named
> > "blank.whatever-your-template-extension-is" it'll copy that for the
> > template, so you can futz and create conventions on a project level. I
> > haven't myself been creating tests -- I guess I just don't write my
> > tests with the same granularity as a table or screen -- but I can
> > certainly see the benefit.
> >
> > I've experimented with automatically modifying files instead of writing
> > new files (Paste has some support for this), but I find this hard to
> > maintain. Python just isn't the kind of language where you can safely
> > modify source in an automated way.
> >
>
> Some times ago I've looked at paster for this reason (modifying files)
> and noticed that you provide support for that but it's indeed and and
> hard thing to do and maintain. :-)
>
> Thanks.
>
> Ciao
> Michele
>
>
>
>
-----------------------------------------
Email sent from www.ntlworld.com
Virus-checked using McAfee(R) Software
Visit www.ntlworld.com/security for more information
just...@ntlworld.com
> I agree. It's much more reasonable to require some modifications for use
> on bigger projects that to incur more boilerplate for everyone.
Everyone? This is a distrubring proposition, that only a few of us will ever have more than one model.py and controller.py
Maybe by this same logic we should ditch templates directory because most people will have just 'hello_web.kid'? Perhaps static and css/javascript/images should be flattened too because most people will have one css file, one/none javascript file and a couple of images. No need for hierarchy there.
Well, that doesn't work obviously but the reasoning is identical.
>
> From: Simon Belak <simon...@hruska.si>
> Date: 2006/03/08 Wed AM 11:13:33 GMT
> To: turbo...@googlegroups.com
> Subject: [TurboGears] Re: bike shed #2: controllers.py vs. controllers
> directory
>
>
> Michele Cella wrote:
> > It's a matter of finding the right balance, I should admit that when I
> > tried Pylons/RoR while searching for the supposed way to add a new
> > controller I've found myself slowed down in respect to TG, for example
> > Django guys some times ago discussed the possibility of reducing the
> > base structure of a new project to something like TG.
>
> I agree. It's much more reasonable to require some modifications for use
> on bigger projects that to incur more boilerplate for everyone.
>
> Cheers,
> Simon
just...@ntlworld.com
> I'like "Keep simple things simple and complex things possible"
> statement,
Yes, great rule of thumb.
I'm puzzled that having a models and controllers directory is somehow being perceived as complex.
We already have good directory structure for statics - is it complex?
We already have a templates (views) directory - is that complex?
>
> From: "gasolin" <gas...@gmail.com>
> Date: 2006/03/08 Wed PM 02:21:50 GMT
> To: "TurboGears" <turbo...@googlegroups.com>
> Subject: [TurboGears] Re: bike shed #2: controllers.py vs. controllers
> directory
>
>
> I'like "Keep simple things simple and complex things possible"
> statement,
>
> How about:
>
> 1. keep current template style in "tg-admin quickstart".
> 2. provide a default "tg-admin quickstart -t project" to generate the
> more hierarchical style controllers/ template.
>
> A person who is familiar to default "tg-admin quickstart" template may
> easily adopt hierarchical template by a little study. (The extra effort
> maybe just copy&paste stuff, but after making a small app in TG, she
> will have enough confidence to do it.
> The transition process also provide a natual chance to refactory her
> small app to project quality)
just...@ntlworld.com
Wouldn't 'admin.py' actually be a controller?
Anyhow to try and dispel FUD over supposed directory structure I'll submit the following mock-up:
my_web_project/
app/
apis/
tag_cloud.py
tag_utils.py
controllers/
controller.py
user_controller.py
login_controller.py
models/
user_model.py
tags_model.py
static/
css/
images/
javascript/
views/
login.kid
entry.kid
tag_cloud.kid
config/
dev.cfg
prod.cfg
setup.py
tests/
user_test.py
login_test.py
>
> From: "Kevin Dangoor" <dan...@gmail.com>
> Date: 2006/03/08 Wed PM 01:47:44 GMT
> To: turbo...@googlegroups.com
> Subject: [TurboGears] Re: bike shed #2: controllers.py vs. controllers
> directory
>
>
> On 3/7/06, Jeff Marshall <mars...@frozenbear.com> wrote:
> >
> > +1 for the controllers/ and models/ subdirectory hierarchy. Every time
> > I create a new TG project, the first thing I do is create a
> > controllers/ subdirectory. I've only had one project that was small
> > enough that I stayed within the single controllers.py file.
>
> For a contrast: the reason quickstart looks the way it does is that I
> figured that one would likely start organizing on application terms as
> they expand beyond one controllers file. So, rather than creating a
> controllers package, one might add an "admin.py" or the like to their
> main project package... then, if that starts to get to be a bit much,
> refactor into some other set of packages that makes sense for the app.
>
> I bring that up for background, not to convince people or say that I'm
> set on that.
>
> When you create a controllers package, what's the name of the module
> inside that package that you use when you start writing your actual
> controllers classes?
>
> Kevin
just...@ntlworld.com
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.
> 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
just...@ntlworld.com
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 <jonatha...@cleverdevil.org>
> Date: 2006/03/08 Wed PM 03:43:07 GMT
> To: turbo...@googlegroups.com
> 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?
just...@ntlworld.com
Oops. Hit send key by accident. Apologies for double posting my semi-rant. :-)
Ian Bicking
>
>> I agree. It's much more reasonable to require some modifications
>> for use on bigger projects that to incur more boilerplate for
>> everyone.
>
>
> Everyone? This is a distrubring proposition, that only a few of us
> will ever have more than one model.py and controller.py
I regularly have 2000 line model files, and it doesn't bother me at all.
Well, okay, a little. But splitting each table into its own file
would be a poor solution. A better solution would be factoring out the
actual logic that causes it to get so big. Partitioning is a poor way
of managing complexity in this case.
Controllers are somewhat different. One issue is that people without
much experience can useful edit controllers, but will have problems
navigating a giant file. Those same people can't really usefully edit
the models anyway.
Also, models are more intimately interrelated than controllers. And all
the models *have* to be imported up-front, unlike controllers.
--
Ian Bicking / ia...@colorstudy.com / http://blog.ianbicking.org
Jorge Godoy
> Interesting point about one model file - suppose a lot boils down to expected
> usage of SQLObject objects.
This is an interesting point. Another one is praticality. Where in
SQLObject's docs there are instructions about setting up multiple files and
integrating them?
> 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.
It depends on how they interact. If you use ForeignKeys, MultipleJoins,
RelatedJoins, etc. then it is a hell lot more practical to *see* all classes
in the same file. Even with tabs or buffers or windows or ... it is easier to
see their relation if they are grouped together. Specially when making
changes that will interfere with this relationship.
> 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.
Where are the docs? The only place where I saw it mentioned is
http://sqlobject.org/sqlobject-admin.html and in a warning that if you have it
in a different namespace then you'll have problems with the automation the
tool is doing.
If we are going to change that, there is a lot of documentation to be written
on that and it has to be very clear so that the user gets what he expects, all
classes and their relationship can be maintained and we don't have to ignore
all of SQLObject's docs. So, more docs, tests and whatever for this, making
sure compatibility with SQLObject still goes on, to avoid surprising long date
users of SQLObject and projects already released.
> 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.
Could you enumerate those well known anti-pattern reasons? And could you also
enumerate some of the bad consequences? When people are reasoning about
something it is much better to make things explicit than imply that all are
thinking the same way you are or have the same background you do. Today is my
Zen of Python (python -m this) citing day: "Explicit is better than implicit."
--
Jorge Godoy <jgo...@gmail.com>
Jonathan LaCour
> but keeping lot's of classes inside a single file is just ... bad
> practice.
Spoken like a true Java person.
Its not at all bad practice in Python. Its very common and "flat is
better than nested" is generally accepted as a mantra in the Python
world. Take a look at the Python standard library, and tell me if
you still think its true :)
I am also not trying to sound preachy, but I thought that this needed
clarification.
> Nobody is complaining about the static directory.
Of course not. You can't put a bunch of images in one file, can
you? You can't put a bunch of templates into one file, can you?
Totally different things, IMO.
I still stand behind my +1 for controllers being a package, and -1
for models being a package.
Jonathan LaCour
> Controllers are somewhat different. One issue is that people without
> much experience can useful edit controllers, but will have problems
> navigating a giant file. Those same people can't really usefully edit
> the models anyway
This is a reasonable argument, and I would actually extend it to say
that people who *are* experienced with Python will also have a much
easier time finding what they are looking for in a controllers
package, rather than a controllers.py file.
> Also, models are more intimately interrelated than controllers.
> And all the models *have* to be imported up-front, unlike controllers.
I think the bottom line is this: model objects are used across an
entire application, and are intimately connected through
relationships and dependencies. Controllers are much more
specialized for a particular part of an application, and are usually
logically separate.
Again, this argues +1 for a controllers package, and -1 for a models
package :)
just...@ntlworld.com
> Spoken like a true Java person.
Bah, rumbled. :-) Although mostly C/C++ where having a source file with a lot of classes is considered a CodeSmell.
I'm still finding my feet with what's considered Pythonic. It's funny - the language is a breeze to pick up but the change in philosophy takes a little getting used to.
Still a bit worried about model.py getting unwieldy though... ;-)
>
> From: Jonathan LaCour <jonatha...@cleverdevil.org>
> Date: 2006/03/08 Wed PM 05:38:59 GMT
> To: turbo...@googlegroups.com
> Subject: [TurboGears] Re: bike shed #2: controllers.py vs. controllers
>
>
> --
> Jonathan LaCour
> http://cleverdevil.org
>
>
>
>
>
-----------------------------------------
ajones
I think in most uses it will not be an issue. The potential headaches
caused by namespaces and SQLObject are more of a worry to me. I think
the best way to configure it is to use a single file by default but
have an example of correct usage set up (and commented out) if you want
to use multiple files.
I agree that this is more important for controllers than models. That
said I think having folders for templates, static content, and
controllers, but not models will be confusing.
I would say that the best way to set it up is to keep the current
configuration but set up the necessary folders/files if people want to
split up their code. Those that don't want it can remove the extra
folders and delete the (commented out) imports. Those that do will have
a much easier time getting that going.
anders pearson
>> Spoken like a true Java person.
>
> Bah, rumbled. :-) Although mostly C/C++ where having a source file
> with a lot of classes is considered a CodeSmell.
in my experience, the code smell isn't having lots of classes in a
single file, it's just having a large file. they get confused though
because having a lot of classes in a file is a good way to get a large
file quickly.
--
anders pearson : http://www.columbia.edu/~anders/
C C N M T L : http://www.ccnmtl.columbia.edu/
weblog : http://thraxil.org/
Justin Johnson
> It depends on how they interact. If you use ForeignKeys, MultipleJoins,
> RelatedJoins, etc. then it is a hell lot more practical to *see* all
classes
> in the same file. Even with tabs or buffers or windows or ... it is
easier to
> see their relation if they are grouped together. Specially when making
> changes that will interfere with this relationship.
The join relations are just explicit versions of the relationships you
get between classes in an application anyway and I personally don't feel
compelled to squeeze them into a single source file.
I'll try and explain the class lumping issue:
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.
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 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.
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.
So, encouraging modular design is a good thing. It's about
managability, ecouraging development of reusable components/libraries
and a path way to scaling.
Jorge Godoy
> 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 <jgo...@gmail.com>
Travis Bradshaw
> that's it. Nothing more. Is it an irrelevant application? No, I don't think
> so. Their authors found it worth writing.
Of course, changing the location of the default controllers and models
to an __init__.py file wouldn't have changed the progress of those
authors at all.
> It is encouraged. You can simply create a new controller, import it in
> controllers.py and voi là!
It might be that easy, but it's certainly not "encouraged". It's not
stated in any way, either indirectly through the quickstart
configuration or directly through "how to grow my TG app" documentation
anywhere in our documentation.
I think one of the best reasons for seperating out controllers and/or
models is being overlooked. Yeah, sure, it's "easy to extend your
application any way you want" with Python. But developers looking to
extend their application aren't looking to do things "any way they
want" because that doesn't require any looking at all... just doing.
A developer in TurboGears wanting to expand is looking for guidance on
best practices that will save him/her the hassle of learning how *not*
to do it and fixing it later. The real solution here is two fold:
extend the quickstart template to provide an example of "what to do"
when building a mature, modular TG application and, second, provide
some documentation on best practices for building, extending, and
maintaining TG applications.
Also, just logically this seems like a little bit of a no brianer.
People new to TurboGears are going to learn whatever is put in front of
them. This means:
Existing Setup:
- New users get up to speed and start developing.
- Users needing to grow their application stop developing and start
researching before getting back to developing.
"Modular" Setup:
- New users get up to speed and start developing.
- User needing to grow their application copy the existing structure
to create a new module and keep developing.
We lose absolutely nothing by changing the quickstart to a more mature
layout, we maintain an inherent barrier to application growth. Who
cares how difficult that barrier really is to overcome, if we can
remove any barriers to quality development for some of our users
without any loss to the rest of the users, then it's a good idea. I
mean, that's entirely the point.
Travis Bradshaw
c.travis...@gmail.com
Justin Johnson
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.
BJörn Lindqvist
>
> 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
just...@ntlworld.com
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" <bjo...@gmail.com>
> Date: 2006/03/09 Thu AM 08:53:46 GMT
> To: turbo...@googlegroups.com
> Subject: [TurboGears] Re: bike shed #2: controllers.py vs. controllers
>
>
Artarious
Nobody is complaining about the static directory.Of course not. You can't put a bunch of images in one file, can you? You can't put a bunch of templates into one file, can you? Totally different things, IMO. I still stand behind my +1 for controllers being a package, and -1 for models being a package.
OTH, if separate models means each model is a separate *database* that would be wonderful. But then I am asking for a new feature.
Artarious
just...@ntlworld.com
I've already split up my SQLObject model files into a models package and it works just fine. I have plenty of joins and dependencies too and the ordering issue doesn't appear any more than it does for normal classes.
For creating a clean-slate database I just have a utility function that imports my models and then runs through them dropping and recreating. Again, no problems.
>
> From: Artarious <arta...@gmail.com>
> Date: 2006/03/09 Thu AM 02:52:09 GMT
> To: turbo...@googlegroups.com
> Subject: [TurboGears] Re: bike shed #2: controllers.py vs. controllers
>
-----------------------------------------
Simon Belak
> 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
Richard Standbrook
> 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
>
+1 to this, I like the idea of starting a project ready for a
controller package, but I think the way it works at the moment is the
most straight forward. Easy for new comers, most common way of
working, etc.
So the ability to specify a more complex quickstart project (tg-admin
projectstart) But only if you need it. It's a nicety, save you having
to set-up the controller package yourself if you know that's how your
going to be working.
Elvelind Grandin
-t templatename.
--
cheers
elvelind grandin
deez...@gmail.com
are used in the real world within TG. This thread has grown so large
and no one has shared any concrete examples yet. :) Anyone? Anyone?
I have a controllers.py that must be 1000 lines now, and it is just
getting a bit long. I need to cut it up, but am not sure of the best
way. I know I need to create some "helper classes" to separate out
certain functionality that is not related to url-mapping, but as far as
having controllers.py as:
controllers/
__init__.py
detail_controller.py
add_entry_controller.py
etc...
Any pointers/examples would be great.
David
Jorge Godoy
> I would like to see various examples of how multiple controller files
> are used in the real world within TG. This thread has grown so large
> and no one has shared any concrete examples yet. :) Anyone? Anyone?
OK... What I have here is:
https://my.site.com/
main -> controller
big_functionality_1 -> controller
/add -> method
/update -> method
/delete -> method
/ -> method
big_functionality_2 -> controller
/add -> method
/update -> method
/delete -> method
/ -> method
big_functionality_3 -> controller
/add -> method
/update -> method
/delete -> method
/ -> method
big_functionality_4 -> controller
/add -> method
/update -> method
/delete -> method
/ -> method
And in my Python code:
(controllers.py)
(... standard imports ...)
(... Python modules imports ...)
# My Project's imports
from project.big_func1 import Big1
from project.big_func2 import Big2
from project.big_func3 import Big3
from project.big_func4 import Big4
class Root(controllers.RootController):
big_functionality_1 = Big1()
big_functionality_2 = Big2()
big_functionality_3 = Big3()
big_functionality_4 = Big4()
(... rest of standard file with small changes ...)
Then it is just a matter of having each BigN to answer for its URL. In it
there should be at least default() and index() methods @expose()d.
> I have a controllers.py that must be 1000 lines now, and it is just
> getting a bit long. I need to cut it up, but am not sure of the best
> way. I know I need to create some "helper classes" to separate out
> certain functionality that is not related to url-mapping, but as far as
> having controllers.py as:
> controllers/
> __init__.py
> detail_controller.py
> add_entry_controller.py
> etc...
>
> Any pointers/examples would be great.
I hope I helped. If you want to have what was proposed here of a controllers
module inside your project, then you'd have all these imports inside
project/controllers/__init__.py instead of project/controllers.py ... And
you'd have to remember to import everything from
project.controllers.big_funcN.
This way, all that is related to http://my.site.com/big_functionality_1 is
at the file project.big_func1. The same for other parts of the site.
For common code you can import from project.utilities or project.utils or
something like that. If you're not using the "controllers" module, then you
can use relative imports and "import utils"...
Be seeing you,
--
Jorge Godoy <jgo...@gmail.com>
deez...@gmail.com
approach.
Thanks for the input.
David
just...@ntlworld.com
I renamed controllers.py to controller.py - the idea being that this is just the _root_ controller.
Next, I created a directory: controllers/
which contains things like:
controllers/
blog_controller.py
forum_controller.py
login_controller.py
json_api_controller.py
...
For controller.py then:
from controllers.blog_controller import BlogController
from controllers.forum_controller import ForumController
from controllers.login_controller import LoginController
from controllers.json_api_controller import JsonApiController
class Root(controllers.RootController):
blog = BlogController()
forum = ForumController()
login = LoginController()
json_api = JsonApiController()
Nothing else in the root although you might be so inclined to put an index and default handler in there.
That's controllers.
For models I did a similar thing. Created a models directory that contains .py source for each SQLObject. 'model.py' then just imports these.
models/
user_model.py
blog_model.py
forum_model.py
tags_model.py
Separating things out like this allows your project to start simply, with structure, and then scale as you add more features. Which is why I advocated quickstart creating a directory structure like this in the first place. I might have mentioned that already. :-)
David isn't going to be the last user wondering how to scale out his TG install. I'd say if quickstart doesn't change then best practices for doing this need documenting somewhere and I just know that when reading this people will wonder why TG quickstart didn't just rig the project like that in the first place.
>
> From: "deez...@gmail.com" <deez...@gmail.com>
> Date: 2006/03/14 Tue AM 01:35:11 GMT
> To: "TurboGears" <turbo...@googlegroups.com>
> Subject: [TurboGears] Re: bike shed #2: controllers.py vs. controllers
>
>
> I would like to see various examples of how multiple controller files
> are used in the real world within TG. This thread has grown so large
> and no one has shared any concrete examples yet. :) Anyone? Anyone?
>
> I have a controllers.py that must be 1000 lines now, and it is just
> getting a bit long. I need to cut it up, but am not sure of the best
> way. I know I need to create some "helper classes" to separate out
> certain functionality that is not related to url-mapping, but as far as
> having controllers.py as:
> controllers/
> __init__.py
> detail_controller.py
> add_entry_controller.py
> etc...
>
> Any pointers/examples would be great.
>
> David
Kevin Dangoor
Here's what I'm thinking:
yourpackage/
controllers/
__init__.py <--- imports your Root
root.py <-- contains your Root
I'm not going to break out model.py right now.
Kevin
Kevin Dangoor
controllers package, I decided that I really do like the slimmer feel
of just having a controllers.py file for the still somewhat common
case of a very small app.
So, there is now a new template that can be used for "big" projects
where you want a controllers package. To use it, type:
tg-admin quickstart -t tgbig
If you want to upgrade an existing project to the big template:
tg-admin update -t tgbig
Running this command will create the controllers package and move it
over to controllers/root.py.
This change was committed in [996]. As an added bonus, I put in a
"release.py" file that gives you a place to put your project's version
information.
Kevin
--
Kevin Dangoor
Author of the Zesty News RSS newsreader
email: k...@blazingthings.com
company: http://www.BlazingThings.com
blog: http://www.BlueSkyOnMars.com
Karl Guertin
> On 3/7/06, Kevin Dangoor <dan...@gmail.com> wrote:
> > 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?
>
> A good number of my projects never move beyond a single model or
> controller. I prefer keeping them as is.
>
> I'd have no problem with the other option being an available profile.
I am a winnar!
Justin Johnson
That seems fair enough. Start small if you like and upgrade when you
need. Or, as I probably will, start with tgbig to begin with and be
done with it. :-)
I'm guessing that tgbig doesn't cater for a models directory with
individual model files currently?
BJörn Lindqvist
>
> I would like to see various examples of how multiple controller files
> are used in the real world within TG. This thread has grown so large
> and no one has shared any concrete examples yet. :) Anyone? Anyone?
I see that you have already gotten much advice, let me share my setup
which is slightly different. I have been using it to develop a
javascript web application for handing job applications. There is only
one controllers.py which contain:
RootController
PersonController
DocumentController
CompanyController
ContractController
I dont know if there is a right way to divide your functionality into
controllers. In my case, each controller (except for the
RootController) maps to a database table. The controllers are used by
the javascript frontend to send and receive JSON:ified XmlHttpRequests
and they basically only acts as a thin layer doing validation and
smoothing out the ugly realities of the database so that the
javascript doesn't see it. The javascript application is written using
qooxdoo which is a totally kickass web gui toolkit.
> I have a controllers.py that must be 1000 lines now, and it is just
> getting a bit long. I need to cut it up, but am not sure of the best
> way. I know I need to create some "helper classes" to separate out
> certain functionality that is not related to url-mapping, but as far as
> having controllers.py as:
> controllers/
> __init__.py
> detail_controller.py
> add_entry_controller.py
> etc...
As I said, I don't know the right way to create controllers. But an
"add_entry_controller" doesn't make any sense to me. IMHO controllers
are classes and as such they should be subjects and represent some
kind of object. "add entry" is more of a verb and sounds like a name I
would give a method instead.
--
mvh Björn
Justin Johnson
> I see that you have already gotten much advice, let me share my setup
> which is slightly different. I have been using it to develop a
> javascript web application for handing job applications. There is only
> one controllers.py which contain:
Well, I've worked in large teams where bunching several classes into a
single source file like that would result in a mob lynching. However
they were C++/Java dev environments and I've been assured that this sort
of thing is a little more relaxed in Python land.
If your app was to grow and you start adding a few dozen more
controllers with a lot more functionality per controller then I'd guess
you'd get a better idea of why separating your controllers might be a
good idea. You'd find it much easier to locate objects/methods and it
gives you the option of easily extracting controllers for use in other
projects (perhaps a login/admin controller you might find useful
elsewhere). Also, having them separate discourages you from making
controllers unnecessarily dependant on methods/code in other controllers
which might seem acceptable if they live in the same source file.
Chances are that you'll get a good idea when your project is becoming
uncomfortable to handle. Again, my experience is in enivronments where
these patterns are well recognised and working practices are put into
place early on to avoid expensive refactorings later. As usual, YMMV.
Jorge Godoy
> The javascript application is written using qooxdoo which is a totally
> kickass web gui toolkit.
Indeed! Very beautiful! I didn't know it before and I found it very
interesting! I'm still watching the demos, but how's it to develop with?
How are its docs? And how well does it integrate with MochiKit?
> As I said, I don't know the right way to create controllers. But an
> "add_entry_controller" doesn't make any sense to me. IMHO controllers
> are classes and as such they should be subjects and represent some
> kind of object. "add entry" is more of a verb and sounds like a name I
> would give a method instead.
I follow the same rule. A controller is usually a page or set of pages that
does an operation fully, all CRUD and auxiliary functions.
--
Jorge Godoy <jgo...@gmail.com>
Jorge Vargas
http://groups.google.com/group/turbogears/tree/browse_frm/thread/f53e297c3c3b9a0a/de247b80792170e1?rnum=21&q=jorge.vargas&_done=%2Fgroup%2Fturbogears%2Fbrowse_frm%2Fthread%2Ff53e297c3c3b9a0a%2F50a0be2182451647%3Fq%3Djorge.vargas%26rnum%3D33%26#doc_50a0be2182451647
it seems people forgot about that thread
Kevin Dangoor
>
>
> That seems fair enough. Start small if you like and upgrade when you
> need. Or, as I probably will, start with tgbig to begin with and be
> done with it. :-)
>
> I'm guessing that tgbig doesn't cater for a models directory with
> individual model files currently?
I didn't make that switch at this point because, by convention,
TurboGears model classes are in yourproject.model. I wanted to avoid
breaking other tools (tg-admin sql create, CatWalk, etc).
The controllers change is pretty transparent.
Kevin
just...@ntlworld.com
> I didn't make that switch at this point because, by convention,
> TurboGears model classes are in yourproject.model. I wanted to avoid
> breaking other tools (tg-admin sql create, CatWalk, etc).
Ah right, ok. The way I've rigged my project is to still have a model.py file but it imports models from a models directory. That's how I did controllers too. I still have a controller.py (root) file but it just imports from a controllers directory.
I haven't used 'sql create' or CatWalk so I'm assuming that when I do they'll put stuff into my model.py and I should be ok?
>
> From: "Kevin Dangoor" <dan...@gmail.com>
> Date: 2006/03/23 Thu AM 03:37:33 GMT
> To: turbo...@googlegroups.com
> Subject: [TurboGears] Re: bike shed #2: controllers.py vs. controllers
>
>
-----------------------------------------
Kevin Dangoor
>
>
> > I didn't make that switch at this point because, by convention,
> > TurboGears model classes are in yourproject.model. I wanted to avoid
> > breaking other tools (tg-admin sql create, CatWalk, etc).
>
> Ah right, ok. The way I've rigged my project is to still have a model.py file but it imports models from a models directory. That's how I did controllers too. I still have a controller.py (root) file but it just imports from a controllers directory.
Yes, that should work. You don't need a controller.py file, because TG
looks in yourpackage.controllers for things, which will pick up either
the package or the module called "controllers". (By the way, there's a
reason one is singular and the other is plural: a project will have
many controllers, but the "model" is the data model for the whole
project.)
> I haven't used 'sql create' or CatWalk so I'm assuming that when I do they'll put stuff into my model.py and I should be ok?
They don't actually put things in there. They pull the class
definitions from there. So, importing is *generally* fine there, but
"sql create" skips over imported classes unless you define some extra
variable in model.py (I forget what it is offhand).
Kevin
BJörn Lindqvist
> > which is slightly different. I have been using it to develop a
> > javascript web application for handing job applications. There is only
> > one controllers.py which contain:
>
> Well, I've worked in large teams where bunching several classes into a
> single source file like that would result in a mob lynching. However
> they were C++/Java dev environments and I've been assured that this sort
> of thing is a little more relaxed in Python land.
>
> If your app was to grow and you start adding a few dozen more
> controllers with a lot more functionality per controller then I'd guess
> you'd get a better idea of why separating your controllers might be a
> good idea. You'd find it much easier to locate objects/methods and it
That may be true. If I sometime in the future realise that I all of a
sudden need hundreds (or THOUSANDS) of controllers, then yes, my
little controllers.py file won't work. Luckily for me that hasn't
happened yet but I'm sure it will any day now... :)
More seriously, the KISS rule is applicable - Keep It Simple Stupid.
If an app doesn't need more than one file for storing controllers,
then it shouldn't have more than one file. If you later discover that
you won't be able to manage all controllers in one file, then split em
up. But there is no point in wasting time and effort making your app
more complex if you absolutely don't have to. KISS
> Chances are that you'll get a good idea when your project is becoming
> uncomfortable to handle. Again, my experience is in enivronments where
> these patterns are well recognised and working practices are put into
> place early on to avoid expensive refactorings later. As usual, YMMV.
One of the big selling points about Python is the fact that
refactorings are very cheap. And I don't buy the argument that it
would be easier to structure your code before you have even begun
writing it. Quite the contrary.
--
mvh Björn
BJörn Lindqvist
>
> "BJörn Lindqvist" <bjo...@gmail.com> writes:
> > The javascript application is written using qooxdoo which is a totally
> > kickass web gui toolkit.
> Indeed! Very beautiful! I didn't know it before and I found it very
> interesting! I'm still watching the demos, but how's it to develop with?
> How are its docs? And how well does it integrate with MochiKit?
For me, it is very hard to say anything negative about Qooxdoo. It is
extremely easy to use it to build very professional looking and
featureful applications. If you know Swing or another GUI toolkit like
Qt, it is very easy to learn it because Qooxdoo is like Qt for the
web. You are developing at a very high level so you don't have to deal
with details like DOM elements or stuff like that. That is good for
rapid development but it can also be considered to be negative because
you lose a lot of control on how the page will look.
That's fine for me because I hate writing CSS and having to "design"
stuff. :) The different widget themes that Qooxdoo offers are much
better than any design I could ever come up with. I'm sure there are
also ways to mix "regular" Javascript+HTML with Qooxdoo widgets, but I
have no idea how painful it is.
The docs are pretty bad and are woefully incomplete. I estimate that
only 10% or so of all methods on all classes have any API
documentation. Of those methods, almost none of them are described
with more than one short line. I think this is because the main
developers are Germans and are not so good at English. They could
probably use some help writing good docs. But since Qooxdoo is so
similar in function (and also in how it names stuff) to regular GUI
toolkits that really isn't a big problem. There are also about 150
short examples in the source/demo directory so it's easy to learn by
example.
I haven't tried using it with MochiKit. I don't think there is much
point to that because for much of that MochiKit offers, Qooxdoo has
more high-level equivalents. For example, MochiKit has the funtion
loadJSONDoc, but Qooxdoo has QxGetRequest. And as I previously said,
there is no need to manually manipulate the DOM with Qooxdoo.
But the most amazing thing to me was that my app, exclusively tested
against Galeon, worked without any problems in IE6.
--
mvh Björn
Jorge Godoy
> But the most amazing thing to me was that my app, exclusively tested
> against Galeon, worked without any problems in IE6.
I'll take a look at it later... Who knows I can refactor some stuff
here... :-)
--
Jorge Godoy <jgo...@gmail.com>
just...@ntlworld.com
> One of the big selling points about Python is the fact that
> refactorings are very cheap. And I don't buy the argument that it
> would be easier to structure your code before you have even begun
> writing it. Quite the contrary.
Well, I had a pretty good idea that my project would contain a lot of controllers with a lot of functionality and putting all of that into a single controllers.py would be a bad idea.
I'm very familiar with KISS - it's a big part of my programming philosophy. But it also applies to implementing simple methods to handle complexity. To my mind I've simplified the handling of my complex project. I've Kept It Simple by separating out concerns into manageble units.
I still fail to see how creating a controllers directory suddenly makes things 'complex'.
Never mind. Thankfully Kevin has augmented quickstart to allow initial creation of single or multi controller projects along with automated migration.
Justin
>
> From: "BJörn Lindqvist" <bjo...@gmail.com>
> Date: 2006/03/24 Fri PM 03:52:21 GMT
> To: turbo...@googlegroups.com
> Subject: [TurboGears] Re: bike shed #2: controllers.py vs. controllers
>
>
-----------------------------------------