Ian Holsman wrote:
> If I'm understanding your question correctly, you could write a function
> similar to gen_pop_pattern (http://svn.zyons.python-hosting.com/trunk/
> zilbo/common/counter/urls.py )
Actually, I'm already doing something very similar. This is what my
main (entry point) urls.py looks like:
------------------
from django.conf.urls.defaults import *
from django.conf import settings
from models import Node
def pattern_line(n):
return ('^%s' % n.get_absolute_url()[1:],
include(n.application.name + '.urls'), {'node': n})
args = ['', (r'^admin/', include('django.contrib.admin.urls'))]
args.extend([pattern_line(n)
for n in
Node.objects.filter(application__isnull=False)
if n.application.name in settings.INSTALLED_APPS])
urlpatterns = patterns(*args)
------------------
I'm basically building urlconf dynamically from objects of a model
called Node. I'm also passing the node object with the matching url to
app specific urlconf.
So you can immagine that the above code might end up in routes looking
something like this:
'/community/weblog/', include('apps.weblog'), {'node':
community_weblog_node}
'/dev/weblog/', include('apps.weblog'), {'node': dev_weblog_node}
'/dev/null/', include('apps.contact'), {'node': dev_null_node}
So the point is obviously that I have two url's pointing to the same
app. At the same time, I'm passing that specific node as an extra
option to the included urlconf.
The idea is to make it easy to create Django applications that are
"node-aware", just like Django applications that are aware of the sites
framework allowing them to be easily doing such a thing.
The problem is that the only way to achieve something similar currently
is to have each and every view of the application accept a node
parameter. Which is not the optimal approach, because if it is, then
maybe we should change the sites framework to behave like this.
If it was possible to figure out the current node from the model code,
then I can make a cool CurrentNodeManipulator (basically, a
CurrentSiteManipulator rip off). If it was at least possible to get the
node in the application specific URLconf then I could at least filter
the queryset by that node before passing it to the views. But none of
this is currently possible.
[EMAIL PROTECTED] wrote:
> Ahmad, do you perhaps mean something like this?
>
>
> ## URLconf (main)
>
> (r'^(?P<language>[a-z]{2})/section/', include('myproject.myapp.urls')),
>
>
> ## URLconf (myapp)
>
> ...
> some logic that depends on <language>
> ...
>
> (r'^list/?$', 'django.views.generic.list_detail.object_list',
> dict(info_dict)),
>
>
>
> I don't know a solution, I merely presume to be facing a similar
> problem.
>
> If this is not what you meant, maybe someone can give me a hand on the
> above scenario.
Yes, that's exactly my problem. The problem I'm having is that I'm
trying to pass an object, you are tying to pass a language, in another
scenario I was trying to pass the user, and other people were
complaining of similar problems.
Todd O'Bryan wrote:
>
> On the other hand, I'm thinking you might be better off putting all
> these things you want to do in a helper function and just calling it
> at the beginning of each view that needs it. Seems explicit,
> uncomplicated, modular, and [insert your favorite buzzword here].
There are a couple of problems here in this method:
1. I have to do it in every view of my application, which is un-DRY and
un-Pythonic in my opinion. Immagine opening a views.py file to find a
line being repeated at the top of each and every view.
2. It makes the interface to views awkward. Generic views and others
are already taking a QuerySet. It doesn't feel natural to send an
additional seperate object for the first line in every view of the
application to be applying an extra filter to that passed QuerySet
using that seperate object?
It is much more natural for the view to just take that QuerySet already
filtered.
3. It will make it harder to port regular Django applications to make
use of the extra features of my project.
4. It is not the optimal solution because if it was, it would have been
the solution used in the sites framework.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
