On Aug 13, 2006, at 9:13 AM, Karen Tracey wrote:
>
> 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
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users
-~----------~----~----~----~------~----~------~--~---
