Hi,
Could one of the core devs take a look over #10899 and give some
guidance on what the best step to take next is? Thanks.
Preston
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to
Hi,
Russell, thanks for having a look at this. Much appreciated!
On Mon, Oct 25, 2010 at 4:04 PM, Russell Keith-Magee
wrote:
> Responding so that
>
> "localize off" is a much better approach to localize
>
> 1) I think there is still a need for a template filter.
Hi Christophe, Jacob and all,
On Saturday 23 October 2010, Christophe Pettus wrote:
> On Oct 22, 2010, at 4:01 PM, Jacob Kaplan-Moss wrote:
> > It's a bug: http://code.djangoproject.com/ticket/9964.
> >
> > Looks like the patch there is OK, but still needs some work (there's a
> > couple of
I propose the following solution for middleware problem:
1. Introduce the BakingMiddleware
(django.template.response.BakingMiddleware or
django.template.middleware.BakingMiddleware?). This middleware bakes
the response using .bake() method.
2. Put this middleware as last middleware in default
On Oct 25, 4:28 pm, Russell Keith-Magee
wrote:
> On Sun, Oct 24, 2010 at 3:42 PM, Andrew Godwin wrote:
> > On 23/10/10 12:54, George Sakkis wrote:
>
> >> This has been (rightly) marked as DDN, so I'm wondering if there are
> >> any thoughts on it to
On 25 October 2010 15:19, rebus_ wrote:
> IMHO, proper implementation in cases where slug is used in URI should at
> least:
>
> * remember the old slug for the object
> * return HTTP 301 [1] when the URI with the old slug is requested and
> have Location field set to a
contrib.messages middleware was broken because it relies on something
that should happen on template rendering (iteration over the messages
in this case) and don't access response content directly.
I was about to introduce 'BakingMiddleware' - the middleware that
bakes the response explicitly. It
On Sun, Oct 24, 2010 at 3:42 PM, Andrew Godwin wrote:
> On 23/10/10 12:54, George Sakkis wrote:
>>
>> This has been (rightly) marked as DDN, so I'm wondering if there are
>> any thoughts on it to move it forward, one way or another. Original
>> thread at
>>
On Mon, Oct 25, 2010 at 1:31 AM, oggy wrote:
> Hi,
>
> would any of the commiters consider marking the patch in #11035
> (urlify.js with Serbian alphabet) as "ready for check-in"? It's
> important for Serbian i18n, but it's been sitting there for over a
> year. The patch
On Mon, Oct 25, 2010 at 1:29 AM, Benjamin Wohlwend wrote:
> Hi,
>
> I reported #13617[1] a couple of months ago, and today Justin Bronn
> committed a fix for it. Unfortunately, the fix doesn't solve my issue
> (which I failed to describe correctly in the issue report, so the
On Mon, Oct 25, 2010 at 5:01 AM, Florian Apolloner
wrote:
> Hi,
>
> in one of my projects I would like to alter the inlines in the admin
> on a per request basis. So I though I could use get_formsets to drop
> unneeded inlines; this isn't the case :( get_formsets has to
Sorry for massive email spam on this list :)
I came up with even more naive implementation of
TemplateResponseMixin:
http://bitbucket.org/kmike/django/src/a3e242ca7b4b/django/views/generic/base.py#cl-87
response.template_name will contain a list of names and there is
(almost) no code
I don't believe there is.
Historically, this is there because slug fields usually make their way
to be used
for URLs. As such, changing the title of an object shouldn't adjust its URL as
that can be bad for SEO and folks who might have bookmarked it.
You can, however, add your own javascript via
File "admin_modify.py" method "def prepopulated_fields_js(context)"
Line 11:
if context['add'] and 'adminform' in context:
should be changed to
if 'adminform' in context:
to allow slug be auto updated every time and not only on the entity
creation in admin.
Is there any setting to do it without
14 matches
Mail list logo