Re: Url resolver issues
The regular expression was incorrect (sorry i was half drunk at the
time of doing it), it is:
url(r'^approved/(((?P[a-zA-Z ,-]+)/)?)(((?P
[0-9]+)/)?)$', views.get_approved_images, image_info,
name='approved'),
I think it is a much nicer solution to only require one url pattern
for use in the templates. However, as there seems to be no option to
resolve the URL i have no choice.
On Sep 25, 4:37 pm, Michael <newmani...@gmail.com> wrote:
> On Fri, Sep 25, 2009 at 11:22 AM, Lewis Taylor
> <lewisctay...@googlemail.com>wrote:
>
>
>
>
>
> > I should have also noted all url resolves fail, not just with no
> > arguments.
>
> > On Sep 25, 4:11 pm, Lewis Taylor <lewisctay...@googlemail.com> wrote:
> > > Here it goes:
>
> > > I wanted a clean url structure so i tried to abstract as much as i
> > > could in one url pattern. it looks something like this:
>
> > > url(r'^approved/((?P[a-zA-Z ,-]+)?)(/?)((?P[0-9]+)?)(/?)
> > > $', get_approved_images, name='approved_images')
>
> > > this in theory should allow the return of
> > > 1) all images - /approved/
> > > 2) pagination options for all images - /approved/2/
> > > 3) images from a specific country - /approved/china/
> > > 4) pagination for countries - /approved/china/3/
>
> > > this works fine, but when trying to resolve the url with no page or
> > > country there are problems i.e.
>
> > > {% url approved_images %}
>
> > > i thought as there can be 0 or 1 of both country and page as specified
> > > in the url pattern there shouldn't be a problem, however it doesn't
> > > seem that way. I haven't looked inside the code as i have higher
> > > priority things to do at present, but if anyone could help with a
> > > solution or a reason why it doesn't work that would be appreciated, if
> > > not i suggest a patch as it makes sense that allowing url's to match a
> > > particular pattern should also mean that any url that matches that
> > > pattern should be resolvable :-)
>
> This feels like a how to question to me, so it might be better to take this
> onto django-users.
>
> If you are proposing that the urlresolver should be able to reverse this, I
> won't weigh in on the technical problems that might exist and just ask you:
>
> Do you really think this is easier than setting up different url patterns
> for each of the different views? I know it means 3 more lines of code, but
> that regular expression is a beast, that can't be easy for readability.
>
> On top of this these urls will also resolve for you: /approved2/,
> /approvedchina3/, /approved. This means you have multiple urls for the same
> resource. A major no no for SEO and just for content in general. Also if the
> urlresolvers were to work, which way would they work?
>
> This really kills the explicitness of the code, as well as the readiblity;
> we all are not regex masters. I think 3 different urlpatterns is much
> better. You can still reuse the view and have different names and it will
> work as advertised.
>
> Just my thoughts,
>
> Michael
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Url resolver issues
I should have also noted all url resolves fail, not just with no
arguments.
On Sep 25, 4:11 pm, Lewis Taylor <lewisctay...@googlemail.com> wrote:
> Here it goes:
>
> I wanted a clean url structure so i tried to abstract as much as i
> could in one url pattern. it looks something like this:
>
> url(r'^approved/((?P[a-zA-Z ,-]+)?)(/?)((?P[0-9]+)?)(/?)
> $', get_approved_images, name='approved_images')
>
> this in theory should allow the return of
> 1) all images - /approved/
> 2) pagination options for all images - /approved/2/
> 3) images from a specific country - /approved/china/
> 4) pagination for countries - /approved/china/3/
>
> this works fine, but when trying to resolve the url with no page or
> country there are problems i.e.
>
> {% url approved_images %}
>
> i thought as there can be 0 or 1 of both country and page as specified
> in the url pattern there shouldn't be a problem, however it doesn't
> seem that way. I haven't looked inside the code as i have higher
> priority things to do at present, but if anyone could help with a
> solution or a reason why it doesn't work that would be appreciated, if
> not i suggest a patch as it makes sense that allowing url's to match a
> particular pattern should also mean that any url that matches that
> pattern should be resolvable :-)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Url resolver issues
Here it goes:
I wanted a clean url structure so i tried to abstract as much as i
could in one url pattern. it looks something like this:
url(r'^approved/((?P[a-zA-Z ,-]+)?)(/?)((?P[0-9]+)?)(/?)
$', get_approved_images, name='approved_images')
this in theory should allow the return of
1) all images - /approved/
2) pagination options for all images - /approved/2/
3) images from a specific country - /approved/china/
4) pagination for countries - /approved/china/3/
this works fine, but when trying to resolve the url with no page or
country there are problems i.e.
{% url approved_images %}
i thought as there can be 0 or 1 of both country and page as specified
in the url pattern there shouldn't be a problem, however it doesn't
seem that way. I haven't looked inside the code as i have higher
priority things to do at present, but if anyone could help with a
solution or a reason why it doesn't work that would be appreciated, if
not i suggest a patch as it makes sense that allowing url's to match a
particular pattern should also mean that any url that matches that
pattern should be resolvable :-)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Translation problem in from django.utils.translation.trans_real : get_language_from_request()
I'm not sure if this has been discussed before, my guess is yes, however i can't find anything about it. I noticed that the get_language_from_request method in trans_real only checks whether the django.mo file for a given locale is available in the django locale directory, and not an app or projects locale folders. To me this doesn't make sense, it's not acceptable to have to create a language folder in the django conf/locale directory just to make django work. If no folder exists there, it will revert back to settings.LANGUAGE_CODE. Does anyone have any particular reason why this approach has been chosen? Thanks Lewis --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
