Re: 1 named url per page/screen?

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?

On Thursday, October 2, 2014 8:27:52 AM UTC-5, Daniel Roseman wrote:

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.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/d9557444-ed8b-48d4-8fce-8ec8778b8d59%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.