Re: @url tag - getting rid of urlpatterns
On Aug 30, 3:08 am, Ilya Semenov <[EMAIL PROTECTED]> wrote:
> Second, I think the use of generic views is over-estimated.
I tend to agree a bit here. I like having all my URLs in one file and
all my views in another. Using generic views usually clutters the
urls file too much for me. Generic views usually don't save enough
code to be worth it in my experience, it just moves the code to a
different place. Also, if I ever wanted to change the view up to do
more custom things, I would have to undue the generic view setup and
create a regular view anyway, so why not just do that in the first
place.
> > 2. One of the best things (again, in my opinion) of urls.py is that it
> > shows whole user interface of an app in one place. You loose this
> > feature with decorators scattered all over views.
Yes, I think this is a very nice thing about having a file dedicated
to url conf. It give you a nice summary of what the application does
and how it's organized. I would not like having to scan through all
my views to figure out the URL structure.
> While I see the rationale in your words, that position is very
> arguable.
>
> Encapsulation is one of the greatest programming principles. From the
> architectural point of view, the app-level urls.py shouldn't bother
> what members area urls are there in members module, since it can
> safely delegate the responsibility to manage the list of members urls
> and just pull the data when needed.
Isn't this what include() is for:
(r'^members/', include('myapp.members'))
All the members URLs can be encapsulated in the members module.
Gary
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Re: @url tag - getting rid of urlpatterns
Ilya Semenov wrote:
> Second, I think the use of generic views is over-estimated. Generic
> views do not even support access restrictions (@user_passes_test) and
> thus are most of the time proxied via custom one-line views.
Actually they support decoration perfectly well, right in urls.py:
from django.views.generic.list_detail import object_detail
from some_decorators import decorator
urlpatterns = patterns('',
(r'...', decorator(object_detail), { ... }),
)
Though I agree that generic views require some time get used to...
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Re: @url tag - getting rid of urlpatterns
On 30 авг, 12:08, Ilya Semenov <[EMAIL PROTECTED]> wrote: > Second, I think the use of generic views is over-estimated. Generic > views do not even support access restrictions (@user_passes_test) and > thus are most of the time proxied via custom one-line views. Look at this: http://www.djangoproject.com/documentation/url_dispatch/#passing-callable-objects-instead-of-strings You can wrap even generic views with decorator --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: @url tag - getting rid of urlpatterns
Ivan,
Thanks for reviewing the snippet.
> While the decorator looks nice it creates in my opinion at least as many
> problems as it solves.
>
> 1. You can apply decorators only to custom views, not to generic views.
> And as generic views are commonly used one still should keep a separate
> urls.py for them.
First of all, the decorator is fully optional. It doesn't replace
urlpatterns, it gently appends to them. There's nothing wrong in
writing:
urlpatterns = urlpatterns('',
('^news/$', 'django.views.generic.object_list',
{'queryset':..})
)
@url('^edit_news/$')
def edit_news(request):
Second, I think the use of generic views is over-estimated. Generic
views do not even support access restrictions (@user_passes_test) and
thus are most of the time proxied via custom one-line views.
> 2. One of the best things (again, in my opinion) of urls.py is that it
> shows whole user interface of an app in one place. You loose this
> feature with decorators scattered all over views.
While I see the rationale in your words, that position is very
arguable.
Encapsulation is one of the greatest programming principles. From the
architectural point of view, the app-level urls.py shouldn't bother
what members area urls are there in members module, since it can
safely delegate the responsibility to manage the list of members urls
and just pull the data when needed.
> BTW, do you know that you can use function objects instead of their
> names in url definition? So this:
>
> urlpatterns = patterns(__name__,
> (r'^index/$', 'index'),
>
> becomes just:
>
> urlpatterns = patterns('',
> (r'^index/$', index),
Sure, that way it is more natural. Alas, that won't work, since index
function is defined later in the module code. Alternatively, one
should put urlpatterns to the very end of the module file, which just
doesn't feel right to me.
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Re: @url tag - getting rid of urlpatterns
Ilya Semenov wrote:
> === apps/app1/views/__init__.py ===
> @url(r'^index/$')
> def index(request):
> ...
>
> @url(r'^news/$')
> def news(request):
While the decorator looks nice it creates in my opinion at least as many
problems as it solves.
1. You can apply decorators only to custom views, not to generic views.
And as generic views are commonly used one still should keep a separate
urls.py for them.
2. One of the best things (again, in my opinion) of urls.py is that it
shows whole user interface of an app in one place. You loose this
feature with decorators scattered all over views.
BTW, do you know that you can use function objects instead of their
names in url definition? So this:
urlpatterns = patterns(__name__,
(r'^index/$', 'index'),
becomes just:
urlpatterns = patterns('',
(r'^index/$', index),
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
