On Mar 5, 12:56 pm, adrian <[email protected]> wrote:
> I've had some problems with reverse and have some questions and
> thoughts:
>
> 1. When I add a view and a corresponding entry in urls,py, sometimes I
> get a reverse error until I stop the dev server and restart it, even
> though nothing is wrong with either file. Is there an order in which
> those changes should be made that guarantees this won't happen?
>
> 2. The doc says templates are intended to be editable by designers/non-
> programmers. But any {% url view arg %} tag that is not 100% correct
> (both view and arg) will bring down that page, not just cause a broken
> link.
> The error message usually points to the first {% url %} tag, which may
> be in a base template not in the template that actually contains the
> error.
This is true and many people have commented on this. The alternative
I have seen is to use the old style, obj.get_absolute_url() and just
put a reverse() inside there. I think that is the best offer django
currently has.
>
> 3. The details given in the error messages for reverse are very
> misleading. The error is almost always elsewhere and the arguments
> are usually irrelevant. It is not good policy to imply a specific
> error location when the error system has no idea where the problem
> is.
I've also noticed that errors originating in templates are difficult
to decipher. I think {% url %} is a case where this problem becomes
very evident since all your urls should use it. I'm not sure what
django 1.1 has in store, but I know many people have complained about
this.
>
> 4. One improvement would be something (in the dev server?) that does
> some basic comparison of urls.py and views. Django has access to
> all the URL patterns and all the views modules, so couldn't it compare
> the views in one to the views in the other and warn you if there is a
> mismatch? This would not require reversing the Regexes, just making
> sure the view functions referenced in urls.py are all present in
> views. That would localize one source of reverse errors.
Not sure what this would achieve. If you have a urls.py pattern that
points to a non existent view the error is pretty clear when you try
to browse to that page. I think the real solution for this is to
write tests for every view you expect to exist. So I think it is a
testing framework solution rather than a default "dry-run" django
should do all the time. There is a django app that exists to
facilitate this type of automatic test "scaffolding" you might call
it. But it is a separate app, which I think is good.
http://ericholscher.com/projects/django-test-utils/
>
> 5. If the checking specified in #4 finds no errors, wouldn't that
> mean the error must be in the template? At that point, would it be
> possible to localize {% url %} tag errors to show the context of the
> error? If the template loader combines base templates with sub-
> templates, then the line number is of limited use so the context would
> be more useful.
This would be ideal, I imagine folks are working on this. If not then
you might want to print this up on django-dev.
>
> I understand this is a difficult problem, but I've found this
> frustrating and believe
> it could be improved.
>
> I'm running 1.0.2 and if this have been improved already, then great.
I second this ...
--
Milan
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to [email protected]
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
-~----------~----~----~----~------~----~------~--~---
