#9315 closed (fixed)
Keyword arguments with spaces and the url tag
Reported by: | Alexis Bellido | Owned by: | Natalia Bidart |
---|---|---|---|
Component: | Template system | Version: | 1.0 |
Severity: | Keywords: | url, tplrf-fixed, pycamp2009 | |
Cc: | Robert, matiasb | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Hi, I asked about this on the django-users group and was told it was probably a bug so I'm reporting it:
I was testing named url patterns and I have something like this in my URLConf:
url(r'^search/(?P<words>.*)$', 'books.views.search', name='search_page'),
The view is defined like this:
def search(request, words):
Now I'd like to print a link to the search page with certain words from a template and used the url tag like this:
<p>{% url search_page words="someword" %}</p>
When viewing on the browser I get something like '/search/someword', which is good. My question is how do I pass more than one word in the 'words'
parameter?
If I do this:
<p>{% url search_page words="someword otherword" %}</p>
I get this error:
TemplateSyntaxError at (my page name here) Could not parse the remainder: '"someword' from '"someword
Can the url tag handle parameters with spaces?
Attachments (2)
Change History (15)
comment:1 by , 16 years ago
Keywords: | tplrf-fixed added |
---|
comment:2 by , 16 years ago
Cc: | added |
---|
comment:3 by , 16 years ago
milestone: | → 1.1 |
---|---|
Triage Stage: | Unreviewed → Accepted |
comment:4 by , 16 years ago
Keywords: | pycamp2009 added |
---|---|
Owner: | changed from | to
Status: | new → assigned |
by , 16 years ago
Attachment: | patch-9315.diff added |
---|
comment:5 by , 16 years ago
Has patch: | set |
---|
Added patch to solve this issue. Fixed involved debugging and improvments of the smart_split
from [browser:/django/util/text.py], plus a simplification of split_contents
at [browser:django/template/__init__.py].
All tests passes except for test_templates (regressiontests.templates.tests.Templates)
which was already failing.
Made by nessita (Natalia Bidart) and matiasb (Matías Bordese, not registered yet).
Contributors understanding regexs: Ramiro Morales, Facundo Batista, Pablo Ziliani, John Lenton.
comment:6 by , 16 years ago
Last night, while being unable to sleep, I figured out that the non-greedy part of the proposed regular expression (in teh pacth attached) can be changed to a greedy expression, improving the performance of it.
So, where it reads:
smart_split_re = re.compile(r"""(\S*?"(?:[^"\\]*(?:\\.[^"\\]*)*)"\S*| # matches '"value with spaces"' and 'keyword="value with spaces"' \S*?'(?:[^'\\]*(?:\\.[^'\\]*)*)'\S*| # same as above but with quotes swapped \S+) # matches not whitespaces""", re.VERBOSE)
the \S+?"
can be changed to [^\s"]"
(same for the '
character). I'll submit a new patch in a while, prior some checkings.
comment:7 by , 16 years ago
Cc: | added |
---|
comment:8 by , 16 years ago
Attaching new patch with greedy regular expression (to avoid backtracking).
by , 16 years ago
Attachment: | patch-9315-regex-greedy.diff added |
---|
comment:9 by , 16 years ago
I'm not going to apply the changes to the split_contents()
portion, since they don't appear to fix an existing problem I'm not convinced they don't introduce a bug. We should fix on problem per ticket.
If somebody wants to fix up that portion (and if it can be reduced to one line, that would be great), the patch should include test of the i18n pieces in that function. It's clearly looking at _("...")
strings, but I don't see anything in the replacement code that handles that. It might well be being handled elsewhere automatically (so we're doing it twice now) and that will be demonstrated by the tests in the new ticket and patch.
comment:10 by , 16 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:11 by , 16 years ago
comment:12 by , 16 years ago
Malcom,
you're welcome! We had the most fun proposing a solution for this one. We would love to keep contributing to the django project.
This would be fixed by #7806.