Re: RFC: #12815/#12816 -- TemplateResponse and render() shortcut
Just for the record: I'm with Ivan here and think that from django.template.response import TemplateResponse def my_view(request): return TemplateResponse(request, 'foo.html') is worse than from django.shortcuts import render def my_view(request): return render(request, 'foo.html') I think that the cases where user should prefer 'render' returning HttpResponse over 'render' returning TemplateResponse are rare so the API by itself should suggest TemplateResponse. TemplateResponse is more flexible and can provide a performance benefit (the template rendering can be prevented in some cases). I don't see much value in adding 'render' shortcut that just use RequestContext after TemplateResponse is introduced - one can still use render_to_response if TemplateResponse is undesired and one shouldn't use such 'render' in other cases. 'render' as alias for TemplateResponse seems fine for me: it is a shortcut and it adds value by simplifying the API. On 29 ноя, 19:07, Harro wrote: > I agree with Jacob on the bake/baked thing.. but maybe it's just > CakePHP coming to haunt me :S > > On Nov 29, 1:09 pm, Ivan Sagalaev wrote: > > > > > > > > > On 11/29/2010 02:58 PM, Russell Keith-Magee wrote: > > > > My counterargument would be this -- if you use TemplateResponse, > > > there's no need to use a shortcut at all. > > > Yes, this is what I understood from your reasoning. I'm concerned more > > with documentation. Namely, what are we going to suggest for usage in > > the tutorial. The nice short `render()` shortcut lacks the power of > > TemplateResponse and TemplateResponse is not *that* nice and short. -- 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: Need help w/ sql.where.WhereNode tree
On Nov 30, 9:34 pm, "Jonas H." wrote: > Hello List! > > I'm working on queries on embedded objects for Django-nonrel (more > precisely, djangotoolbox) that will use JOIN-like syntax. > > For this, I need to know how to distinguish > .filter(spam__op=eggs, foo__op=bar) > from > .filter(spam__op=eggs).filter(foo__op=bar) > > in the .where tree used in django.db.models.sql.query.Query. > > My first idea was to guess the original query expression from the where > tree's structure, but I suspect that will work out for all kinds of > queries (using Q objects in particular). > > So -- is it possible? How do the SQL backends decide when to do one JOIN > with two SELECTs or two JOINS with one SELECT each? You can take a look at django-dbindexer. It can rewrite JOINs such that they become simple filter calls on the main model. It's part of our automatic denormalization / JOIN emulation code. We haven't yet announced this because the current implementation isn't complete, but it's sufficient if you want to understand how JOINs work. However, you'll also have to change the embedded field, so it behaves like a ForeignKey. Otherwise the ORM won't generate a JOIN for it. In the end JOINs will be a rather complicated solution. I thought that's why you wanted to extend the ORM directly to handle embedded fields in a special way. That should be easier and cleaner. BTW, what were Alex' results regarding embedded objects? Did you discuss any design/implementation ideas? Bye, Waldemar -- 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: Pluggable encryption for django auth (design proposal)
On Tue, Nov 30, 2010 at 4:22 AM, Tom Evans wrote: > First comment is that Django already has a pluggable authentication > stack, which already allows for this - simply define a new auth > backend that tests the password in the manner you wish. My understanding of the pluggable authentication system is that it's for situations where you need a totally different authentication mechanism, such as LDAP. Simply replacing the crypto mechanism for the default authentication system should not require developing a lot of pieces. It is something that needs to be upgraded on an ongoing basis for everyone. It's simply best practices. The federal government already forbids use of SHA-1 after 2010. > It doesn't allow for this with the default authenticator, but it is > doable. I have a django project with >100k users, and none of them > have a sha1 hash as their password. I won't comment on the wisdom of this, but I'd not use it as an example of why we don't need to provide flexibility to improve security. Chris -- | Chris Petrilli | petri...@amber.org -- 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: Need help w/ sql.where.WhereNode tree
On Wed, Dec 1, 2010 at 4:34 AM, Jonas H. wrote: > Hello List! > > I'm working on queries on embedded objects for Django-nonrel (more > precisely, djangotoolbox) that will use JOIN-like syntax. > > For this, I need to know how to distinguish > .filter(spam__op=eggs, foo__op=bar) > from > .filter(spam__op=eggs).filter(foo__op=bar) > > in the .where tree used in django.db.models.sql.query.Query. > > My first idea was to guess the original query expression from the where > tree's structure, but I suspect that will work out for all kinds of queries > (using Q objects in particular). > > So -- is it possible? How do the SQL backends decide when to do one JOIN > with two SELECTs or two JOINS with one SELECT each? The problem here is that this isn't handled purely on the where tree. You need to read the Where tree and the joined table list in concert. The list of tables gives you the table aliases, and the Where tree references those aliases. The SQL backends don't do any evaluation of whether one join or two joins are required; that decision is handled by the way add_q is invoked. The single-filter version turns into a single Q addition to the query; them multiple filter version turns into one add_q call for each filter clause. The use of a single Q clause is what controls the join behavior. You *might* be able to reverse engineer the filter() statements from the where tree plus table list, but it's not going to be trivial, and there aren't any built-in tools to do this. 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.
Need help w/ sql.where.WhereNode tree
Hello List! I'm working on queries on embedded objects for Django-nonrel (more precisely, djangotoolbox) that will use JOIN-like syntax. For this, I need to know how to distinguish .filter(spam__op=eggs, foo__op=bar) from .filter(spam__op=eggs).filter(foo__op=bar) in the .where tree used in django.db.models.sql.query.Query. My first idea was to guess the original query expression from the where tree's structure, but I suspect that will work out for all kinds of queries (using Q objects in particular). So -- is it possible? How do the SQL backends decide when to do one JOIN with two SELECTs or two JOINS with one SELECT each? Thanks! Jonas -- 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: Ticket #7817: Extending "with" and "include" tags.
--- On Tue, 11/30/10, Jacob Kaplan-Moss wrote:
From: Jacob Kaplan-Moss
Subject: Re: Ticket #7817: Extending "with" and "include" tags.
To: django-developers@googlegroups.com
Date: Tuesday, November 30, 2010, 10:38 AM
On Thu, Nov 18, 2010 at 9:47 AM, Russell Keith-Magee
wrote:
> However, given the Unless Jannis is willing to downgrade his -1 to a
> -0, I think a BDFL judgement is called for here.
Let's go with {% with a=foo b=bar %}.
Jacob
--
I have to agree lets go with {% with a=foo b=bar %}
Michael
--
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: Ticket #7817: Extending "with" and "include" tags.
On Thu, Nov 18, 2010 at 9:47 AM, Russell Keith-Magee
wrote:
> However, given the Unless Jannis is willing to downgrade his -1 to a
> -0, I think a BDFL judgement is called for here.
Let's go with {% with a=foo b=bar %}.
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: Django/Python Job
On Mon, Nov 29, 2010 at 9:27 PM, Bita Bita wrote: > My client is in a immediate need for a front end engineer whi knows > Django, Python, AJAX, and/or html5 . This is a full time position with > a really good pay in Palo Alto, CA. Sent me your updated resume if > interested. You're on the wrong group; you want django-users: http://groups.google.com/group/django-users django-developers is for discussion about developing Django itself, not for using it as a web developer. -- 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.
Forms: display_value for BoundFields and widgets
Hello,
This is a proposal related to ticket 10427: Bound field needs an easy
way to get form value [1].
Ticket #10427 is already closed as fixed, but the fix is only partial.
It is now possible to get the value from BoundField, but the value
might be a DB primary key or something else not usable for displaying
to user.
To fix this issue, so that it is possible to render a form in show-
only-data state, I propose two additions:
1. form widgets should receive additional method, display_value(name,
value, attrs=None). This method returns the value given in human
preferred format. For TextInput this would be simply:
%(value)s
For more complex fields, like SelectMultiple, the display_value would
know how to render the values correctly: If values are (1, 3) the
output could be something like:
text_representing_choice_1text_representing_choice_3
2. BoundFields would get additional property display_value, which
would return the BoundField's widget's display_value output.
I am already using a version of Django patched to do this in
production. My own feeling is that this is really useful. So, now I am
asking that if this is
1) Something that would be included in Django core (#10427 suggests
so).
2) Does the approach seem valid.
3) What to do with FileFields.
4) Is the wrapping in tag sensible, or
should it be something else.
The code for my own version can be found from [2], but that code is
not core ready, and it is a bit outdated, especially the tests part of
it.
A few pictures can never hurt my case, so here are some pictures of
actual usage of the display_value. Sorry, the site is implemented in
finnish, but the actual values are not the point... The first one is a
form rendered simply by using a for loop and field.label and
field.display_value. This is used for viewing data, the link "Muokkaa"
in the upper left corner is a edit link.
http://users.tkk.fi/akaariai/Screenshot-7.png
The second picture is what you get when clicking the edit link. This
is rendered with {{ form.as_table }}.
http://users.tkk.fi/akaariai/Screenshot-8.png
It is notable that select multiple fields are handled correctly and
that the "Omistaja" field is actually an autocomplete field which has
a totally different widget than usual select fields. Yet it is really
easy to define display_value method for that widget, too.
In general, this proposal will allow to easily make previews for
forms, implement list - view - edit workflow for websites and in
general to easily show the contents of any model - just define a
ModelForm and display it.
I hope to get some feedback before I start to write a patch for
current Django trunk. The most work will be writing tests for this, so
I would like to get the point 4) above (wrapping in ) correct on
first try.
- Anssi
[1] http://code.djangoproject.com/ticket/10427
[2] https://github.com/akaariai/django/tree/ticket10427
--
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: Pluggable encryption for django auth (design proposal)
On Sun, Nov 28, 2010 at 3:14 AM, Christophe Pettus wrote:
> Hi, all,
>
> Right now, Django's auth system pretty much uses sha1 hardwired in
> (literally, in the case of User.set_password) for the hash. For a discussion
> of why a general-purpose hash function is not the best idea in the world for
> password encryption, see:
>
> http://codahale.com/how-to-safely-store-a-password/
>
> I'd like to propose a backwards-compatible method of allowing different hash
> algorithms to be used, while not adding new dependencies on external
> libraries to the core.
>
> 1. Add a setting DEFAULT_PASSWORD_HASH. This contains the code for the
> algorithm to use; if it is absent, 'sha1' is assumed.
>
> 2. Add a setting PASSWORD_HASH_FUNCTIONS. This is a map of algorithm codes
> to callables; the callable has the same parameters as
> auth.models.get_hexdigest, and return the hex digest its parameters (to allow
> for a single function to handle multiple algorithms, the algorithm aprameter
> to get_hexdigest is retained). For example:
>
> PASSWORD_HASH_FUNCTIONS = { 'bcrypt':
> 'myproject.myapp.bcrypt_hex_digest' }
>
> 3. auth.models.get_hexdigest is modified such that if the algorithm isn't one
> of the ones it knows about, it consults PASSWORD_HASH_FUNCTIONS and uses the
> matching function, if present. If there's no match, it fails as it does
> currently.
>
> 4. User.set_password() is modified to check the value of
> DEFAULT_PASSWORD_HASH, and uses that algorithm if specified; otherwise, it
> uses 'sha1' as it does not. (Optional: Adding the algorithm as a default
> parameter to User.set_password().)
>
> Comments?
>
First comment is that Django already has a pluggable authentication
stack, which already allows for this - simply define a new auth
backend that tests the password in the manner you wish.
It doesn't allow for this with the default authenticator, but it is
doable. I have a django project with >100k users, and none of them
have a sha1 hash as their password.
Cheers
Tom
--
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.
