Beginner questions on writing views
Karen Tracey
database. So for example where it covers writing a detail view for the
Poll model, I think really I'm going to want a detail view for each of
the models in my database, and they're all going to be the same except
for the name of the model and the actual stuff that gets output, which
will be controlled by the model-specific template.
So I come up with a url mapping that looks like this:
urlpatterns = patterns('kmt.crossword.views',
(r'^(?P<model_name>\w+)/(?P<id>\d+)/$', 'detail'),
)
and my views.py is very simple:
from django.db.models import get_model
from django.shortcuts import render_to_response, get_object_or_404
def detail(request, model_name, id):
model = get_model('crossword', model_name)
instance = get_object_or_404(model, pk=id)
return render_to_response(model_name + '_detail.html', {'instance':
instance})
This works nicely, but I have a few niggling questions. First I found
that useful get_model function not in the documentation, but by looking
around in the Django code. Is this something I should be using, or is
it really only intended for Django internal use? If it's not something
I should be using, where should I be looking to figure out how to
accomplish the kind of thing it does for me?
Second, it seems a bit inelegant to hardcode my own app name
('crossword') here. Seems like there should be some way for my
kmt.crossword.views code to figure out that its own app name is
'crossword', but how to do that is eluding me. I'm not quite sure I'm
going to stick with that name so I'd like to minimize the places I have
it hard-coded.
(Finally I know I am ignoring some error cases at the momemt, like if a
url with a non-existant model name comes in. I know I have to deal
with that but right now I'm concentrating on the model names that do
exist.)
Thanks for any feedback -- I'm a complete Python and Django novice so
welcome any and all suggestions as to how I should be approaching this
in the proper manner.
Karen
Don Arbow
>
> I'm working through the tutorial, applying its lessons to my own
> database. So for example where it covers writing a detail view for
> the
> Poll model, I think really I'm going to want a detail view for each of
> the models in my database, and they're all going to be the same except
> for the name of the model and the actual stuff that gets output, which
> will be controlled by the model-specific template.
>
> So I come up with a url mapping that looks like this:
>
> urlpatterns = patterns('kmt.crossword.views',
> (r'^(?P<model_name>\w+)/(?P<id>\d+)/$', 'detail'),
> )
>
> and my views.py is very simple:
You might want to look at generic views. When you write "my views.py
is very simple", that's a cue that a generic view is a good idea.
With a generic view, you can code most of the info in the urls.py
file and eliminate the views.py altogether. When I first came across
generic views, I passed over them thinking I wanted to control all of
my views. Then after coding numerous "simple" views, you start to
wish that there was an easier way - generic views are the answer to
repetitive coding. There are generic views for many mundane tasks.
As for the get_model thing, I don't have a good idea as to how to
deal with that. I am usually not too concerned with decoupling my
templates from my views, so hard coding them is not really a burden.
Don
Karen Tracey
>You might want to look at generic views. When you write "my views.py
>is very simple", that's a cue that a generic view is a good idea.
Ah, there it is right in the next section of the tutorial -- in fact
from a quick glance they seem to use the exact same naming convention
for templates that I came up with. I just hadn't gotten that far yet
because in the tutorial doing something with a form came first and I
didn't want to get involved with forms before trying to get some
basic views working. Thanks for the pointer!
Karen
Malcolm Tredinnick
I don't see a lot of problem with using that function if you really need
to. It exists to provide the functionality you are using it for to the
Django core.
> Second, it seems a bit inelegant to hardcode my own app name
> ('crossword') here. Seems like there should be some way for my
> kmt.crossword.views code to figure out that its own app name is
> 'crossword', but how to do that is eluding me.
With that particular view setup, you could look at the __file__
attribute (every module has one -- try printing it out to see that it's
just a standard file path, so os.path.* can be used to work on it) and
work it out from there (go to the name aboves the 'views/' component).
In general, though, this is an impossible problem based on the
information the view has available to it. Since the view is just a
Python function, it could be located anywhere at all. Multiple
directories down, or in an entirely different part of your filesystem.
So either the view module has to know its position relative to your
application directory (the case at the start of this paragraph), or you
have to pass in the application name to the view somehow. Otherwise it
simply does not have enough information.
You might think "well, my views will always be under the app directory"
and they may well be in this case. However, that's not a universal
truth. For example, as Don pointed out, generic views are useful in some
cases and they live somewhere entirely different. Sometimes you will
write an app that only consists of views and uses models from other
applications (so they present a different outlook on the data). And so
on and so forth.
Regards,
Malcolm