it's last:
I don't know how to provide order of processing outside middlewares...
i stopped on this:
settings.py:
MIDDLEWARE_CLASSES = (
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
megathanks to all
I will try to use something like:
(r'^members/', include('members.urls'), {'auth':True})
but {'auth':True} will consist of name of handler (handlers)
I'll try to create 1 middleware to process this filters. All handlers
will be called according by its names.
Yes, this is a
Oh, forgot there are also signals that might help.
http://docs.djangoproject.com/en/dev/ref/signals/#module-django.core.signals
:)
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to
Not sure if this would solve the problem, but have a look at
django.utils.ddecorators.decorator_from_middleware.
"""
Given a middleware class (not an instance), returns a view decorator. This
lets you use middleware functionality on a per-view basis.
"""
This also might be best discussed on
Hi Serg,
(replying to the list)
On Thu, Nov 26, 2009 at 4:09 AM, serg wrote:
>
> hmm.. yes. it's almost the same i mean.
> but, all middlewares calls for each request... It's bad (imho).
> also in 99.99% cases it wil be work nice...
> thanks!
>
> This method {'filter_ip':True}
On Wed, Nov 25, 2009 at 11:08 PM, serg wrote:
>
> For example:
you can already do something like this (middleware conditional on
urls) via the view middleware mechanism.
in urls:
...
(r'^members/private/', include('members.private.urls'), {'filter_ip':True}),
...
then the
The request processing can be easy if developers of sites can define
prehandlers and posthandlers for each urls.py (or views.py?).
prehandler: the connection middleware. It calls before request
object was created. Only connection detailes needed for prehandler
processing (no session, no