>Great; is decorator_from_middleware implemented or still an idea? I
>can't find it mentioned in the docs.
from django.utils.decorators import decorator_from_middleware
from django.middleware.middlewaremodule import MiddlewareClass
decoratorfunc = decorator_from_middleware(MiddlewareClass)
:-)
# Sure: in those cases you just won't use the "easy-way-out"
# middleware, but just use the "disable-commit-on-save" machinery and
# do explicit commits and rollbacks yourself.
Yeah, that's what I was thinking, but it wasn't yet clear from your
proposal whether it would be easy to toggle between
>You might call those operations "out-of-band" from
>the primary task of the request (like inserting an order into the
>database), so I think that should be considered in the
>implementation. With your proposal, can you illustrate how one >would
>accomplish this?
Sure: in those cases you just wo
# And middleware already has side-effects like changing elements of
# the request object, for example. Or storing stuff in the cache - the
# caching middleware actually would be a much "bigger" middleware than
# the transaction middleware :-)
Ok, good point. (But caching still has more to do wit
>Doesn't this deviate from the standard use of middlewares? The docs
>say, "It's a light, low-level "plugin" system for globally altering
>Django's input and/or output." This sounds like a rather invasive
>exception, and it sounds like something that makes this middleware
>more than a plugin.
I
# So we can't just pass cursors around and let users decide what
# cursor to commit - the commit would have to be on the
# connection. And it would commit all open database changes, even from
# cursors the user didn't really know about.
But *are* cursors being passed around? I guess I'm assuming
# I think the best way to do commits is to tie them to the request by
# using a middleware that does the commit-rollback-handling. Only
# needed change to django would be a process_exception middleware hook
# that is only triggered if the viewfunc throws an exception - to do
# the automatic rollba
Hi,
>> really happy to use it - but we could just switch the storage of
>> translations to storage under Locale names, in t hat case it would
>> just
>> directly work through the magic of gettext.find. The storage would
>> look
>> like this:
>> locale/pt_BR/LC_MESSAGES/django.po
>> locale/de/LC_M
On 12-10-2005, at 8:32, hugo wrote:
Actually no, I am _first_ checking for the full language spec, only if
that fails I am checking for a base language spec. That's needed,
because people might just send a accept-language for de-de, but there
isn't a de-de language available, only a de language
>But my point was that transactions shouldn't *have* to be tied to Web
>requests. We should be able to use transactions outside the scope of a
>Web request -- in, say, a Python script or the interactive
>interpreter. Transactions shouldn't be coupled with any other layers
>of the stack.
Actually
10 matches
Mail list logo
