I think you've kind of missed my point as there's not a view that can render
any object - but rather the name of the view is in the url.
This is the url conf for a typical rails app.
map.connect '', :controller => "public"
# Install the default route as the lowest priority.
map.connect ':controller/:action/:id.:format'
map.connect ':controller/:action/:id'
That is the whole thing. Controllers are analogous to applications in django,
actions are like view functions, id is typically the primary key of the object
being viewed. format is new and could be .json, .xml, .html..... I don't
really use it just now.
I see no reason ever to specify a more elaborate url. I want the equivalent
setup in my urls.py and then I never want to open that file again - relying
entirely on naming convention rather than configuration.
You've kind of pointed me in the right direction though. After a day of
hacking about I ended up with:
urlpatterns += patterns('',
(r'^(?P<app>[^/]+)/(?P<view>[^/]+)/(?P<id>[^/]+)\.(?P<format>[^/]+)',dispatch_request),
(r'^(?P<app>[^/]+)/(?P<view>[^/]+)/(?P<id>[^/]+)',dispatch_request),
(r'^(?P<app>[^/]+)/(?P<view>[^/]+)\.(?P<format>[^/]+)',dispatch_request),
(r'^(?P<app>[^/]+)/(?P<view>[^/]+)',dispatch_request),
(r'^(?P<app>[^/]+)\.(?P<format>[^/]+)',dispatch_request),
(r'^(?P<app>[^/]+)',dispatch_request),
)
def dispatch_request(request, app, view='index', id=None, format='html'):
"""
Implements Ruby on Rails 'Convention over Configuration' Policy
Along with rules in urls.py, implements urls of type
/application/view/id.format
which is analogous to Rails's
/controller/action/id.format
"""
view_module = None
view_function = None
# if debug, let the exceptions fly - otherwise make them 404's
# try to import the application module, then lookup the view function in it
if settings.DEBUG:
view_module = __import__(app+'.views', globals(), locals(), [ view ],
-1)
view_function = (view_module.__getattribute__(view))
else:
try:
view_module = __import__(app+'.views', globals(), locals(), [ view
], -1)
view_function = (view_module.__getattribute__(view))
except ImportError:
raise Http404
# make the GET mutable and stick format and id on it if non-nil
if request.GET:
request.GET = request.GET.copy()
else:
request.GET = QueryDict('').copy()
request.GET.__setitem__('format',format)
if id:
request.GET.__setitem__('id',id)
# call the view function
result = view_function(request)
# if the view didn't render anything, lookup the template by convention and
render it
if result == None:
result = render_to_response(app+'/'+view+'.'+format,{'app': app,
'view': view , 'id': id, 'format':
format},context_instance=RequestContext(request))
return result
and this gives me most of the convention of rails. No more fiddling urls.py.
The only improvement would be to make the functions in views.py methods on an
object (the "controller") and bind its ivars into the request when rendering
the template.
On Nov 25, 2009, at 11:36 AM, Tim Valenta wrote:
> I usually don't find myself writing too many redundant views, since
> the built-in admin site does so much of that automatically. Then I
> just build views specific to the site's public UI. I still find it
> curious that you would find yourself recreating said urls. I run a
> company database through the admin and three urls and three views.
> There should only have to be one url pattern defined per model, plus
> any extra views for looking at that one model. I don't mean to
> belittle what it is you're doing, but I can't say that I can identify
> very well. How many of your models have exactly the same set of
> views? My tendency is to think that those should be caught through
> some keyword captures.
>
> There are, however, generic views (http://docs.djangoproject.com/en/
> dev/ref/generic-views/) which might help. You might look at it and
> not think that it is as easy to use as you might like, but they are
> quite good for automatically handling dates in URLs, etc.
>
> I can't explain too much about generic views, as I haven't had to use
> them much. I'm totally not an authority on that end.
>
> If they don't really work out, you could always write a url which
> captures each of those three things as keyword arguments:
>
> urlpatterns = patterns('',
> (r'^(?P<app>[^/]+)/(?P<view>[^/]+)/(?P<id>\d+)/',
> 'magic_view_handler'),
> )
>
> "magic_view_handler" would then be a view that gets called, whose
> signature looks something like:
>
> magic_view_handler(request, app, view, id):
> view_function = None
> try:
> view_function = import('%s.%s' % (app, view))
> except ImportError:
> raise Http404
> view_function(request, id)
>
> It'd then be up to your *real* view to check to ensure that the id is
> legit.
>
> I forget precise syntax on that import() function. I don't use it
> often. The idea is to import a dynamic module based on some string
> you've got handy.
>
> I think that the reason why this latter suggestion doesn't have a
> reason to exist is because you've always got to validate all sorts of
> stuff very specific to the model. By making one generic view, you're
> bound to never really allowing yourself any custom processing. You'd
> always be passing your variably-defined model to the same template.
> How could the same template render entirely different models to the
> page?
>
> Anyway, "sticky" the word for it, at best. I'm totally curious, so
> could I ask that you give an example of your url conf? If feels like
> there might be something missing that could simplify your task.
>
> Tim
>
> On Nov 25, 12:07 pm, Todd Blanchard <tblanch...@mac.com> wrote:
>> It is mostly a waste of time and busy work.
>>
>> I like the rails strategy of /controller/action/id
>>
>> I'd like to define a similar one time couple rules in urls.py
>>
>> Something like /application/view/id where view is the name of the function
>> in the views.py in that application.
>>
>> Anybody got a little snippet or recipe to do this generically once and for
>> all?
>>
>> -Todd Blanchard
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
