Allow slug to be prepopulated on edit
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 changing Django internal source code? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Allow slug to be prepopulated on edit
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 the methods listed in the docs[0]. If you need more help on this, please direct your questions to django-users as this has more to do with using django than the core product itself. Best of luck, -justin [0]: http://docs.djangoproject.com/en/dev/ref/contrib/admin/#modeladmin-media-definitions On Mon, Oct 25, 2010 at 4:32 AM, Alex wrote: > 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 changing Django internal source > code? > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Gentle Proposal: add 'render' shortcut in 1.3
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 duplication between TemplateResponse and
TemplateResponseMixin with this implementation. Custom template
loading and context instantiation go to TemplateResponse subclasses.
On 24 окт, 17:32, Mikhail Korobov wrote:
> new changes (integration with generic views, test client and messages
> middleware fixes):http://bitbucket.org/kmike/django/overview
>
> Yet another gotchas:
>
> - response.template_name for generic views will contain Template
> instance, not template names, so response.template_name is quite
> misleading. The better name ('template') is already taken by test
> client (but it is deprecated in 1.3). I can't find a good solution so
> leave the 'template_name' for now.
>
> - hasattr(response, 'bake') and callable(response.bake) checks are
> ugly. The alternative is to provide HttpResponse.bake method but this
> way HttpResponse will be aware of TemplateResponse and it doesn't seem
> clean for me.
>
> On 24 окт, 02:14, Mikhail Korobov wrote:
>
>
>
> > Yes, you're right and I was wrong, the messages middleware doesn't
> > return response as-is. I'll take a look.
>
> > As for tests, response.context and response.templates are not
> > available for TemplateResponse instances before they are baked so test
> > client should be patched to explicitly bake the response. There is
> > response.template_context and response.template_name but their
> > semantics differ.
>
> > On 24 окт, 01:52, SmileyChris wrote:
>
> > > The points were just off the top of my head from memory, when I get
> > > back to work I'll have a look to see what the actual cases are.
>
> > > Regarding the messages middleware, I *know* there's a problem. A
> > > message won't be marked as "read", since the template hasn't iterated
> > > the messages object by the time the middleware is triggered
>
> > > On Oct 23, 8:35 am, Mikhail Korobov wrote:
>
> > > > Hi Chris,
>
> > > > I don't see anything harmful neither in
> > > > django.contrib.messages.middleware.MessageMiddleware nor in
> > > > django.test.testcases.assertContains.
> > > > Messages middleware passes response as-is and assertContains reads
> > > > 'content' attribute and thus forces the baking.
>
> > > > at lest the following test case forks fine for me:
>
> > > > class AssertTestCase(TestCase):
> > > > def test_assert_contains(self):
> > > > request = RequestFactory().get('/')
> > > > template = Template('foo')
> > > > response = TemplateResponse(request, template)
> > > > self.assertContains(response, 'oo')
>
> > > > Can you please provide more details?
>
> > > > On 23 окт, 00:21, SmileyChris wrote:
>
> > > > > In my use of TemplateResponse in a real project, we encountered two
> > > > > gotchas that I can think of off the top of my head:
>
> > > > > 1. You need to explicitly bake the response if you are testing using
> > > > > assertContains
> > > > > 2. You need to explicitly bake the response before the
> > > > > contrib.messages middleware
>
> > > > > On Oct 23, 1:32 am, Russell Keith-Magee
> > > > > wrote:
>
> > > > > > On Fri, Oct 22, 2010 at 7:32 PM, Mikhail Korobov
> > > > > > wrote:
> > > > > > > Russell's comments were helpful in discovering the edge case.
> > > > > > > _set_content behaves differently for baked and non-baked
> > > > > > > responses:
>
> > > > > > > response = render(request, Template('foo'))
> > > > > > > response.content = 'bar'
> > > > > > > print response.content # 'foo'
> > > > > > > response.content = 'baz'
> > > > > > > print response.content # 'baz'
>
> > > > > > > This is confusing so I think responses should be marked as baked
> > > > > > > in
> > > > > > > _set_content, not in force_bake.
>
> > > > > > > The patch that should resolve this concern and Russell's concerns
> > > > > > > regarding the
> > > > > > > tests:http://bitbucket.org/kmike/django/changeset/00f8be464749
>
> > > > > > > I'll take a look at docs and generic views integration later.
>
> > > > > > > Should new generic views return TemplateResponse by default?
>
> > > > > > I would have thought so. Is there a compelling reason why CBV's
> > > > > > shouldn't return a TemplateResponse?
>
> > > > > > Yours,
> > > > > > Russ Magee %-)
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Allow slug to be prepopulated on edit
On 25 October 2010 14:04, Justin Lilly wrote: > 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 the methods listed in the > docs[0]. If you need more help on this, please direct your questions to > django-users as this has more to do with using django than the core product > itself. > > Best of luck, > -justin > > [0]: > http://docs.djangoproject.com/en/dev/ref/contrib/admin/#modeladmin-media-definitions > > On Mon, Oct 25, 2010 at 4:32 AM, Alex wrote: >> 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 changing Django internal source >> code? >> Just to expand on Justin Lilly's thoughts: 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 URI with a new slug These two points are well beyond the scope of JavaScript and require certain amount of changes in how the SlugField is now handled in Django. [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.2 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Gentle Proposal: add 'render' shortcut in 1.3
2010/10/25 Mikhail Korobov : > 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 duplication between TemplateResponse and > TemplateResponseMixin with this implementation. Custom template > loading and context instantiation go to TemplateResponse subclasses. This is starting to look good to me; here are some comments, going back a couple of messages: * Yes, you've got the right idea with regards to the role played by the various TemplateResponseMixin methods * It seems reasonable to me that assertTemplateUsed would require some baking, and yes, that should be happening at the test client before template rendering signals are disconnected. * The problem with messages is a big one -- probably even a show-stopper if we can't find a way to reconcile the general use case that it represents (i.e., we don't just need a fix for contrib.messages -- we need to explain how/why the problem exists, and provide a consistent approach for analogous problems) * Following the convention of the rest of the API, the call to get_template_names() should be internal to get_response(), not passed in as an argument. * I'm not entirely convinced that get_response() is needed now. As your implementation currently stands, render_to_response() is just a call to get_response() -- which suggests that the extra level of indirection isn't needed. Backing up this position -- most of the flexibility that TemplateResponseMixin has is to enable the easy integration of different rendering engines and contexts; those API points are now provided by TemplateResponse, so there isn't any need to preserve them in the mixin. If you want to use a different loader, template renderer, context instance, etc, you subclass TemplateResponse. So - revised source code: class TemplateResponseMixin(object): """ A mixin that can be used to render a template. """ template_name = None template_response_class = TemplateResponse def render_to_response(self, context): """ Returns a response with a template rendered with the given context. """ return self.template_response_class( request=self.request, template=self.get_template_names(), context=context, **response_kwargs ) def get_template_names(self): """ Returns a list of template names to be used for the request. Must return a list. May not be called if render_to_response is overridden. """ if self.template_name is None: return [] else: return [self.template_name] However, all this is a moot point if we can't find a fix for the contrib.messages problem. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Increasing the usefulness of ModelAdmin.get_formsets
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 return > the same inlines in the correct order (eg > http://code.djangoproject.com/browser/django/trunk/django/contrib/admin/options.py#L789 > requires this). Maybe we could add a method like > get_formsets_with_inlines (better name anyone) which (by default) > would just return zip(self.get_formsets(request), > self.inline_instances). This would increase the usefulness of > get_formsets quite a bit imo. Any thoughts? Sounds like a reasonable idea in general. However, get_formsets_with_inlines strikes me as exposing a little too much of the internal implementation. Having a quick look at the code, it strikes me that the actual use case here is 'get_formset_instances()' -- the prefixing and formset instantiation logic is essentially shared between the three places that get_formsets() are used, and would provide the entry point that you need to eliminate formsets on a per-request basis. I'd be a lot more comfortable with an API at than one that provides 'zip some stuff together' level functionality. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: RFC: issue 13617
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
> blame is on me) nor does it address a larger problem that I described
> in the ticket with the current l10n handling of numbers:
>
> Django's handling of localization of numbers in templates may result
> in undesired output with some locales. When rendering structured
> content like JavaScript, it generates output that may be syntactically
> or semantically incorrect, e.g.:
>
> var num = {{ 2.5 }};
>
> is rendered as "var num = 2,5;" (note the decimal separator) using the
> locale "de-de".
>
> . AFAIK, there are only two work arounds:
>
> * completely deactivate l10n
> * convert every floating point number to a string in the view layer,
> using a suitable locale
>
> My proposal is to introduce a block tag that temporarily deactivates
> l10n for the enclosed fragment. See the patch I attached to the
> ticket.
>
> Two other tickets (#14181, #14164) are manifestations of this issue.
> Unfortunately, I found them only after writing the patch. I like the
> tags proposed in #14181 better than my `{% noloc %}{{ variable }}{%
> endnoloc %}`. I'll update my patch if that is the general consensus.
>
> Justin said he'd like some more core dev eyes on the patch, since it
> touches a couple of vital code paths in the template system. So here I
> am :)
Responding so that
"localize off" is a much better approach to localize
1) I think there is still a need for a template filter. There's an
analog here with autoescape; there's an autoescape template tag for a
large block of content, but there's also an escape filter to escape a
single variable.
2) activate() isn't a cheap operation; I know I put {% localize "de"
%} as a use case in the ticket, but on reflection, I'm not sure it's
worth the overhead. That said, I'm willing to be convinced otherwise
if there's a lot of demand for this feature.
3) The '_localize' magic variable in the context. It looks to me like
a better solution would be to pass down a 'localize' argument to
render. This is a little more intrusive to the codebase, but it
doesn't have the same code smell to me.
4) 'force' isn't a good description of the argument to date_format()
et al. I'd be inclined to extend the 'localize' argument from point
(2), and use a ternary logic value; True/False, plus None == use the
value of USE_L10N.
Yours,
Russ Magee %-)
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Bump of #11035
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 shouldn't be controversial at all (it's not perfect > but it's a significant improvement over the current situation). It > wasn't accepted for 1.1 as it was reported too late, so just trying to > make sure it avoids the same fate for 1.3. The Ready For Checkin tag doesn't need to be handled by a committer -- in fact, we rely on the community to do this triage and point us at tickets that are ready. This person who does the triage doesn't need to be anyone in particular. It just needs to be someone other than the patch submitter (and in this case, someone who speaks Serbian). The other reason the patch hasn't progressed is that it isn't in a format we can easily use. We prefer context diffs generated against the root of the source tree, not 'ed' format diffs of a single file. >From a pure content point of view, the patch looks fine, assuming the Cyrillic mapping is accurate. It's also preferable to the patch on #14345 due to the fact that it doesn't change the ordering of ALL_DOWNCODE_MAPS. If you update the patch to be a context diff, and get another Serbian speaker to review it, it can progress. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: #13772 design decision needed
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 >> http://groups.google.com/group/django-developers/browse_frm/thread/3b5939ba089bce51/67892d99a9a6aff3. >> >> George > > My personal opinion on this is that we shouldn't put this into pre_save - > I'd rather not have us doing a query before we get that far (and I've seen > quite a few things that do some validation in pre_save, so cancellation > happens reasonably often). > > I'm also not particularly fond of adding yet another signal - we risk making > it a mess of connection points, and signal calls, even if empty, do have > overhead. > > My preferred solution is either to not ship this, or replace it with a > decorator which does this for you (so you can wrap your pre_save listener > function in the decorator, which does the existence query for you, and which > also passes this information back up to the model instance so we don't end > up doing three queries). That way, people who want this can have it, we > don't have a useless extra query in nearly any scenario, and we don't change > current behaviour. For the record, I concur with Andrew's reasoning. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Gentle Proposal: add 'render' shortcut in 1.3
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 can be a border between middlewares with rendered templates as requirement and middlewares without this requirement. But we can't inject this middleware in backwards- compatible way to user's code so I just fixed the contrib.messages middleware. I still like the idea but don't know if we can afford 'add BakingMiddleware before the MessagesMiddleware' note in upgrade docs. This is all quite similar to problems django have with streaming http responses (see http://groups.google.com/group/django-developers/browse_thread/thread/9dc1bb93eed77987/c61c1b8d5426c1cb?lnk=gst&q=http+content#c61c1b8d5426c1cb) and maybe there are some ideas from that thread which may be useful. On 25 окт, 19:33, Russell Keith-Magee wrote: > 2010/10/25 Mikhail Korobov : > > > 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/gener... > > > response.template_name will contain a list of names and there is > > (almost) no code duplication between TemplateResponse and > > TemplateResponseMixin with this implementation. Custom template > > loading and context instantiation go to TemplateResponse subclasses. > > This is starting to look good to me; here are some comments, going > back a couple of messages: > > * Yes, you've got the right idea with regards to the role played by > the various TemplateResponseMixin methods > > * It seems reasonable to me that assertTemplateUsed would require > some baking, and yes, that should be happening at the test client > before template rendering signals are disconnected. > > * The problem with messages is a big one -- probably even a > show-stopper if we can't find a way to reconcile the general use case > that it represents (i.e., we don't just need a fix for > contrib.messages -- we need to explain how/why the problem exists, > and provide a consistent approach for analogous problems) > > * Following the convention of the rest of the API, the call to > get_template_names() should be internal to get_response(), not passed > in as an argument. > > * I'm not entirely convinced that get_response() is needed now. As > your implementation currently stands, render_to_response() is just a > call to get_response() -- which suggests that the extra level of > indirection isn't needed. > > Backing up this position -- most of the flexibility that > TemplateResponseMixin has is to enable the easy integration of > different rendering engines and contexts; those API points are now > provided by TemplateResponse, so there isn't any need to preserve them > in the mixin. If you want to use a different loader, template > renderer, context instance, etc, you subclass TemplateResponse. > > So - revised source code: > > class TemplateResponseMixin(object): > """ > A mixin that can be used to render a template. > """ > template_name = None > template_response_class = TemplateResponse > > def render_to_response(self, context): > """ > Returns a response with a template rendered with the given context. > """ > return self.template_response_class( > request=self.request, > template=self.get_template_names(), > context=context, > **response_kwargs > ) > > def get_template_names(self): > """ > Returns a list of template names to be used for the request. Must > return > a list. May not be called if render_to_response is overridden. > """ > if self.template_name is None: > return [] > else: > return [self.template_name] > > However, all this is a moot point if we can't find a fix for the > contrib.messages problem. > > Yours, > Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Allow slug to be prepopulated on edit
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 URI with a new slug Sounds like a job for the database to me, a Redirect-model or somesuch. Lookup old url/slug, receive new url/slug. HM -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: #13772 design decision needed
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 move it forward, one way or another. Original > >> thread at > >>http://groups.google.com/group/django-developers/browse_frm/thread/3b > > >> George > > > My personal opinion on this is that we shouldn't put this into pre_save - > > I'd rather not have us doing a query before we get that far (and I've seen > > quite a few things that do some validation in pre_save, so cancellation > > happens reasonably often). > > > I'm also not particularly fond of adding yet another signal - we risk making > > it a mess of connection points, and signal calls, even if empty, do have > > overhead. > > > My preferred solution is either to not ship this, or replace it with a > > decorator which does this for you (so you can wrap your pre_save listener > > function in the decorator, which does the existence query for you, and which > > also passes this information back up to the model instance so we don't end > > up doing three queries). That way, people who want this can have it, we > > don't have a useless extra query in nearly any scenario, and we don't change > > current behaviour. > > For the record, I concur with Andrew's reasoning. Fair enough; unless someone objects in the next few days, I'll close it as wontfix. George -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Gentle Proposal: add 'render' shortcut in 1.3
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 settings.py (with a blank line above). 3. The ugly bit: if there is no BakingMiddleware in settings.MIDDLEWARE_CLASSES then assume that it is the last middleware. django.core.handlers.base.BaseHandler should be patched for that. Warning may also be emitted if there is no explicit BakingMiddleware in settings.py so that this ugly bit can be removed in future. 4. raise ImproperlyConfigured exception if unbaked response is received by messages middleware This way changes will be backwards-compatible on middleware level because middlewares will only receive baked responses by default. No existing middlewares make use of TemplateResponse and things will work as usual with default setup. Cool new response middlewares that makes use of TemplateResponse (e.g. do some caching or paginating on context objects) can be put after the BakingMiddleware so they will be able mess with an unbaked response if it is available. Implementation (no tests and docs): http://bitbucket.org/kmike/django/changeset/68571aa0e5a3 On 25 окт, 20:36, Mikhail Korobov wrote: > 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 can be a border between middlewares > with rendered templates as requirement and middlewares without this > requirement. But we can't inject this middleware in backwards- > compatible way to user's code so I just fixed the contrib.messages > middleware. I still like the idea but don't know if we can afford 'add > BakingMiddleware before the MessagesMiddleware' note in upgrade docs. > > This is all quite similar to problems django have with streaming http > responses > (seehttp://groups.google.com/group/django-developers/browse_thread/thread...) > and maybe there are some ideas from that thread which may be useful. > > On 25 окт, 19:33, Russell Keith-Magee wrote: > > > > > 2010/10/25 Mikhail Korobov : > > > > 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/gener... > > > > response.template_name will contain a list of names and there is > > > (almost) no code duplication between TemplateResponse and > > > TemplateResponseMixin with this implementation. Custom template > > > loading and context instantiation go to TemplateResponse subclasses. > > > This is starting to look good to me; here are some comments, going > > back a couple of messages: > > > * Yes, you've got the right idea with regards to the role played by > > the various TemplateResponseMixin methods > > > * It seems reasonable to me that assertTemplateUsed would require > > some baking, and yes, that should be happening at the test client > > before template rendering signals are disconnected. > > > * The problem with messages is a big one -- probably even a > > show-stopper if we can't find a way to reconcile the general use case > > that it represents (i.e., we don't just need a fix for > > contrib.messages -- we need to explain how/why the problem exists, > > and provide a consistent approach for analogous problems) > > > * Following the convention of the rest of the API, the call to > > get_template_names() should be internal to get_response(), not passed > > in as an argument. > > > * I'm not entirely convinced that get_response() is needed now. As > > your implementation currently stands, render_to_response() is just a > > call to get_response() -- which suggests that the extra level of > > indirection isn't needed. > > > Backing up this position -- most of the flexibility that > > TemplateResponseMixin has is to enable the easy integration of > > different rendering engines and contexts; those API points are now > > provided by TemplateResponse, so there isn't any need to preserve them > > in the mixin. If you want to use a different loader, template > > renderer, context instance, etc, you subclass TemplateResponse. > > > So - revised source code: > > > class TemplateResponseMixin(object): > > """ > > A mixin that can be used to render a template. > > """ > > template_name = None > > template_response_class = TemplateResponse > > > def render_to_response(self, context): > > """ > > Returns a response with a template rendered with the given context. > > """ > > return self.template_response_class( > > request=self.request, > > template=self.get_template_names(), > >
Re: Ticket 9964 (was Re: Why does transaction management only commit on is_dirty?)
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 TODOs still). > I was quite surprised to see that comment, in light of http://code.djangoproject.com/ticket/9964#comment:15 where Russell, Malcolm and Jacob decided that the patch's approach was unacceptable. > Looking at the history of the ticket, it looks like there is some concern > about keeping the "current behavior" to maintain backwards compatibility. > > Which raises the question: Just what is the current behavior that we'd like > to preserve? The current behavior is to keep "clean" transactions open. As benchmarks I ran then indicated ( http://code.djangoproject.com/ticket/9964#comment:6 ), this may under some scenarios actually improve performance. > The current situation seems to be quite indeterminate; the > transaction just stays open until it is closed... somehow, by some means > (probably a rollback when the connection closes). (more probably until the relevant thread handles a request which updates the database through the models, or otherwise dirties a transaction) > Is this really > explicit-enough behavior that maintaining it is important? Are > applications really relying on it? > I would be extremely surprised if there is any application out there which conciously relies on it. I would be almost as surprised if the behavior is changed to "always close transactions" and no website starts to break misteriously or experience 20% slow-downs. The change is deep. This is why I tried to make it so that all new projects start with correct behavior, but upgrades under old projects will not change the behavior. If Jacob has indeed changed his mind about the viability of this approach -- or if your "just do the right thing" approach is accepted -- I will be delighted to cooperate on updating the patches. Just please CC me with responses, because I tend to neglect monitoring this list. Thanks, Shai. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: RFC: issue 13617
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. There's an
> analog here with autoescape; there's an autoescape template tag for a
> large block of content, but there's also an escape filter to escape a
> single variable.
The revised patch has a template filter. Not sure about using the same
name as for the template tag, though.
>
> 2) activate() isn't a cheap operation; I know I put {% localize "de"
> %} as a use case in the ticket, but on reflection, I'm not sure it's
> worth the overhead. That said, I'm willing to be convinced otherwise
> if there's a lot of demand for this feature.
I agree that switching locale in the template rendering stage seems to
be an obscure use case. I removed it for the time being.
>
> 3) The '_localize' magic variable in the context. It looks to me like
> a better solution would be to pass down a 'localize' argument to
> render. This is a little more intrusive to the codebase, but it
> doesn't have the same code smell to me.
I tried to implement this, but this puts me firmly into code paths I'm
not comfortable messing with, especially with regard to backwards
compatibility. I confined the `localization` argument to
`VariableNode`'s with an `isinstance` check, but still, any third
party `Node`s inheriting from `VariableNode` will not like this.
>
> 4) 'force' isn't a good description of the argument to date_format()
> et al. I'd be inclined to extend the 'localize' argument from point
> (2), and use a ternary logic value; True/False, plus None == use the
> value of USE_L10N.
Done. I named the argument `localization`, though. `localize` crashes
with the `localize` function in `django.utils.formats`.
Kind regards,
Benjamin
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Direction on #10899
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 django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
