Nested Namespaces don't Reverse

[jameslon...@gmail.com]

I have a simple example that is giving me some trouble. When a project
has multiple instances of an application referenced by patterns nested
more than one level deep it seems impossible to look up using reverse
() with only two path components. No matter what the current_app
argument is set to.

After looking at django internals this seems to be by design. However
it makes nesting of namespaces somewhat difficult to deploy because
there isn't a dynamic way to construct URLs based on contextual
information in your application.

Here is my urlpatterns to test:

patterns2 = (patterns('views',
url(r'^$', 'index', name='index'),
), 'app', 'inst2')


patterns1 = (patterns('views',
url(r'^$', 'index', name='index'),
url(r'^instance2/', include(patterns2)),
), 'app', 'inst1')


urlpatterns = patterns('views',
url(r'^$', 'index', name='crm'),
url(r'^instance1/', include(patterns1)),

)


and the view that I was testing with:
def index(request):
print reverse('app:index', current_app='inst2') #busted, should
return /instance1/instance2/, not /instance1/
print reverse('app:index', current_app='inst1') #works, /
instance1/
print reverse('inst1:app:index') #works, should it?, /instance1/
instance2/
print reverse('inst1:inst2:index') #works, /instance1/instance2/
print reverse('app:index') #default instance, current_app should
change behavior
return HttpResponse('Try the console')


In an application where there are multiple instances responding on
many different urls nested amongst each other, it becomes impossible
to generate reverse() urls since you don't know your current
namespace.

To illustrate, generating the string 'inst1:inst2:index' at runtime
from within the application would be mostly impossible.
-- 
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.

ANNOUNCE: Django 1.2 alpha 1 released

[James Bennett]

The first alpha preview package for Django 1.2 is now available.

* Release notes: http://docs.djangoproject.com/en/dev/releases/1.2-alpha-1/

* Download instructions: http://www.djangoproject.com/download/

-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
-- 
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: Design and code review requested for Django string signing / signed cookies

[Elias Torres]

On Jan 5, 2:33 pm, Luke Plant  wrote:
> On Tuesday 05 January 2010 16:53:17 Elias Torres wrote:
>
> > Simon,
>
> > I'm not a security expert by any means, but I really the fact that
> > you're making use of HMACs in your design. I will ask a good friend
> > (Ben Adida) who's really an expert on the subject to see if your
> > paranoia on adding a salt and hashing the key helps you in any way.
> >  My intuition says if the salt will be stored and made available to
> >  anyone with access to the DB, I'm not sure it will make much of a
> >  difference. HMAC takes care of the prefix/suffix attacks already.
>
> The point of the 'salt' is to make it easy to use unique keys.  
> Otherwise, one use of HMAC with SECRET_KEY in a web app could be
> trivially used to compromise another usage.
>
> For example, suppose that, on a social network, the user can specify
> the username of someone that they nominate as a 'best friend' .  This
> value might be stored in a signed cookie.  If we use SECRET_KEY
> without salt as the HMAC key, the user then has access to the value
> HMAC(SECRET_KEY, some_username). But suppose another signed cookie is
> used to store the username when a user logs in (as opposed to using a
> session).  The value will be HMAC(SECRET_KEY, users_username).  Since
> an attacker can trivially get hold of  HMAC(SECRET_KEY,
> somone_elses_username), they can log in as anyone they like.
>
> 'Salt' in the key is to protect against that.  The signed cookie
> implementation, for example, uses the cookie *name* as part of the
> salt, so that all cookies have their own key.  The salt is not a
> secret, so doesn't provide any additional protection against brute
> force attacks, but it isn't meant to.
>
> Luke

Thanks Luke for your explanation. I think I have learned something
here in terms of my own application security independent of Django's
multi-app environment. Basically, you're reminding me that as an
application, I must be careful to not sign any random string for a
user, because it can be re-used for another purpose. Therefore, we
include the 'purpose', salt, or namespace in the process. One thing I
would like to ask though, is whether the salt needs to be part of the
key or the value? If you look at TimestampSigner, the timestamp goes
as part of the value. I think the same can be done with the name of
the cookie. In other words you can always use a method like
_cookie_signature as in Tornado's implementation [1] and always pass
two parts: cookie name and cookie value. Technically, as long as your
SECRET_KEY is protected, there should not be a need to creating
multiple signing keys, especially if the data is not secret.

def _cookie_signature(self, *parts):
  hash = hmac.new(SECRET_KEY, digestmod=hashlib.sha1)
  for part in parts: hash.update(part)
return hash.hexdigest()


Any thoughts on Django's auth using HMAC besides md5 and sha1 hashing
alone?

Thanks,

-Elias

[1] http://github.com/facebook/tornado/blob/master/tornado/web.py#L251

>
> --
> "Making it up? Why should I want to make anything up? Life's bad
> enough as it is without wanting to invent any more of it." (Marvin
> the paranoid android)
>
> Luke Plant ||http://lukeplant.me.uk/
-- 
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: Final call for feedback: Multi-db

[Russell Keith-Magee]

On Wed, Jan 6, 2010 at 12:42 AM, Brett Hoerner  wrote:
> On Dec 22 2009, 4:27 pm, Russell Keith-Magee 
> wrote:
>> I'll need to cogitate on this over my Christmas pudding :-)
>
> Did you come to any conclusions, or need any more feedback on the read-
> slave testing issue?

I haven't reached any conclusions - my pudding was not enlightening in
this regard. :-)

The complication is that without a good model of how master/slave will
work in normal code, it's difficult to work out how the test framework
should behave. My suggestion of TEST_NAME=None or your suggestion of
TEST_NAME= (default TEST_NAME) are both relatively simple to
implement, but I don't want to rush into implementing something that
doesn't actually help in practical terms.

If you're actually doing master/slave in the wild, your guidance may
actually be more enlightening than my theoretical navel gazing. In
particular - how have you got master/slave configured? How do you find
and select slave databases? How does that approach degrade when
DATABASES suddenly has less entries (including the case of a config
with no slaves)?

> I in no way mean to rush, I just wanted to make sure I didn't (and
> don't) miss anything as I'm more than happy to test any changes
> against our rather large and quirky setup.

You certainly haven't missed anything. There have been a couple of
discussions on separate threads about cross-database joins, but they
haven't turned into any trunk commits yet.

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: Possible contrib.humanize addition

[harrym]

Thanks for your reply - I'll have a look into how this would work with
other languages and get back to you if it looks like it would work
easily with other languages.

Regards,
Harry

On Jan 6, 3:45 am, Russell Keith-Magee  wrote:
> On Wed, Jan 6, 2010 at 5:24 AM, harrym  wrote:
> > I'm working a templatetag that determines whether to use 'a' or 'an'
> > in front of English words. My particular use case for this is in a
> > tumblelog app I'm developing - many different types of entry may be
> > added (link, html, quote, etc), and I'm linking to the 'Add a[n]
> >  entry' pages by iterating over the different types. Would this
> > be considered a useful addition to contrib.humanize?
>
> > The two main reasons against it I see are that firstly, it only works
> > for English words, so would be of little use to developers using
> > foreign languages, and secondly, it perhaps wouldn't be as widely used
> > as the other filters in there.
>
> It sounds like a potentially interesting addition to contrib.humanize,
> but you have hit both of the objections that I would raise.
>
> The foreign language limitation is particularly important - if we're
> going to introduce a tag like this, then it should be able to be used
> for languages other than English. If you present some research to
> demonstrate how this tag could/would work for non-English languages,
> it would be a lot more compelling.
>
> 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: Possible contrib.humanize addition

[Russell Keith-Magee]

On Wed, Jan 6, 2010 at 5:24 AM, harrym  wrote:
> I'm working a templatetag that determines whether to use 'a' or 'an'
> in front of English words. My particular use case for this is in a
> tumblelog app I'm developing - many different types of entry may be
> added (link, html, quote, etc), and I'm linking to the 'Add a[n]
>  entry' pages by iterating over the different types. Would this
> be considered a useful addition to contrib.humanize?
>
> The two main reasons against it I see are that firstly, it only works
> for English words, so would be of little use to developers using
> foreign languages, and secondly, it perhaps wouldn't be as widely used
> as the other filters in there.

It sounds like a potentially interesting addition to contrib.humanize,
but you have hit both of the objections that I would raise.

The foreign language limitation is particularly important - if we're
going to introduce a tag like this, then it should be able to be used
for languages other than English. If you present some research to
demonstrate how this tag could/would work for non-English languages,
it would be a lot more compelling.

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: Design and code review requested for Django string signing / signed cookies

[Elias Torres]

oops.. I mean really *like*. Thanks.

On Jan 5, 12:09 pm, Karen Tracey  wrote:
> On Tue, Jan 5, 2010 at 11:53 AM, Elias Torres  wrote:
>
> > I'm not a security expert by any means, but I really the fact that
> > you're making use of HMACs in your design.
>
> There seems to be a key word missing here: really  the fact...
>
> (One might guess based on the rest of the message, but still it might be
> nice to know what was intended to go there.)
>
> Karen
-- 
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: Design and code review requested for Django string signing / signed cookies

[Luke Plant]

On Tuesday 05 January 2010 16:53:17 Elias Torres wrote:
> Simon,
> 
> I'm not a security expert by any means, but I really the fact that
> you're making use of HMACs in your design. I will ask a good friend
> (Ben Adida) who's really an expert on the subject to see if your
> paranoia on adding a salt and hashing the key helps you in any way.
>  My intuition says if the salt will be stored and made available to
>  anyone with access to the DB, I'm not sure it will make much of a
>  difference. HMAC takes care of the prefix/suffix attacks already.

The point of the 'salt' is to make it easy to use unique keys.  
Otherwise, one use of HMAC with SECRET_KEY in a web app could be 
trivially used to compromise another usage.

For example, suppose that, on a social network, the user can specify 
the username of someone that they nominate as a 'best friend' .  This 
value might be stored in a signed cookie.  If we use SECRET_KEY 
without salt as the HMAC key, the user then has access to the value 
HMAC(SECRET_KEY, some_username). But suppose another signed cookie is 
used to store the username when a user logs in (as opposed to using a 
session).  The value will be HMAC(SECRET_KEY, users_username).  Since 
an attacker can trivially get hold of  HMAC(SECRET_KEY, 
somone_elses_username), they can log in as anyone they like.

'Salt' in the key is to protect against that.  The signed cookie 
implementation, for example, uses the cookie *name* as part of the 
salt, so that all cookies have their own key.  The salt is not a 
secret, so doesn't provide any additional protection against brute 
force attacks, but it isn't meant to.

Luke


-- 
"Making it up? Why should I want to make anything up? Life's bad 
enough as it is without wanting to invent any more of it." (Marvin 
the paranoid android)

Luke Plant || http://lukeplant.me.uk/
-- 
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.

[JOB] Python/Django Web Developer, NYC | 75-100k

[OSS]

This is a full time, on-site, salaried position is located in New York
City paying $75,000-$100,000.  No telecommuting allowed.  US Citizens,
Green Card holders, EAD or CAN only please.  Thank you.

My New York City client is an international comparative shopping
search engine that accumulates its data from crawling online stores.
They are looking for an experienced UI Developer to work on our web
front-end.

An ideal candidate will know the web development stack from server-
side to JavaScript, be familiar with Django, understand principles of
website performance optimization, and turn out pages that are cross-
browser compatible from the start.

Language: Python + Django, jQuery a bonus

Years of experience: 2-4 years of work experience

Duties: Development of consumer-facing website, maintenance of
existing site, as well as internal-facing projects such as reporting
UIs.

Requirements:
* Intimately familiar with HTML and CSS hacks for cross-browser
compatibility
* Familiarity with modern web paradigms (AJAX and DHTML, etc.)
* Must know how to work with cvs/subversion (Bonus points for already
knowing git)
* Must be familiar with the Unix development environment
* B.A. or higher in CS or equivalent field

To be considered, please submit your resume along with your salary
requirements to beau[AT]open-source-staffing.com

Thank you,

Beau J. Gould
Open Source Staffing
http://open-source-staffing.com
beau[AT]open-source-staffing.com
-- 
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: Design and code review requested for Django string signing / signed cookies

[Karen Tracey]

On Tue, Jan 5, 2010 at 11:53 AM, Elias Torres  wrote:

>
> I'm not a security expert by any means, but I really the fact that
> you're making use of HMACs in your design.
>

There seems to be a key word missing here: really  the fact...

(One might guess based on the rest of the message, but still it might be
nice to know what was intended to go there.)

Karen
-- 

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: Design and code review requested for Django string signing / signed cookies

[Elias Torres]

Simon,

I'm not a security expert by any means, but I really the fact that
you're making use of HMACs in your design. I will ask a good friend
(Ben Adida) who's really an expert on the subject to see if your
paranoia on adding a salt and hashing the key helps you in any way. My
intuition says if the salt will be stored and made available to anyone
with access to the DB, I'm not sure it will make much of a difference.
HMAC takes care of the prefix/suffix attacks already.

Anyway, the main point of my email is to remind folks here that
password management in Django is still not using HMAC-based hashing.
Please read [1] on the matter. I'm currently using Tornado so I used a
couple of methods from Django auth [2] blindly thinking that Django
was doing the right thing and after a friendly code review I was
caught with simple hashing. The good thing is that it was very easy
for me to make a backwards-compatible change to the get_hexdigest()
function:

  if algorithm == 'hmac':
return hmac.new(raw_password, salt, hashlib.sha1).hexdigest()

The nice property of the authentication code path, is that the secret
key is owned by the user logging in and no-one else. Therefore, the
chance of discovering people's passwords with a dump from a Django
application is really small.

[1] http://benlog.com/articles/2008/06/19/dont-hash-secrets/
[2] http://code.djangoproject.com/svn/django/trunk/django/contrib/auth/models.py

Regards,

Elias Torres

On Jan 4, 7:47 am, Simon Willison  wrote:
> I'm pursing expert feedback on the crypto used in Django signing /
> signed cookies. Here's the e-mail I'm sending out to various mailing
> lists. I'll also link to this post from a number of places and see if
> I can get some smart eyes on it that way.
>
> 
>
> Hello,
>
> We've been working to add string signing and signed cookies to the
> core of the Django web framework . We
> have a design and an implementation but we've decided we should get
> some feedback from security experts before adding it to the project.
>
> I'd really appreciate any feedback people can give us on the approach
> we are using. We're planning on adding two APIs to Django - a low-
> level API for signing and checking signatures on strings, and a high-
> level API for setting and reading signed cookies.
>
> The low-level API can be seen here:
>
> http://github.com/simonw/django/blob/signed/django/utils/signed.py
>
> The core signing logic lives in the Signer class on line 89:
>
> http://github.com/simonw/django/blob/signed/django/utils/signed.py#L89
>
> Here are the corresponding unit tests:
>
> http://github.com/simonw/django/blob/signed/tests/regressiontests/uti...
>
> To summarise, the low-level API is used like this:
>
> >>> signer = Signer('my-top-secret-key')
> >>> value = u'Hello world'
> >>> signed_value = signer.sign(value)
> >>> signed_value
>
> 'Hello world:DeYFglqKoK8DLYD0nQijugnZaTc'>>> unsigned_value = 
> signer.unsign(signed_value)
> >>> unsigned_value
>
> u'Hello world'
>
> A few notes on how the code works:
>
> Signing strings
> ---
>
> Actual signatures are generated using hmac/sha1. We encode the
> resulting signature with base64 (rather than the more common
> hexdigest). We do this because the signatures are expected to be used
> in both URLs and cookies, where every character counts. The relevant
> functions are:
>
> def b64_encode(s):
>     return base64.urlsafe_b64encode(s).strip('=')
>
> def base64_hmac(value, key):
>     return b64_encode(
>         (hmac.new(key, value, sha_constructor).digest())
>     )
>
> Picking a key to use for the signature
> --
>
> We've been (I think) pretty paranoid about picking the key used for
> each signature. Every Django installation has a SECRET_KEY setting
> which is designed to be used for this kind of purpose. Rather than use
> the SECRET_KEY directly as the key for signatures, we derive a key for
> each signature based on the SECRET_KEY plus a salt.
>
> We do this because we're worried about attackers abusing a component
> of a Django application that allows them to control what is being
> signed and hence increase their information about the key. I don't
> know if hmac/sha1 can be attacked in this way, but I'm pretty sure
> this is a good idea. If you have any tips as to how I can explain the
> benefits of this in the documentation for the feature they would be
> greatly appreciated!
>
> By default, the key we actually use for the signature (and hence pass
> to the base64_hmac function above) is sha1('signer' + SECRET_KEY +
> salt). 'salt' defaults to the empty string but users will be
> encouraged to provide a salt every time they use the low-level signing
> API - Django functionality that calls it (such as the signed cookie
> implementation) will always use a salt.
>
> Here's the signature method from the Signer class in full:
>
> def signature(self, value, 

Re: idea for using RequestContext by default

[Jacob Kaplan-Moss]

On Tue, Jan 5, 2010 at 9:38 AM, Russell Keith-Magee
 wrote:
> To clarify your position Jacob - are you advocating that
> shortcuts.render() should return a TemplateReponse? Or are you
> suggesting that we add a TemplateResponse *and* a shortcut.render()
> that is an analog of render_to_response, but with a RequestContext?

I don't particularly care how ``render`` works internally -- I'm not
totally sold on ``TemplateResponse``, but I'm also not against it
really. I'm just really sick of
``context_instance=RequestContext(request)``.

Jacob

--

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: idea for using RequestContext by default

[Russell Keith-Magee]

On Tue, Jan 5, 2010 at 11:00 PM, Jacob Kaplan-Moss  wrote:
> On Tue, Jan 5, 2010 at 7:41 AM, Russell Keith-Magee
>  wrote:
>> I haven't taken the temperature of anyone else in the core, but you
>> can take it as read that Simon and myself are both +1. The sprint this
>> weekend would be a great opportunity to advocate for inclusion of
>> this. With a few tests and documentation, Simon's patch could easily
>> be made trunk-ready.
>
> I'm also +1 on something like ``TemplateResponse``, and especially
> ``django.shortcuts.render(request, template, context)``.

To clarify your position Jacob - are you advocating that
shortcuts.render() should return a TemplateReponse? Or are you
suggesting that we add a TemplateResponse *and* a shortcut.render()
that is an analog of render_to_response, but with a RequestContext?

Russ %-)

--

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: idea for using RequestContext by default

[Ben Firshman]

On 5 Jan 2010, at 15:00, Jacob Kaplan-Moss wrote:

> On Tue, Jan 5, 2010 at 7:41 AM, Russell Keith-Magee
>  wrote:
>> I haven't taken the temperature of anyone else in the core, but you
>> can take it as read that Simon and myself are both +1. The sprint  
>> this
>> weekend would be a great opportunity to advocate for inclusion of
>> this. With a few tests and documentation, Simon's patch could easily
>> be made trunk-ready.
>
> I'm also +1 on something like ``TemplateResponse``, and especially
> ``django.shortcuts.render(request, template, context)``.

I ran across a really frustrating problem with TemplateResponse.

TemplateResponses typically get baked by a response middleware because  
that's the first place the content is accessed. However, if there are  
any template errors, you don't see a sensible traceback because pretty  
debug pages aren't shown for exceptions raised in middleware.

Is there any reason why exceptions in middleware aren't handled?

Ben

--

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: idea for using RequestContext by default

[Jacob Kaplan-Moss]

On Tue, Jan 5, 2010 at 7:41 AM, Russell Keith-Magee
 wrote:
> I haven't taken the temperature of anyone else in the core, but you
> can take it as read that Simon and myself are both +1. The sprint this
> weekend would be a great opportunity to advocate for inclusion of
> this. With a few tests and documentation, Simon's patch could easily
> be made trunk-ready.

I'm also +1 on something like ``TemplateResponse``, and especially
``django.shortcuts.render(request, template, context)``.

Jacob

--

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: idea for using RequestContext by default

[Ivan Sagalaev]

Russell Keith-Magee wrote:
> Certainly - and Simon made exactly this proposal during the review of
> the CSRF work. Simon even provided a sample implementation:
> 
> http://groups.google.com/group/django-developers/msg/b1b3f8854b9ae2b1

Thanks! I keep missing nice things on django-dev@ due to many *-dev 
lists traffic :-(

--

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: idea for using RequestContext by default

[Russell Keith-Magee]

On Tue, Jan 5, 2010 at 9:23 PM, Ivan Sagalaev
 wrote:
> Russell Keith-Magee wrote:
>> I'm in complete agreement with Simon on this point. I fail to see the
>> benefit of decorators in this context.
>
> I can see one valid point that "render_to" guys have. Which is,
> incidentally, has nothing to do with the decorator syntax. An
> HttpResponse with an opaque string as its content is hard to alter after
> it is returned from a view (one of the precedents was the old
> CsrfMiddleware was parsing HTML to inject a token). And most of the real
> use-cases for this are about adding something to the view's context
> before it blends in a template. Right now the only way to do it is with
> context processors but they are global, not per-view, which is not
> convenient.
>
> I think it can be solved another way, by something like a special
> HttpResponse subclass -- TemplateResponse. It can keep a template and
> its context separate until the very last moment when its contents is
> asked and only then do render a template.
>
> This will allow extension of the views:
>
>     # some library:
>
>     def library_view(request):
>         # ...
>         return TemplateReponse('template.html', context = { ... })
>
>     # user code:
>
>     def my_view(request):
>         response = library_view(request)
>         response.context.update({ ... })
>         return response
>
> Russel, can you see something like this in Django trunk?

Certainly - and Simon made exactly this proposal during the review of
the CSRF work. Simon even provided a sample implementation:

http://groups.google.com/group/django-developers/msg/b1b3f8854b9ae2b1

(Ignore the bits about the CSRF implementation - the interesting bits
are near the end of the message)

I haven't taken the temperature of anyone else in the core, but you
can take it as read that Simon and myself are both +1. The sprint this
weekend would be a great opportunity to advocate for inclusion of
this. With a few tests and documentation, Simon's patch could easily
be made trunk-ready.

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: idea for using RequestContext by default

[Ivan Sagalaev]

Russell Keith-Magee wrote:
> I'm in complete agreement with Simon on this point. I fail to see the
> benefit of decorators in this context.

I can see one valid point that "render_to" guys have. Which is, 
incidentally, has nothing to do with the decorator syntax. An 
HttpResponse with an opaque string as its content is hard to alter after 
it is returned from a view (one of the precedents was the old 
CsrfMiddleware was parsing HTML to inject a token). And most of the real 
use-cases for this are about adding something to the view's context 
before it blends in a template. Right now the only way to do it is with 
context processors but they are global, not per-view, which is not 
convenient.

I think it can be solved another way, by something like a special 
HttpResponse subclass -- TemplateResponse. It can keep a template and 
its context separate until the very last moment when its contents is 
asked and only then do render a template.

This will allow extension of the views:

 # some library:

 def library_view(request):
 # ...
 return TemplateReponse('template.html', context = { ... })

 # user code:

 def my_view(request):
 response = library_view(request)
 response.context.update({ ... })
 return response

Russel, can you see something like this in Django trunk?

--

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: idea for using RequestContext by default

[Yuri Baburov]

Hi Davor,

On Tue, Jan 5, 2010 at 5:06 PM, rebus_  wrote:
> Hi,
>
> This is the "natural" sequence of doing things anyway, i don't see why
> would you shuffle it around.
>
> 1. process stuff into variables
> 2. add said variables to a ContextRequest
> 3. send said ContextRequest to a template for rendering.
Nothing is shuffled around.
But we came to a bikeshed discussion.
> In the example buttman gave in his link [1] you could say you don't
> even need to specify a template. You could just have a decorator that
> says "this function is a view and when it returns take the name of the
> function and generate template name or even if it is ajax request
> append _ajax to template name". This is however even more implicit,
> though it could save you some typing.
>
> [1] http://github.com/nbv4/flightloggin/blob/master/logbook/views.py
>
>
>> This decorator intercepts `request` argument.
>> When you have 2 or more ways to return anything from function, it
>> looks much better.
>> Moreover, visually it looks much better too: this important
>> information of what page is rendered to each template is always right
>> here.
>
> Personally I don't find this readable at all:
>
> @render_to('my/template.html')
> def my_view(request, param):
>   if param == 'something':
>       return {'data': 'some_data'}
>   elif something_else():
>       return HttpResponse('not found anything at all')
>   else:
>       return {'data': 'some_other_data'}, 'another/template.html'
>
> You explicitly set a template at the beginning of the view but few
> lines after it you mention yet another template.
> When someone is reading your code this could lead to confusion. What
> happens when you need to debug lets say few hundred line view? You
> could even forget that you used another template in it and pull your
> hair out why my/template.html doesn't produce wanted result.
Please, no imaginary arguments.

> Also, it doesn't either look or work much more different then:
>
> def my_view(request, param)
>  template = 'my/template.html'
>  if param == 'something':
>    context = {'some':context}
>  elif something_else():
>    context = {'some_other':context}
>    template = 'another/template.html'
>  return render_to_response(template, context,
> context_instance=RequestContext(request))
Compare to:
@render_to()
def my_view(request, param)
  template = 'my/template.html'
  if param == 'something':
context = {'some':context}
  elif something_else():
context = {'some_other':context}
template = 'another/template.html'
  return context, template

render_to is made to translate
 "return render_to_response(template, context,
context_instance=RequestContext(request))"
into "return context, template".

If you like the longer version, or don't see the difference, what else to talk?

In bikeshed question of what to use, render_to or render_to_response(),
the winner is clearly the smarter render shortcut, proposed in different thread.
"render(template, context, request)".

-- 
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com

--

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: idea for using RequestContext by default

[rebus_]

Hi,

This is the "natural" sequence of doing things anyway, i don't see why
would you shuffle it around.

1. process stuff into variables
2. add said variables to a ContextRequest
3. send said ContextRequest to a template for rendering.

In the example buttman gave in his link [1] you could say you don't
even need to specify a template. You could just have a decorator that
says "this function is a view and when it returns take the name of the
function and generate template name or even if it is ajax request
append _ajax to template name". This is however even more implicit,
though it could save you some typing.

[1] http://github.com/nbv4/flightloggin/blob/master/logbook/views.py


> This decorator intercepts `request` argument.
> When you have 2 or more ways to return anything from function, it
> looks much better.
> Moreover, visually it looks much better too: this important
> information of what page is rendered to each template is always right
> here.

Personally I don't find this readable at all:

@render_to('my/template.html')
def my_view(request, param):
   if param == 'something':
   return {'data': 'some_data'}
   elif something_else():
   return HttpResponse('not found anything at all')
   else:
   return {'data': 'some_other_data'}, 'another/template.html'

You explicitly set a template at the beginning of the view but few
lines after it you mention yet another template.
When someone is reading your code this could lead to confusion. What
happens when you need to debug lets say few hundred line view? You
could even forget that you used another template in it and pull your
hair out why my/template.html doesn't produce wanted result.

Also, it doesn't either look or work much more different then:

def my_view(request, param)
  template = 'my/template.html'
  if param == 'something':
context = {'some':context}
  elif something_else():
context = {'some_other':context}
template = 'another/template.html'
  return render_to_response(template, context,
context_instance=RequestContext(request))

Just my 2 cents,

--
Davor Lučić

--

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.