On Tue, Nov 2, 2010 at 11:06 PM, Mikhail Korobov wrote:
> Hi all.
>
> The new patch is attached to ticket (see
> http://code.djangoproject.com/attachment/ticket/12816/render_shortcut.6.diff?format=raw
> ). Docs are cumbersome (and incomplete), and a couple of middleware
> tests are missing.
>
> 1)
On 11/02/2010 05:27 PM, Mikhail Korobov wrote:
I'm quite busy now and don't think I'll be able to make the patch
ready by 1.3 alpha 1.
Full feature freeze is expected only by the time of beta so I don't
think it's absolutely necessary to push it before alpha 1.
Anyway since I care very much
I'm quite busy now and don't think I'll be able to make the patch
ready by 1.3 alpha 1.
On 2 ноя, 20:06, Mikhail Korobov wrote:
> Hi all.
>
> The new patch is attached to ticket
> (seehttp://code.djangoproject.com/attachment/ticket/12816/render_shortcut...
> ). Docs are cumbersome (and incomplet
Hi all.
The new patch is attached to ticket (see
http://code.djangoproject.com/attachment/ticket/12816/render_shortcut.6.diff?format=raw
). Docs are cumbersome (and incomplete), and a couple of middleware
tests are missing.
1) Template response middleware is introduced. It is applied only for
res
On 10/30/2010 10:47 PM, SmileyChris wrote:
It seems a simple enough proposal that trying to access the content
property would raise an error until it is explicitly baked. Problem
solved.
True. I seem to somehow missed it between the lines. Thanks! I'm +1 on
it by the way.
--
You received thi
On Oct 31, 8:26 am, Ivan Sagalaev wrote:
> Russel and others: do you think the issue of accidental baking is a
> show-stopper here?
It seems a simple enough proposal that trying to access the content
property would raise an error until it is explicitly baked. Problem
solved.
--
You received t
On 10/29/2010 09:38 PM, Carl Meyer wrote:
Seems that a template-response-middleware might reasonably want to
look at some other response data (headers? or simply extra annotation
attributes?) in order to make decisions about what to do.
You right. And it's not feasible (or beautiful) to just ri
On Oct 29, 2:04 pm, Ivan Sagalaev wrote:
> Aha, I see the point now. On a second thought I think we can avoid this
> problem altogether by not passing actual response object into
> middleware. Instead we could pass just those bits that a middleware
> should care about: a template name and a contex
On 10/29/2010 09:58 AM, Russell Keith-Magee wrote:
I agree that it's important to treat people as grown ups. However,
this is something that is trivial to do by accident -- for example,
printing response.content would be an obvious debug step -- and it
will be a non-trivial thing to identify that
On 29 окт, 10:09, Russell Keith-Magee wrote:
>
> Ah - I wasn't aware there was a working implementation of this idea --
> did I miss a link somewhere?
>
No, there is no full working implementation. I'm talking about Ivan's
code snippet:
response = get_response(...)
if hastattr(response
On Fri, Oct 29, 2010 at 2:50 PM, Ivan Sagalaev
wrote:
> Russel:
>>>
>>> Wouldn't it make sense to put a flag on the TemplateResponse
>>> that prohibits accidental baking?
>
> Mikhail:
>>
>> So maybe it will be better not to make bake/force_bake public so that
>> users won't be able to shoot themse
Russel:
Wouldn't it make sense to put a flag on the TemplateResponse
that prohibits accidental baking?
Mikhail:
So maybe it will be better not to make bake/force_bake public so that
users won't be able to shoot themselves in the foot?
I don't think it's doable at all. People still can call a
2010/10/29 Mikhail Korobov :
> Hi Russel,
>
> Thank you for your reviews and moving things on!
>
> On 29 окт, 07:35, Russell Keith-Magee wrote:
>>
>> I like this idea -- it's is an elegant solution to the problem, and
>> avoids all the backwards compatibility issues I can think of.
>>
>> I have tw
Hi Russel,
Thank you for your reviews and moving things on!
On 29 окт, 07:35, Russell Keith-Magee wrote:
>
> I like this idea -- it's is an elegant solution to the problem, and
> avoids all the backwards compatibility issues I can think of.
>
> I have two comments:
>
> Firstly, there needs to be
On Thu, Oct 28, 2010 at 2:55 PM, Ivan Sagalaev
wrote:
> On 10/27/2010 04:55 PM, Mikhail Korobov wrote:
>>
>> 1. 'Border' middleware is a backwards-compatible change, the
>> requirement to bake response in middleware isn't.
>>
>> The
>> difference is only that you propose to execute 'bake' in the e
On 10/28/2010 12:24 PM, Mikhail Korobov wrote:
The request handling code have to be put into WSGIHandler and into
ModPythonHandler so I'll wait until the patch for
http://code.djangoproject.com/ticket/9886
will be landed.
I'd say it's even worth to wait for
http://code.djangoproject.com/ticke
On 28 окт, 12:55, Ivan Sagalaev wrote:
> On 10/27/2010 04:55 PM, Mikhail Korobov wrote:
>
> > 1. 'Border' middleware is a backwards-compatible change, the
> > requirement to bake response in middleware isn't.
>
> > The
> > difference is only that you propose to execute 'bake' in the end of
> > res
On 10/27/2010 04:55 PM, Mikhail Korobov wrote:
1. 'Border' middleware is a backwards-compatible change, the
requirement to bake response in middleware isn't.
The
difference is only that you propose to execute 'bake' in the end of
response cycle and I propose to execute it at the beginning of the
Hmm, and now I don's see a use case for the 'force_bake' (and maybe
even public 'bake' method) method if BakingMiddleware is implemented.
With BakingMiddleware there is exactly one place where response should
be baked and user's code shouldn't be calling 'force_bake' and even
'bake' on responses.
Hi Ivan,
Let me explain why I prefer 'border' middleware way (that is
implemented) over explicit baking in messages middleware (that was
implemented but then replaced with 'border' middleware).
1. 'Border' middleware is a backwards-compatible change, the
requirement to bake response in middleware
On 10/25/2010 04:33 PM, Russell Keith-Magee wrote:
* 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
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 sett
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
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
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
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. Th
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.
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
Hi all again!
I've done some research on generic views integration and think that
TemplateResponseMixin should be refactored in order to use
TemplateResponse (SimpleTemplateResponse actually) because it
currently assumes that template must be rendered before the response
is returned.
'render_temp
On 22 окт, 18:10, Łukasz Rekucki wrote:
> On 22 October 2010 03:59, Russell Keith-Magee wrote:
> > 2010/10/21 Łukasz Rekucki :
> >> Both render_to_response() and direct_to_template() have one very
> >> annoying flaw:http://code.djangoproject.com/ticket/12669. Please add
> >> a "response_class" ke
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 fo
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,
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 # 'fo
2010/10/22 Łukasz Rekucki :
> On 22 October 2010 03:59, Russell Keith-Magee wrote:
>> 2010/10/21 Łukasz Rekucki :
>>> On 20 October 2010 21:57, Jacob Kaplan-Moss wrote:
2010/10/20 Mikhail Korobov :
> There is an unresolved question in the ticket: "The only hesitation is
> the relatio
On 22 October 2010 03:59, Russell Keith-Magee wrote:
> 2010/10/21 Łukasz Rekucki :
>> On 20 October 2010 21:57, Jacob Kaplan-Moss wrote:
>>> 2010/10/20 Mikhail Korobov :
There is an unresolved question in the ticket: "The only hesitation is
the relationship with #12815; we should resolv
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
Hi Russel,
On 10/22/2010 05:20 AM, Russell Keith-Magee wrote:
Jacob has already marked #9886 RFC, and on first inspection, the patch
looks good to me too; I want to have a closer look before I commit,
though. If you want to proceed assuming that #9886 will be committed
(i.e., make the fix for #1
2010/10/21 Łukasz Rekucki :
> On 20 October 2010 21:57, Jacob Kaplan-Moss wrote:
>> 2010/10/20 Mikhail Korobov :
>>> There is an unresolved question in the ticket: "The only hesitation is
>>> the relationship with #12815; we should resolve that decision before
>>> committing anything for this tick
On Fri, Oct 22, 2010 at 8:19 AM, Mikhail Korobov wrote:
> Patch is ready for review:
> http://bitbucket.org/kmike/django/changeset/37d977574923
>
> This is the TempleteResponse by Simon Willison with tests and minor
> tweaks.
>
> Notes:
>
> - TemplateResponse and SimpleTemplateResponse reside in
On Fri, Oct 22, 2010 at 12:34 AM, Ivan Sagalaev
wrote:
> On 10/21/2010 03:22 PM, Ivan Sagalaev wrote:
>>
>> On 10/21/2010 11:49 AM, Mikhail Korobov wrote:
>>>
>>> 2. Does TemplateResponse allow pretty exception pages or not? Is Ben's
>>> issue resolved?
>>
>> I'll look into it this evening (MSD).
Patch is ready for review:
http://bitbucket.org/kmike/django/changeset/37d977574923
This is the TempleteResponse by Simon Willison with tests and minor
tweaks.
Notes:
- TemplateResponse and SimpleTemplateResponse reside in
django.template.response
- django/shortcuts/__init__.py used to have ext
I love programming: two-liner shortcut turns to be a massive core
refactoring ;) Ivan, thank you for the research.
I'll provide a draft patch for 'render == TemplateResponse' soon.
By the way, Łukasz Rekucki's suggestion to add the 'response_class' to
render shortcut is complicated much by Templa
On 10/21/2010 03:22 PM, Ivan Sagalaev wrote:
On 10/21/2010 11:49 AM, Mikhail Korobov wrote:
2. Does TemplateResponse allow pretty exception pages or not? Is Ben's
issue resolved?
I'll look into it this evening (MSD).
So I did.
There are actually two problems:
- Exceptions in response middl
On 10/21/2010 11:49 AM, Mikhail Korobov wrote:
2. Does TemplateResponse allow pretty exception pages or not? Is Ben's
issue resolved?
I'll look into it this evening (MSD).
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this g
Well, I don't mean that now we all must write only class-based views.
I was talking about reusable views and most views don't have to be
reusable (though it would be nice). Django now can help developer in
writing reusable views and it was not the case when TemplateResponse
was invented. That's wha
On 10/21/2010 11:10 AM, James Bennett wrote:
Django cares about whether your views meet the following criteria:
1. Is a callable object.
2. When called, accepts an instance of HttpRequest as its first
positional argument.
3. When called, returns an instance of HttpResponse or raises an exception
On Thu, Oct 21, 2010 at 1:29 AM, Ivan Sagalaev
wrote:
> Can someone of core committers clarify this: is it now recommended to write
> all views as classes?
Django cares about whether your views meet the following criteria:
1. Is a callable object.
2. When called, accepts an instance of HttpReque
On 10/21/2010 01:39 AM, Mikhail Korobov wrote:
1. Developer writes a view and want to reuse it (e.g. change the
context).
My assumptions was:
a) Class based views are now the recommended way to write reusable
views
This is where our views differ. I have to admit that I didn't follow
closely t
Hi Ivan!
On 21 окт, 03:00, Ivan Sagalaev wrote:
>
> Wait!!!
>
> Sorry… Hello everyone :-)
>
> If I remember correctly TemplateResponse was solving a problem of some
> middleware wanting to mess with a view context before it's baked into
> final string representation. This would solve in a good wa
On 10/20/2010 11:51 PM, Mikhail Korobov wrote:
#12815 is about introducing TemplateResponse. Is the patch with
'render' shortcut returning just HttpResponse acceptable? I think that
TemplateResponse is less useful after class-based views make their way
into trunk so 'render' shortcut shouldn't bo
I think the correct ticket is http://code.djangoproject.com/ticket/9081
and it is in 'almost-wontfix' state now. Yes, it's a great time to
either move it to wontfix or mark as accepted and implement alongside
with the render shortcut.
On 21 окт, 02:05, Łukasz Rekucki wrote:
> On 20 October 2010 2
On 20 October 2010 21:57, Jacob Kaplan-Moss wrote:
> 2010/10/20 Mikhail Korobov :
>> There is an unresolved question in the ticket: "The only hesitation is
>> the relationship with #12815; we should resolve that decision before
>> committing anything for this ticket."
>>
>> #12815 is about introdu
2010/10/20 Mikhail Korobov :
> There is an unresolved question in the ticket: "The only hesitation is
> the relationship with #12815; we should resolve that decision before
> committing anything for this ticket."
>
> #12815 is about introducing TemplateResponse. Is the patch with
> 'render' shortcu
That's great! I'll mark the ticket as assigned for me then.
There is an unresolved question in the ticket: "The only hesitation is
the relationship with #12815; we should resolve that decision before
committing anything for this ticket."
#12815 is about introducing TemplateResponse. Is the patch
On Wed, Oct 20, 2010 at 1:48 PM, Mikhail Korobov wrote:
> So please add the 'render' shortcut in 1.3.
It's one of the things on my list. If you'd like to make it happen
faster, a patch + tests would make it a no-brainer for me.
Jacob
--
You received this message because you are subscribed to t
Hi all,
I'm talking about this ticket: http://code.djangoproject.com/ticket/12816
With class-based views landed and the deprecation of
django.views.generic.simple (and direct_to_template in particular)
there won't be simple and undeprecated shortcut for
render_to_response.
So please add the 'ren
56 matches
Mail list logo
