bike shed #2: controllers.py vs. controllers directory
Kevin Dangoor
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?
Kevin
--
Kevin Dangoor
Author of the Zesty News RSS newsreader
email: k...@blazingthings.com
company: http://www.BlazingThings.com
blog: http://www.BlueSkyOnMars.com
Mike Pirnat
models. This gives a symmetry to the layout of controllers, models,
and templates that (at least to me) seems pleasant.
--
Mike Pirnat
mpi...@gmail.com
http://www.pirnat.com/
Justin Johnson
I'd go for setting up a controllers and models directory/package from
the start. It's initially convenient but not particularly good practice
to have them in one source file each.
Considering that the ideal is to support MVC paradigm, it would make
sense to have Model, View and Controller packages with separate source
files for each component.
Quick look over the fence never hurts:
http://www.ilovejackdaniels.com/ruby_on_rails_cheat_sheet.png
;-)
Karl Guertin
> 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.
Michele Cella
> +1 for a controllers directory/package, and +1 for doing the same with
> models. This gives a symmetry to the layout of controllers, models,
> and templates that (at least to me) seems pleasant.
>
+1.
That's the first question I asked on this group back on October (IIRC).
:-)
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.
IMHO good conventions are really helful to easily learn the best
practise you should use to manage a project and it's layout while it
grows up.
Ciao
Michele
Jorge Godoy
> 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?
Hmmm... I prefer importing. For both cases.
--
Jorge Godoy <jgo...@gmail.com>
Justin Johnson
The only difference would be the model.py would move to a models
directory and controller.py would move to controller directory. At
least that way it can scale and encourages good practice for newcomers.
Karl Guertin
> The only difference would be the model.py would move to a models
> directory and controller.py would move to controller directory. At
> least that way it can scale and encourages good practice for newcomers.
http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING
Preference is preference. I'm not about to argue the point.
Jorge Godoy
> The only difference would be the model.py would move to a models
> directory and controller.py would move to controller directory. At
> least that way it can scale and encourages good practice for newcomers.
The other difference is that you won't be able to start writing your code and
only "importing" it when you won't crash the app. Or you'd have to start
creating "conventions" to avoid importing some new file that you've just
created (if we have to edit __init__.py or something else to import, then I
don't see any advantage over editing controllers.py to import the new
file...).
This will happen for both model and controllers...
--
Jorge Godoy <jgo...@gmail.com>
Michele Cella
Yeah, that's the pure bikeshed spirit, moreover this one is officially
blessed by the boss. :D
Funny...
Ciao
Michele
BJörn Lindqvist
have never needed more than one controllers.py and model.py. Longer
paths are to me more inconveniencing and complicating for no good
reason. KISS
--
mvh Björn
Ian Bicking
> 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.
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.
--
Ian Bicking / ia...@colorstudy.com / http://blog.ianbicking.org
Travis Bradshaw
TurboGears users are new or unfamiliar with developing large Python
applications. I think this is especially true for those potential
users that would use TurboGears for an enterprise level replacement for
established web development technologies (they are unlikely to be
programming in Python much because they are busy with j2ee, or php, or
whatever).
The default layout for the quickstart project is a "deadend" without
scalability. It provides a containing wall that requires a developer
to stop developing and start learning Python package symantics from
another source in order to continue.
I think that the quickstart application should provide a scalable
starting point to form as the "roots" of a well "grown" large scale
application. When it comes time to start breaking code into extra
modules and packages, the developer should be able to look to the
quickstart as an example of how to do just that.
The old adage is that "great code is self documenting". If the
quickstart for TurboGears can be a ideal example of how to modularize
your TurboGears application for scalability, I think it will be all the
better off for it.
(As a aside, if someone wants to see a "simpler" version of a
TurboGears application, they can always download a sample application
from the documentation that is a finished, small application)
Travis Bradshaw
c.travis...@gmail.com
Mike Orr
It's not just a preference; it's about TG being scalable out of the
box. Quickstart provides a 'static/' directory that's suitable for
all but the most pedantic applications. Why not the same for
controllers and models? Small applications will find
controllers/__init__.py a very minor inconvenience. Large
applications require it.
--
Mike Orr <slugg...@gmail.com>
(m...@oz.net address is semi-reliable)
Jeff Marshall
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.
On a tangent: another thing I always do is modify the setup.py's
find_package_data to (where='.', package=''). The reason being that I
have a "shared" directory that I link in to every TG project at the top
level of the project, and I want it to get picked up when I build the
egg. I suppose my other option is to build and release my shared
library as an egg and set the version number dependency in my setup.py?
Another tangent: another thing I always do is move the app version out
of the setup.py and put it in my projectdir/__init__.py so I can do
this in myproject-start.py:
def add_custom_variables(variables):
variables['app_version'] = myproject.__version__
turbogears.view.variableProviders.append(add_custom_variables)
I do this because I want my application's version number available to
my templates for appending at the end of each .js and .css inclusion.
Jeff Marshall
mars...@frozenbear.com
Ben Bangert
> On a tangent: another thing I always do is modify the setup.py's
> find_package_data to (where='.', package=''). The reason being that I
> have a "shared" directory that I link in to every TG project at the top
> level of the project, and I want it to get picked up when I build the
> egg. I suppose my other option is to build and release my shared
> library as an egg and set the version number dependency in my setup.py?
setuptools 06a9 I believe added support for the:
include_package_data=True,
option. It will automatically include all the package data in your
project thats under either CVS or SVN version control. I've found it
rather nice. :)
> Another tangent: another thing I always do is move the app version out
> of the setup.py and put it in my projectdir/__init__.py so I can do
> this in myproject-start.py:
> def add_custom_variables(variables):
> variables['app_version'] = myproject.__version__
> turbogears.view.variableProviders.append(add_custom_variables)
> I do this because I want my application's version number available to
> my templates for appending at the end of each .js and .css inclusion.
I actually got stung bad by this earlier for the following reason. If
you setup.py indicates you require certain dependencies, perhaps your
project needs package XXX. Then your setup.py goes and includes the
version from your project/__init__.py, and your __init__.py also
happens to import some stuff that imports some stuff that imports
package XXX. It's quite likely package XXX wasn't installed yet, and
the process will die as such, because setuptools hasn't had the chance
to install dependencies. It was still busy pulling your version
number...
Some thoughts. :)
- Ben
Michele Cella
> 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
Richard (koorb)
Simon Belak
> 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
Jorge Godoy
That's what I think as well... "Keep simple things simple and complex things
possible"... Who will be starting a huge application will know how to create
a new structure -- or will be able to ask on the mailing list.
A lot of us have several controllers but importing them is no different from
having them on a specific directory (you can have your directory the same way
if you wish)... So...
--
Jorge Godoy <jgo...@gmail.com>
Kevin Dangoor
>
> +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
gasolin
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)
Jonathan LaCour
> 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?
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
Jason Chu
I'm just going to throw my 2 cents in right here.
We're trying to build a semi-large application with turbogears and still
only have a controllers.py file. The reason is because we have seperate
directories with models, controllers, and widgets for each of the sections
of the application.
We did end up having a model directory, but that was only because I wanted
to have a project.model.helper package. It was a very simple change, so I
don't see the need for a model directory either.
I think they should both stay files.
Jason
--
If you understand, things are just as they are. If you do not understand,
things are just as they are.
Michele Cella
> I'm just going to throw my 2 cents in right here.
>
> We're trying to build a semi-large application with turbogears and still
> only have a controllers.py file. The reason is because we have seperate
> directories with models, controllers, and widgets for each of the sections
> of the application.
>
Yep, that's a very interesting point of view, I think we can find a
good balance and provide a quickstart command to add a new application
section (as asked before by Dan Jacob) in the way you're doing it.
I like this, it's still a convention, but a less obtrusive one, yes
it's different from others (like RoR that uses a global controllers
dir) but not for that reason worse.
We need to find the right convention that fits with the way TG works
(not what the other are doing) and I like this one personally (it seems
to also fit nicely with "firstclass" and WSGI concept of apps) since it
gives you a section and re-usability inclination.
Thanks Jason.
Ciao
Michele
Jorge Vargas
1- quickstart will stay as if
2- <insert name here>, this one will ask
you want a controllers package? [default: no]
you want a model package? [default: no]
3- <expand> a quickstart
>>>migrating controller.py to ./controllers/controller.py
>>>migrating model.py to ./models/model.py
If you think of it a little bit the changes in quickstart code are small
check the input, create the dir change to that dir.
and since we have to import if it's on a package or not there is nothing else for TG to do.
ohh yea and create the __init__.py file which is trivial.
qvx
SQL (via ODBC) and 1 Oracle. To me, separate directory is clearly the
winner.
However, since I have to connect to databases not supported by
SQLObject (each database is using different convention for primary keys
which is reason enough not to use SQLObject) I'm using combination of
techniques (experimenting with SQLAlchemy among others). I guess it
wouldn't have helped me even if quickstart created models directory for
me.
Just my 2 cents.
Tvrtko