On 3/18/06, James Bennett <[EMAIL PROTECTED]> wrote:
> 1. The new example of usage for a generic view is counterintuitive;
> now we pass a QuerySet instead of the app_label/module_name, which is
> fine, but the example on the wiki is:
>
> from myproject.blog.models import Entry
> info_dict = {'queryset': Entry.objects.all()}
>
> This is confusing to someone who's not familiar with how magic-removal
> works, because that makes it look like every hit to a generic view
> fetches all objects of that class from the database -- even if the
> generic view is, say, object_detail. It doesn't, of course, because
> all() simply instantiates a QuerySet, but that's counterintuitive and
> scary and you have to go read the code to figure it out. We really
> need either a better example, a better way of getting the QuerySet, or
> both.
I think good documentation is the best way to solve this one.
> 2. That example also couples the application to the project;
> previously the magic in Django meant we didn't need to have the full
> dotted path to the model class, but now there doesn't seem to be any
> way around it. Still, that's bound to have an effect on application
> portability. How can that be worked around?
Assuming the URLconf is in a file "urls.py" and the models are in a
file "models.py" in the same directory, you can just do this:
from models import Entry
That's one of the nice things about magic-removal: All the stuff is in
the same Python package, so a developer can use relative imports in
URLconfs and views.
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" 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-developers
-~----------~----~----~----~------~----~------~--~---
