1 named url per page/screen?

35 views
Skip to first unread message

Malik Rumi

unread,
Sep 25, 2014, 5:43:43 PM9/25/14
to django...@googlegroups.com
1. I am trying to understand the documentation here: https://docs.djangoproject.com/en/1.7/topics/http/urls/#naming-url-patterns

Let us suppose I have a model and folder on mysite called Colors. Within Colors there are several individual documents: blue, green, yellow.

If blue, green, and yellow all use the same view and template, [and they're supposed to, aren't they?]  does this mean each url must be named 'blue' or 'green' or 'yellow' in order for Django to tell them apart?

That's how I'm reading this, but that doesn't make sense to me, because it seems to be about the same as hardcoding the url, and if you have a lot of pages it would be murder to have to do this for every page, and seems contrary to the whole notion of a dynamic web site.  So what am I missing here?



2. I am struggling with this error: 

" Reverse for 'colors_articleView' with arguments '()' and keyword arguments '{u'pk': '', u'slug': ''}' not found. 1 pattern(s) tried: ['colors/(?P<pk>\\d+)/(?P<slug>[\\w]+)'] "

I don't know what I'm missing here. I did a queryset for all the colors in a function based equivalent to list view and didn't see this error, but now that I want individual pages I can't resolve it. 



thx.

Daniel Roseman

unread,
Sep 26, 2014, 10:26:23 AM9/26/14
to django...@googlegroups.com
On Thursday, 25 September 2014 22:43:43 UTC+1, Malik Rumi wrote:
1. I am trying to understand the documentation here: https://docs.djangoproject.com/en/1.7/topics/http/urls/#naming-url-patterns

Let us suppose I have a model and folder on mysite called Colors. Within Colors there are several individual documents: blue, green, yellow.

If blue, green, and yellow all use the same view and template, [and they're supposed to, aren't they?]  does this mean each url must be named 'blue' or 'green' or 'yellow' in order for Django to tell them apart?

That's how I'm reading this, but that doesn't make sense to me, because it seems to be about the same as hardcoding the url, and if you have a lot of pages it would be murder to have to do this for every page, and seems contrary to the whole notion of a dynamic web site.  So what am I missing here?


No, that's not what it means. It means you have one name per URL type: in your case, it would be for "colors", which can then take a parameter "blue" or "green" or whatever - exactly as the example you link to has "arch-summary" with a parameter of the year.
 

2. I am struggling with this error: 

" Reverse for 'colors_articleView' with arguments '()' and keyword arguments '{u'pk': '', u'slug': ''}' not found. 1 pattern(s) tried: ['colors/(?P<pk>\\d+)/(?P<slug>[\\w]+)'] "

I don't know what I'm missing here. I did a queryset for all the colors in a function based equivalent to list view and didn't see this error, but now that I want individual pages I can't resolve it. 

It shows that you are passing blank strings for the pk and slug parameters in the reverse call. Without seeing the code though we can't tell you why.
--
Daniel.

Malik Rumi

unread,
Oct 1, 2014, 4:35:30 PM10/1/14
to django...@googlegroups.com

Ok, thank you Daniel. Your response is reasonable and makes sense, but that clarity is not on the docs page. But this leads me to a related follow up: The need for the parameter, be it 'green' as in my case or '1945' as in the docs, means that each template is going to be tied to a single web page. So instead of hardcoding the url, we are hardcoding the template, meaning it can't be re-used, even if the only difference between it and the copy is 'yellow' instead of 'green'. 

In other words, two documents in the same namespace, with the same view and the same regex/url pattern, can't be reversed unless you include a distinguishing, unique parameter in the url tag. And this unique parameter has to be 'hardcoded', it can't be a variable. That doesn’t make sense to me either. In fact, once I fixed the part about empty strings being passed, and I figured out why I was getting no reverse match, Django was able to decipher the right parameter without me hardcoding it in the url tag, so I completely don’t understand what is going on there. If you’d care to enlighten me, please do.

But I am not out of the woods yet. I posted a new request for help here: https://groups.google.com/forum/#!topic/django-users/fbiVWytyz5w 

. I invite you to share your wisdom.

Daniel Roseman

unread,
Oct 2, 2014, 9:27:52 AM10/2/14
to django...@googlegroups.com
On Wednesday, 1 October 2014 21:35:30 UTC+1, Malik Rumi wrote:

Ok, thank you Daniel. Your response is reasonable and makes sense, but that clarity is not on the docs page. But this leads me to a related follow up: The need for the parameter, be it 'green' as in my case or '1945' as in the docs, means that each template is going to be tied to a single web page. So instead of hardcoding the url, we are hardcoding the template, meaning it can't be re-used, even if the only difference between it and the copy is 'yellow' instead of 'green'. 

In other words, two documents in the same namespace, with the same view and the same regex/url pattern, can't be reversed unless you include a distinguishing, unique parameter in the url tag. And this unique parameter has to be 'hardcoded', it can't be a variable. That doesn’t make sense to me either. In fact, once I fixed the part about empty strings being passed, and I figured out why I was getting no reverse match, Django was able to decipher the right parameter without me hardcoding it in the url tag, so I completely don’t understand what is going on there. If you’d care to enlighten me, please do.

But I am not out of the woods yet. I posted a new request for help here: https://groups.google.com/forum/#!topic/django-users/fbiVWytyz5w 

. I invite you to share your wisdom.


Well, I must confess to being completely puzzled by what you're saying here. Why would you need to hardcode the parameter? Why do you say it can't be a variable? It can, of course: if you had a URL defined as `(r'^color/(?P<color_name>\w+)/$, color_detail, name='color-detail')`, and in your template context a list of strings ['red', 'blue', 'green'], then you could produce a list of links via the URL tag by iterating:

    {% for item in colors %} 
        <li>{% url "color_detail" color_name=item %}</li>
    {% endfor %}

which will produce links pointing to /color/red/, /color/blue/, etc.
--
Daniel.

Malik Rumi

unread,
Oct 2, 2014, 3:16:09 PM10/2/14
to django...@googlegroups.com
Well, as I said, I completely don't understand what is going on here. By my understanding, which is obviously wrong, I should not have been able to resolve the problem as I did. But I really would like to understand, so thank you for helping. 

I think it is a matter of vocabulary, and understanding what is meant or implied by terms. Here's the text from the docs at issue:
***

With these names in place (full-archive and arch-summary), you can target each pattern individually by using its name:

{% url 'arch-summary' 1945 %}
{% url 'full-archive' 2007 %}
***
'Name' in this example is either 'arch-summary' or 'full-archive'. This is referring to the view and the urlconf. The 1945 and 2007 refer to specific years of the archive that are being accessed. But the docs say NOTHING about these additional terms. They are literals, or at least they appear to me to be literals, not variables. That is why I say they are 'hardcoded', (and I concede that may not be the right term in this situation).  Presumably, from this example, there are archives for every year from 1945 thru 2007. So it looks to me like they are saying the only way to get a year-specific page out of the archive is to add the name/unique keyword of that specific page or year. That is why I said what I said, and that is why I interpreted it the way I did. Now that may be wrong, and obviously is, but to my untrained and inexperienced eye, this is the plain meaning of the example. Do you see what I am saying? What would have let me understand it correctly the first time out? Rewriting the docs is one possibility, but maybe understanding some other aspect of Django or Python would have led me to the right conclusion without a rewrite. What would that be?
Reply all
Reply to author
Forward
0 new messages