Re: on type-specific input fields

[Bruno Renié]

Hi Erik,

I think a more elegant solution than rolling back to TextInput would
be to promote/document the use of the "novalidate" attribute. In a
nutshell, '' disables client-side
validation, letting users submit forms regardless of the client
validation logic while still taking advantage of the HTML5 input
types.

Browsers support doesn't seem to be an issue as browsers which don't
support that attribute (iOS, Android browsers) don't prevent form
submission at all so they already have a "" behavior.

Cheers,
Bruno

On Wed, Jul 23, 2014 at 11:34 AM, Erik Romijn  wrote:
> Hello all,
>
> Since Django 1.6, the Django form fields for URLs, numbers and email 
> addresses make use of widgets that use type-specific input fields in their 
> HTML rendering. So instead of rendering them as , they now 
> have type="url", type="number" and type="email". This has upsides: for 
> example, an email field will cause an iPhone to display the email-optimized 
> keyboard.
>
> However, in #23075[1] sehmaschine raised an important issue: this also causes 
> browsers to apply their own validation to these fields. This causes a number 
> of issues:
>
> * The validation code used by the browser may not match that used in Django. 
> For example, URLField will accept "example.com", but Chrome's validation for 
> type="url" will reject it. Safari on the other hand, does accept it. So there 
> are two validation steps, which may not be equal, and which may differ per 
> browser.
>
> * Error behaviour of browsers is inconsistent. Chrome renders it's own 
> unstylable error message. Safari, according to comment 3, will simply remove 
> invalid values, which is a usability disaster in itself, but avoidable if the 
> field was type="text" as then the form validation would detect the invalid 
> value, reject it, and provide a proper error message.
>
> * Validation timing becomes inconsistent. In the traditional form validation 
> flow, the user would submit the form, see any errors, and submit again. With 
> these fields, some of the validation happens before submit, but some does 
> not. This can be confusing for users.
>
> The workaround is to override the widget in ModelForms or admin forms, and 
> force it to forms.TextInput().
>
>
> If we leave the situation as is, developers may unexpectedly find that their 
> users may get validation errors which are different from all others in 
> content, style and timing (and possibly language), whose criteria do not 
> match other validation steps for the same data, and all this will work 
> differently in different browsers. With the Safari behaviour of simply 
> ignoring invalid values, mentioned by sehmaschine in the ticket, this becomes 
> even more serious.
>
> Therefore, as much as I like using the correct field types, I think their 
> issues outweigh the current benefits. I propose that we change all relevant 
> fields to use forms.TextInput() as their default widget, still allowing a 
> developer to override this with a specific widget if they do want to use 
> type="number". Ideally, considering the potential impact, I'd still like to 
> see this changed in 1.7, although I realise it's very very late for that.
>
> In any case, I thought this might be controversial enough to first bring it 
> up on this list.
>
> cheers,
> Erik
>
>
> [1] https://code.djangoproject.com/ticket/23075
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/6E0F05BE-D767-44B1-9626-3811758C9D31%40solidlinks.nl.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAB4BXAhKnaforSKrUWBKrzT-LXHjU0njJiAVXK3ODHmtRppVfw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: An argument against mark_safe.

[Bruno Renié]

On Thu, Oct 17, 2013 at 10:06 AM, Daniele Procida  wrote:
> On Wed, Oct 16, 2013, Jonathan Slenders  wrote:
>
>>Some people still have javascript in their templates and they use template
>>tags inside their javascript. :(
>
> I am not sure if you're saying this is a bad thing, but it is unavoidable, 
> isn't it? For example I use the Google Maps API, and I don't know of any 
> other way to generate the map items dynamically than to build some of the JS 
> for it using template tags. Is there a problem doing it like this, and is 
> there a better way?

I see at least 2 more robust ways:

* Loading map items in another JSON request or as an embedded JSON
string in a hidden  or something. Then your JS code can
simply JSON.parse() the data and no other code generation is required.

* Using data-attributes that can be parsed using completely static JS
code: . You could
imagine storing map items as DOM elements with data-attributes
attached.

Bruno

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAB4BXAjqtoweb0JG%3DpggtRtP_t5_p1nCZZoHDKBL%3DLxyzorYDg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Proposal: ModelForm API improvements

[Bruno Renié]

Hello,

There was some discussion on the current limitations of the ModelForm
API in the past couple of days on IRC, I'd like to make a proposal to
address some of them.

I wrote django-floppyforms, a library that lets you render forms using
templates instead of python code. It behaves exactly like the Django
forms library, the only difference is the import path. Import
`floppyforms as forms` and when you render a form, the HTML code comes
from templates.

There is still a limitation with ModelForms: since there is no way to
globally override the model field -> form field/widget mapping since
ModelForms fields come from the model definition. I documented this
here:

http://django-floppyforms.readthedocs.org/en/latest/differences.html#modelforms

It is possible to override widgets using the Meta.widgets dict but not
in a way that would switch all the ModelForm's fields to
template-based widgets automatically. The idea is to have custom
ModelForm subclasses with specific strategy on the model field -> form
field mapping.

This is currently possible using something called `formfield_callback`
as a ModelForm class attribute: it is simply a callback that takes a
db field and returns a form field. But this callback is a) private and
b) limited: it gets lost in the inheritance chain as described in
ticket #12915:

https://code.djangoproject.com/ticket/12915

A discussion thread was started a couple of days ago for a design
decision about formfield_callback: should we consider its behaviour as
buggy or leave it as it is? In fact formfield_callback is only used by
the admin, which has custom widgets for pretty much every db field.
This customization is done using the following methods and attributes
(all in django/contrib/admin/options.py):

FORMFIELD_FOR_DBFIELD_DEFAULTS
ModelAdmin.formfield_overrides
ModelAdmin.formfield_for_dbfield(db_field, **kwargs)
ModelAdmin.formfield_for_choicefield(db_field, **kwargs)
ModelAdmin.formfield_for_foreignkey(db_field, **kwargs)
ModelAdmin.formfield_for_manytomany(db_field, **kwargs)

In most cases those methods end up calling formfield() on the DB field
object, with some arguments for customizing the field class (wrongly
called `form_class`) and its constructor arguments (widget, label,
help_text, required, etc).

The arguments to db_field.formfield() are passed via the
formfield_callback function I mentioned earlier.

My proposal is to move that field customization API from the
ModelAdmin class back to ModelForm:

* Move formfield_for_* to ModelForm and document them as public APIs
* Deprecate `formfield_callback`
* Write an AdminModelForm class that implements all the admin form
fields and widgets customization
* Modify ModelAdmin to make use of that base class
* (maybe?) deprecate ModelForm.Meta.widgets in favor of something
similar to the admin's formfield_overrides, which is more generic.

I see the following advantages to this:

* This would allow people to have "site-wide" fields/widgets
overrides, which is a feature that the admin is already proving
useful. Write a nice date picker once, register it for all your
DateFields globally.

* Maintainers of form libraries can ship a base ModelForm class that
implements custom fields/widgets while keeping API compatibility with
Django.

Backwards-compatibility shouldn't be an issue as this touches only a
couple of ModelAdmin methods. Regarding formfield_callback, despite it
being a private API I'm not sure it can be removed safely. There are
references to it on StackOverflow and on the Django bug tracker.

I'm happy to work on a patch if core devs agree to accept this. Thoughts?

Regards,
Bruno

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: dumpdata with custom auth model

[Bruno Renié]

Hello,

On Sat, Nov 24, 2012 at 7:43 AM, Russell Keith-Magee
 wrote:
> Hi Benoit,
>
> Like I said in my last response, I'm *not* seeing the problem. Saying "I'm
> seeing the problem" doesn't help me. Saying "I've got a custom User" doesn't
> help me either -- I've got a custom User (several, actually - a test case
> extending AbstractUser and one extending AbstractBaseUser, plus a of live
> projects using custom user models), and dumpdata is working fine for me on
> all of them.
>
> What I need is a complete project that demonstrates the problem -- the
> minimal set of instructions necessary to reproduce the problem you are
> seeing.
>
> I also need you to tell me what version of trunk you're using. Django 1.5
> hasn't been released yet, so the problem is with a specific revision, not
> with a final release, and since the branch is under constant development,
> the *exact* revision matters.

Out of curiosity I ran 'dumpdata auth' on one of our projects that
uses the 1.5 branch and got the same error. I tried to reproduce it
and it turns out this was fixed very recently, in c8985a8a73 [0].

With Django installed using
https://github.com/django/django/tarball/0a0a0d66b3 -> error on
'manage.py dumpdata auth'

With Django installed using
https://github.com/django/django/tarball/c8985a8a73 -> no error.

Christian, Benoit: could you try again using a recent tarball of the 1.5 branch?

Russel: thanks for your work on this feature, which is already proving
very useful for us :)

Regards,
Bruno

[0] https://github.com/django/django/commit/c8985a8a73

> On Fri, Nov 23, 2012 at 5:33 PM, Benoit Petit 
> wrote:
>>
>> I have the same issue with django 1.5. I have a custom User model that
>> extends AbstractUser.
>>
>> Regards
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msg/django-developers/-/VFhbHqt6P4cJ.
>>
>> To post to this group, send email to django-developers@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-developers@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-developers@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: proposal: post-collectstatic signal

[Bruno Renié]

On Sun, Nov 11, 2012 at 5:09 PM, Justin Holmes  wrote:
> My sense is that there are a growing number of use cases, but the one that I
> currently have in mind is for django-coldbrew.  I want to be able to
> compile all the coffeescript in a project during the collectstatic process.
> Currently, we have a management command, "collect_coldbrew" - but I'd like
> to allow users to have this occur automatically during collectstatic.

In this case it seems you could just override the collectstatic
command. That's what contrib.staticfiles does with runserver, which is
a core command that gets overridden when you add the staticfiles app
to your INSTALLED_APPS.

>From the get_commands [0] code it looks like the last app in
INSTALLED_APPS takes precedence, so adding 'coldbrew' after
`staticfiles` in INSTALLED_APPS would override the default
collectstatic command with coldbrew's extended version.

[0] 
https://github.com/django/django/blob/master/django/core/management/__init__.py#L79-123

Bruno

> I'm not sure if the best timing for the signal is at the end of the complete
> collectstatic process or at the end of each iteration (ie, one signal for
> each static directory that django finds).
>
>
>
> On Sun, Nov 11, 2012 at 4:55 AM, Alex Gaynor  wrote:
>>
>> What's the use case?
>>
>> Alex
>>
>>
>> On Sat, Nov 10, 2012 at 8:48 PM, Justin Holmes 
>> wrote:
>>>
>>> Currently, our only built-in management signal is post-syncdb.
>>>
>>> I propose (and, notwithstanding objection, will build)
>>> post-collectstatic.
>>>
>>> Is this reasonable?  Is there another, less invasive way to hook logic
>>> into collectstatic?
>>>
>>>
>>> --
>>> Justin Holmes
>>> Chief Chocobo Breeder, slashRoot
>>>
>>> slashRoot: Coffee House and Tech Dojo
>>> New Paltz, NY 12561
>>> 845.633.8330
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Django developers" group.
>>> To post to this group, send email to django-developers@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.
>>
>>
>>
>>
>> --
>> "I disapprove of what you say, but I will defend to the death your right
>> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
>> "The people's good is the highest law." -- Cicero
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To post to this group, send email to django-developers@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.
>
>
>
>
> --
> Justin Holmes
> Chief Chocobo Breeder, slashRoot
>
> slashRoot: Coffee House and Tech Dojo
> New Paltz, NY 12561
> 845.633.8330
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@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-developers@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: Custom user models don't like non integer primary keys.

[Bruno Renié]

On Wed, Nov 7, 2012 at 12:06 AM, Russell Keith-Magee
 wrote:
> Hi Eric,
>
> Although the full stack trace would confirm it, I think I can guess what the
> problem is here -- it's the mechanism for generating reset tokens.
>
> If you dig into the token generation (and reversal) mechanisms, they use
> int_to_base36 and base36_to_int to convert the user's primary key into
> something that can be used as a reversible, text-based identifier of the
> user object that isn't the literal identifier itself. This identifier is
> then used as part of the password reset token (along with a timestamp
> component and a component based on the last login timestamp)
>
> A base36 encoding of an integer produces a nice reversible alphanumeric
> representation of the integer primary key that can be used in this reset
> token.
>
> So, yes -- non-integer primary keys will have a problem with any of the
> password reset or account activation logic. These should (he says,
> hopefully) be the only views that are affected.
>
> One of the big features for Django 1.5 is the introduction of swappable user
> models. However, even with that change, we've maintained the requirement
> that the User model has an integer primary key
>
> That said, I'm not personally opposed to dropping this requirement -- we
> just need to find a way to abstract the PK-dependent tokenization part in a
> useful way. As an initial thought, this is something that we could abstract
> out to the token generator API; the token generator is already customisable
> in the password reset views. However, I'm certainly open to other
> approaches.

The token generator API looks very similar to the cryptographic
signing API. The password reset views can be updated to use signing
instead. In fact I rewrote the password reset views using class-based
views and signing [0] and they ended up working very well even when
using an external authentication system instead of contrib.auth. I
also got rid of the base36 conversion in the process but this could be
added back with customization hooks.

It seems the auth views could benefit from such a conversion.

[0] http://pypi.python.org/pypi/django-password-reset

Bruno

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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 people: impossible to sign up ?

[Bruno Renié]

Hi Michael,

On Thu, Aug 2, 2012 at 9:16 PM, Michael  wrote:
> Hi,
>
> Since Django People  is hosted on the djangoproject.com website:
> https://people.djangoproject.com/signup/, I thought it would be a good place
> to ask my question. If not, sorry for that.
> I have an issue to sign up. I actually can't.
> I tried with several browsers and when I hit the "sign me up" button, I can
> see something is going on but the page is loading again and I have not been
> signed up.

Can you create an issue on the github repo?

https://github.com/brutasse/djangopeople/issues/new

If you could include more details using a debugger that'd be great:
the failing POST data (obfuscating your password), the actual response
if you get any…

Thanks,
Bruno

> Does anyone have the same issue?
>
> Thanks.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/q4yr7Yax02gJ.
> To post to this group, send email to django-developers@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-developers@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: Glad site is being brought back.

[Bruno Renié]

On Wed, May 30, 2012 at 10:30 PM, Daniel Sokolowski
 wrote:
> Please disregard this message, it was meant as a reply to a thread not a new
> thread.
>
> -Original Message- From: Daniel Sokolowski
> Sent: Wednesday, May 30, 2012 12:35 PM
> To: Django developers
> Subject: Glad site is being brought back.
>
>
> I was just about to post a public message to Simon Willison urging him
> to shut it down or fix the site when I found this thread.
>
> I wish to say thank you and am very grateful that you are fixing and
> bringing the service back.
>
> On unrelated note would it be possible to change my username on the
> site from: djangopeople.net/danols/ to djangopeople.net/
> danielsokolowski/ ?

As announced on the Django weblog, people.djangoproject.com is live :)

The code currently lives on my github account [0]. Feel free to submit
issues and pull requests if you have ideas for improvements on the
site. I'll look at renaming usernames, in the meantime if you need
anything custom just get in touch privately.

Bruno

[0] https://github.com/brutasse/djangopeople

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: Djangopeople.net status

[Bruno Renié]

On Sat, May 19, 2012 at 3:46 PM, Will Hardy  wrote:
> Seeing as we have to deal with a stale data issue anyway, I thought I
> would throw an idea into the mix.
>
> I think it'd be nice to have something where the data is a little more
> open, allowing anyone to create an index of developers. For example,
> each developer who wants to be index sticks a json file somewhere
> online with loosely standard information: who they are, whether or not
> they are currently available, where they are happy to work, what their
> relevant interests are, some experience and links to
> github/twitter/etc accounts.
>
> This way, a developer would need only update the file and the changes
> would propagate to whatever index others have built. For employers, it
> means the index only contains people clever enough to put a json file
> on their website/github/etc :-)
>
> There are of course no doubt issues with this (verification etc), but
> I thought I would mention a worthy goal. At the very least,
> people.djangoproject.com could provide a simple API, in effect hosting
> such information and letting others build fancy indicies. As someone
> who is looking for competent developers, I'd be happy to work on this
> if others find it useful.

Hi,

Quick update, the data issue has been resolved and we're working on
the deployment of the new site. The infrastructure should be ready in
a couple of days.

If people are interested in playing with new ideas, the code is on
github and should contain all the information to get started:

https://github.com/brutasse/djangopeople

Bruno

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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.contrib.auth.models.get_hexdigest missing in 1.4

[Bruno Renié]

Hi,

On Sun, May 13, 2012 at 3:08 PM, Shai Berger  wrote:
> Hi,
>
> In the process of upgrading to Django 1.4, I've run into a little problem: one
> of our files uses django.contrib.auth.models.get_hexdigest, which is no longer
> present.
>
> I searched, and could find no mention of this in release notes, tickets, or 
> the
> developers group.
>
> Was this, for some reason, not considered a public API?

It isn't documented so I believe it has never been part of the public API.

> Of course, I can copy the function from a 1.3 installation and use that, but I
> suspect that if it was removed, there was a good reason -- and I'd like to
> know what it was, before deciding to ignore it...

Django 1.4 added pluggable password hashers and this was all
abstracted in django.contrib.auth.hashers. If you need to deal with
passwords use make_password and check_password from this module:

https://docs.djangoproject.com/en/dev/topics/auth/#manually-managing-a-user-s-password

Regards,
Bruno

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: Djangopeople.net status

[Bruno Renié]

On Thu, May 10, 2012 at 8:04 AM, Russell Keith-Magee
 wrote:
> On Thu, May 10, 2012 at 9:19 AM, Aaron C. de Bruyn  wrote:
>> On Wed, May 9, 2012 at 1:37 PM, Alex Sosnovskiy  wrote:
 https://convore.com/djangopeoplenet-development/ - gives http404
>>>
>>> Djangopeople.net is dead?
>>>
>>> If to be honest I don't understand you, guys! What's the profit of rewriting
>>> views to class-based if djangopeople.net is down for a year ?

That's because the rewritten code has never been deployed.

>> Look at the whois record for djangoproject.com verses
>> djangopeople.net.  I don't think djangopeople.net is officially part
>> of Django.
>
> I can confirm for you -- djangopeople.net has never been an "official"
> part of the Django project. It was always an effort run outside of the
> official  (although Simon, the original developer, is a Django core
> developer).
>
> That said, I'm still interested in making djangopeople.net an official
> resource of the Django project. It was a very useful resource in it's
> time, which I for one miss. If anyone is interested (including Bruno,
> if he's still interested) in managing the project for the long term,
> let me know.

I am still interested, the issue right now is to get admin access to
the djangopeople.net DNS records and an up-to-date dump of the data.
Regarding that, Simon Willison is pretty hard to reach and the best
way to contact him is via Andew Godwin who can talk to him IRL. But as
you may know, they're both busy people so that's why we're in the
current situation.

There is also the issue of hosting, at the time Andrew was happy to
host the rebirth of djangopeople.net on ep.io but since it's closing
down we'd have to find another option.

Regards,
Bruno

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: auth.user refactor: the profile aproach

[Bruno Renié]

Hi Jacob,

Thanks for taking the time to tackle this issue!

On Tue, Apr 3, 2012 at 2:35 AM, Jacob Kaplan-Moss  wrote:
> Hi folks --
>
> I've written up a proposal for how *I* would like to address refactoring
> auth.user: https://gist.github.com/2245327.
>
> In essence, this does two things:
>
> * Vastly "prunes" the required fields on auth.user. The only things left are
> an "identifier" (which could be username, email, url, uuid, whatever), and a
> password.
> * Introduces a new "profile" system that provides a way to contribute extra
> related fields. Multiple profiles are supported, along with some syntactic
> sugar for dealing with multiple profiles in a reasonably reusable way.

I very much like the idea of stripping down the user fields. I am
currently using an approach that's very similar to your proposal in
all my projects, except that instead of creating several profiles, I
directly add fields to the User model using this snippet:

https://gist.github.com/1283969 (I am not the initial author)

With this, adding a field to the user model is as simple as:

class MyUser(models.Model):
newsletter = models.BooleanField()

class Meta:
abstract = True
contribute_to_model(MyUser, User)

I already use this to patch the email field in the User model or make
group names not unique for instance.

The only issue is that the contributed models need to be registered as
early as possible. Currently I import them in my urls.py, but we can
imagine adding hooks for such things that need to be done at startup
time (app-refactor? :) or use your AUTH_PROFILES setting for this (not
enthusiastic about this one).

I am fully aware that this can be abused a lot. However this makes a
couple of things simpler:

* No need to proxy fields on the User model, it stays a normal model
with no special treatment
* Conflicts are simply resolved: if two models contribute the same
field, the last one registered wins
* No need for a special-cased form for editing profile-related fields,
a simple ModelForm with includes = ['fields', 'to', 'include'] works.

This is the technique I will use anyway if your proposal is
implemented, and I don't see anything that would prevent this from
working with the new auth so I'm mainly posting this because I haven't
seen this approach in the different proposals for the auth refactor.

-Bruno

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: Addition of failed login signal

[Bruno Renié]

On Sun, Jan 15, 2012 at 7:06 AM, Darren Spruell  wrote:
> Greetings,
>
> As an enhancement to the existing collection of signals I wanted to
> propose the addition of a signal for the event of an unsuccessful
> login. Currently django.contrib.auth supports user_logged_in and
> user_logged_out for successful events. Addition of e.g.
> user_failed_login would allow this event to be handled. I'm interested
> in logging this as a security event for the application. I've seen
> past discussions on the topic of implementing protection against
> password guessing attacks. It seems to me that at least having the
> signal available would then give some basis for developers to flexibly
> implement customized approaches for handling and responding to login
> failures.
>
> I've been advised that I can reach some form of similar functionality
> by subclassing the auth backend. Does the new signal approach have
> merit?

To me subclassing the auth backend is nicer than a signal, more
explicit. Furthermore, adding a signal to the default backend would
provide very limited information about the attacker since ModelBackend
only "knows" the username/password combination. In the context of a
brute-force attack it's not enough, since you need to take action
against a specific *attacker* without blocking the whole user account
and legitimate login attempts.

To adress this issue (apologies for the plug) I wrote
django-ratelimit-backend [0], which is basically a request-aware
authentication backend and a bunch of helpers for login forms, login
views and the admin.

I wouldn't mind seeing it added to Django itself but this topic has
been discussed several times before, with the conclusion that
solutions and use cases are often too specific, hence a generic
solution would be hard to add to Django core.

Regards,
Bruno

[0] https://github.com/brutasse/django-ratelimit-backend

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: Djangopeople.net status

[Bruno Renié]

On Fri, Jul 15, 2011 at 1:22 PM, Subhranath Chunder
 wrote:
> Hi,
> I'm very much interested to help. Please tell me, from where and how to get
> started.
> Thanks,
> Subhranath Chunder.

Hi Subhranath,

I've been contacted by a couple of people so I'll post publicly here
what I tell them :)

We have a wiki page [0] on GitHub that summarizes everything.
Basically everyone can suggest ideas and pick tasks, but to avoid
conflicting work I'd recommend having a chat before, either on IRC
(#djangopeople.net on freenode) or on the Convore group [1]. It's far
easier to reach me on IRC, though.

Thanks,
Bruno

[0] https://github.com/brutasse/djangopeople.net/wiki
[1] https://convore.com/djangopeoplenet-development/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: Djangopeople.net status

[Bruno Renié]

On Wed, Jul 13, 2011 at 5:49 PM, Yonsy Manuel Solis Ponce
 wrote:
> well, i am interested to help
> we need to fork in github from https://github.com/brutasse/djangopeople.net
> ?

Yes, the fork tree is slightly confusing but this repo contains all
the work that's been done recently. There is also a wiki page with
different tasks listed, feel free to add your ideas and choose a task!

Bruno

> --
> Yonsy Solis
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/jsu-jhCvDmoJ.
> To post to this group, send email to django-developers@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-developers@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.

Djangopeople.net status

[Bruno Renié]

Hi fellow Django devs,

I'd like to talk about a site that all of you probably know: djangopeople.net.

The site has originally been developed by Simon Willison and Natalie
Downe and is a very useful part of the different sites connecting the
Django community. Recently, however, Simon and Natalie became too busy
to handle the maintenance work and, with the site going down every now
and then, people started to worry about its future. I read at some
point that Simon had more or less agreed to let other people run the
site, but there wasn't any volunteer I was aware of.

Given that the source code is on github, we started with Dan Fairs and
Filip Jukić to work on the codebase: updating to Django 1.3 and the
practices and conventions that have emerged since 2009. This is still
a work in progress but the result can be seen on the github repo:
https://github.com/brutasse/djangopeople.net.

At this year's EuroPython, we talked about this with Jannis, Andrew
and Simon. The result of the chat was that Simon is willing to let the
DSF run djangopeople.net as part of its infrastructure and the DSF now
has a database dump of djangopeople.net. The idea is now to make this
a more open project: with Dan and Filip, we haven't very much
advertised our work since we were not sure where we were going. Now
we'd like to help the DSF run the site and make it evolve with a very
high bus factor.

To that end, we'd love to hear from anyone willing to help us with the
site, from writing code to suggesting new features and improvements.
Maybe it could be interesting to team with the djangopeople.me crew as
well :)

Assuming the DSF lets us handle djangopeople.net, the next steps would
be to get the data and load it on a django-frienly host (I have an
ep.io app running the updated codebase). The purpose of this email is
to make more official the fact that there's a group of people working
on it, and that more group members are welcome :).

Regards,
Bruno

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: Form Rendering API Proposal

[Bruno Renié]

Hi all,

On Fri, Jun 24, 2011 at 12:38 PM, Gregor Müllegger  wrote:
> Hi Jacob,
>
> 2011/6/23 Jacob Kaplan-Moss :
>> Hi Idan et al. --
>>
>> Thanks for putting this all together!
>>
>> In general, I like this a lot, and I'm always going to defer to the
>> eyes of someone like Idan who spends more time wrangling templates
>> than I do. So I like the general gist, and I most don't mind the {%
>> formconfig %} business.
>>
>> However, I do have a few concerns:
>>
>> 1. Performance: it looks, to me, like rending a basic form is going to
>> cause dozens of template includes and dozens of sub-renders (the form
>> loads a form template which loads row templates which load widget
>> templates). That's dozens of disk hits, and a lot of overhead for form
>> rendering. I worry about this overhead a lot. Django's performance has
>> slipped lately, and I'm really afraid this'll make things a lot worse.
>>
>> So I'm going to need to see some benchmarks -- particularly in how a
>> simple {% form myform %} compares to {{ form.as_* }}.
>>
>> The wrong performance benchmarks could result in a veto from me; this
>> is important.
>
> Unfortunatelly we don't have any implementation yet, except of what Bruno did
> with floppyforms, what we can benchmark. But I think we could minimize disk
> hits or template-loader work by caching the rendered templates ourself. For a
> form with many fields it's very likely that most of them use the same row
> level template, so we can reuse this a couple of times during the rendering. I
> will do my best to make things as fast as possible. Benchmark was not yet part
> of my GSoC timeline but I agree that this should have a high priority.

Someone did a couple of benchmarks to measure the performance impact
of my patch (#15667, the template-widgets implementation aka
django-floppyforms). There is some slowdown, the question is whether
it's acceptable or not, and where's the limit. If you have simple
forms, they'll render in 6 milliseconds instead of 3.5. However, with
fields with lots of choices, this gets much worse. Something that
takes 32 milliseconds with the current forms implementation can take
almost 200 milliseconds to render if it's done in the templates. The
biggest part of this time is spent actually rendering the templates,
not loading them. So template caching helps but only to a limited
extent.

Also see on the ticket page, there are a couple of pretty graphs that
show exactly where time is spent. For instance, 12% of the rendering
time is spent doing isinstance() calls, that's part of the template
rendering logic.

I did the same benchmarks with pypy, and the results are interesting.
Raw results are here, for some context see the files attached to the
ticket:

http://dpaste.com/hold/558425/

So, currently I see how it can be a problem to have this as the only
widget rendering system. I don't think it's worth maintaining both
implementation (the current one and the template one) with ways to
switch from one way to another, it's going to be too much of a burden
to maintain.

When the template language gets faster, maybe we can integrate my
patch. The question is, what slowdown is acceptable? Or are we
expecting a speedup? With jinja2, widget rendering is actually
*faster* using templates than using the current string-based
implementation but I'm not sure we can go this far with django
templates. So:

* We need faster templates for this to land in trunk
* We need pypy :)
* If you want template-base widgets *now*, use django-floppyforms.
* If you want to use the new forms / templates API as soon as it's
done… how do you do it? Is it going to be packaged as an app, as a
patched version of django?

That being said, I really like the design work that's been done and I
look forward to trying it.

-Bruno

> However based on the feedback I got on djangocon and on the mailinglist yet,
> the anticipation for this feature is really big. And we won't make code slower
> that already exists. You only get a bit slower form rendering if you are going
> to use the new mechanics, but you trade that for a much more flexible and
> faster template designing. And as Benoît described in the current thread: Most
> designers already use something like the proposal suggests but with a custom
> {% include %} hierachy. Introducing a "special" syntax can only open up the
> possibilities for performance tweaking.
>
>>
>> 2. Verbosity: There's a lot of tags (well, 4, but that's a lot to me)
>> wall-of-code stuff like
>> https://github.com/idangazit/formrendering/blob/master/djangocon_sketch.html#L62-83
>> doesn't particularly give me the warm fuzzies. I think  part of the
>> problem is that all the tags are `form*` which makes for a bit of
>> "bork bork bork" there.
>>
>> I think it might be possible to simplify things somewhat here, so
>> here's my rough thoughts:
>>
>> * Keep {% form %} -- it's obvious.
>> * Rename {% formfield %} to {% field %} -- it won't conflict, 

Re: RFC: Templatetag API for form rendering

[Bruno Renié]

Hi,

I like the API and I'm looking forward to this. Just a small comment
on the {% widget %} tag:

On Sun, May 22, 2011 at 10:21 PM, Gregor Müllegger  wrote:
> (You can read this RFC online if you prefer:
> https://github.com/gregmuellegger/gsoc2011-stuff/blob/master/rfc_syntax.rst )

>    {% widget [] [using ] for
>  [with = ...] %}
>
> In this syntax description  means that you can specify one of
> three things as argument:

We just had a chat about the {% widget %} tag on IRC, it would be
useful to let template authors add attributes to the widget without
having to alter the template *and* add a context variable. Something
like:

{% widget field width foo="bar" attrs placeholder="john.sm...@example.com" %}

Instead of {% widget field with boo="bar" placehodler="..." using
"some_template.html" %} and having to copy the default template to add
the placeholder next to the attrs.

The 'with' keyword would be used to add template variables, the
'attrs' keyword to add new attributes. The content of the context and
the attrs also needs to be checked: switching the input type or the
placeholder from the template is safe, I think but people shouldn't be
able to overwrite the input name for instance. There needs to be a
clear separation between what can be touched and what can't.

For the record, in my work on template widgets, the input's "name",
"value" and "type" are passed directly in the template context, not in
the attrs dict (which contains only the id by default). We chose to be
explicit but people may expect a different behaviour :)

Cheers,
Bruno

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: Read-only forms and DataBrowse

[Bruno Renié]

On Thu, Apr 7, 2011 at 3:23 PM, akaariai  wrote:
> About the read-only forms part of the proposal: read-only forms will
> be easy to implement if the template widget rendering idea will be
> included in core.
>
> For example for SelectMultiple widget the base template is probably
> something like this:
>
> 
> {% for choice in choices %}
>   {% if choice.selected %}
>       {{choice}} option>
>   {% else %}
>       {{choice}}
>   {% endif %}
> {% endfor %}
> 
>
> If you want a read-only widget, just give it a custom template:
>
> 
> {% for choice in choices %}
>    {% if choice.selected %}
>        {{choice}}
>    {% endif %}
> {% endfor %}
> 
>
> Now, that was easy :) Combined with template based form rendering, it
> would be relatively easy to implement read-only forms. Another reason
> why template based form/widget rendering would be nice to have in
> core.
>
> By the way, it would be nice to see how the template based rendering
> compares to python based rendering in performance terms when rendering
> a larger list of choices. But on the other hand, if you have a large
> Select/SelectMultiple list there is bound to be some usability issues,
> so maybe the performance isn't that important... Sorry for bringing
> performance up here again, but I am a speed freak :)

If you want to play with template-based widgets and benchmarks, feel
free to look at my github fork [0]. This is where I'm implementing
template-based widgets (http://code.djangoproject.com/ticket/15667)
and I added a few metrics in the last & only commit message. Timing
the forms regressiontests gives this (network calls excluded):

 * No template caching: Ran 402 tests in 2.395s
 * Template caching: Ran 402 tests in 1.413s
 * Old string-based method: Ran 402 tests in 0.864s

If you're interested in measuring the impacts in more details, feel
free to dig and write benchmarks. I'm sure this would result in some
valuable information. I haven't converted the admin widgets yet but
measuring the effect on the admin test suite would also show the
impact on real-world applications.

Bruno

[0] https://github.com/brutasse/django/commits/15667-template-widgets

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: Proposal: template-based widget rendering

[Bruno Renié]

Hi Carl,

On Tue, Mar 15, 2011 at 6:59 AM, Carl Meyer  wrote:
>
> As we've already discussed here at PyCon, I'm +1 on this change. It
> makes forms far more flexible and usable by template authors, and I
> think that will benefit almost all Django users. It's more consistent
> with Django's philosophy that presentation issues should be accessible
> to template designers who are not necessarily Python programmers.
>
> There is the speed tradeoff, and I sure hate to do anything that we know
> is slower. But I feel like this is a case of "do it right, then make it
> fast" - and I just think this is clearly the right way to do it.
> Probably the right way to make it fast is to make the template engine
> fast (Alex Gaynor had some interesting proposals for that for last
> year's GSoC, though it got dropped in favor of the no-SQL stuff). In
> absolute terms, I think the speed difference is already small enough
> that only a small fraction of users will be impacted by it, and they
> would always have the option to replace the default widgets in their
> forms with their own faster versions.
>
> The auto-escaping is another significant advantage - it's quite easy to
> forget to escape something that should be escaped in a custom widget (we
> had such a bug in Django itself until the latest security release), and
> I think it can only be good for security to discourage people ever
> building HTML strings in Python code.
>
> I already use floppyforms on all projects, and don't have any issues
> with the widget API it provides.
>
>> This could be part of a broader change related to form rendering (e.g.
>> fieldsets, looping over fields, etc) but I haven't thought about this
>> enough to have a concrete proposal. For more information, see that
>> discussion that happened at Djangocon:
>>
>> https://github.com/SmileyChris/django-forms/wiki/Django-form-API-ideas
>
> Although these proposals are related, and will involve some similar
> changes (i.e. the need to be able to load default form templates), I
> think the broader questions about form-rendering tags still need more
> work, and converting the built-in widgets to use templates doesn't need
> to be delayed while we hammer all of that out.

With 1.3 out (yay!), I just created a ticket to track the progress on this:

http://code.djangoproject.com/ticket/15667

I'm working on a patch, I'll attach it to the ticket as soon as I'm
happy with the widgets code and the regression tests pass again.

I'm not sure, however, how django's backwards-compatibility applies in
this case. The widgets API has never been publicly documented but the
official documentation encourages people to look at the code and
create their own widgets based on it. Is it fine to touch some
internal methods like build_attrs()? There will be some minor
differences in the rendered code, with things like the order of
attributes (name='foo' id='bar' versus id='bar' name='foo') and
linebreaks (I have an EOL at the end of every template so each widget
gets a "\n" at its end).

Currently the base `Widget` class has a render() method that raises
NotImplemented. I think the rendering logic should happen here, the
base Widget class should accept a template_name attribute and a
render() method that renders the template. This way there is (almost)
no need to touch any widget's render() method since template_name and
get_context_data provide the needed extension points.

I'll post some updates here and on the ticket, in the meantime I'm
open to comments and suggestions.

Regards,
Bruno

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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.

Proposal: template-based widget rendering

[Bruno Renié]

Hi django devs,

Although Django 1.3 is not released yet I'd like to take advantage of
the pycon sprints to discuss a proposal for 1.4: render form widgets
using Django templates instead of python code.

This approach is implemented in django-floppyforms [0] (I'm the
author): each widget gets a template_name argument, and the render
method of each widget renders this template. Floppyforms also provides
hooks to inject data in the template context, making it quite easy to
implement custom widgets: add some context data, define a custom
template and you're done.

This approach has a couple of advantages and drawbacks.

Advantages:

 - Templates give you escaping for free, giving us better protection against XSS
 - Template authors can alter widget rendering more easily
 - This would also fix the "how do I specify my own doctype?" issue:
Django can provide XHTML-style  elements and people can switch
to html4-style s by providing their own set of templates.

Drawbacks:

 - Template rendering is slower than string interpolation. There is a
benchmark in the floppyforms source tree, for a simple form the
rendering takes 9 milliseconds instead of 1.5 milliseconds. With
template caching enabled, it drops to 3 milliseconds. It still takes
no time but I can see it being an issue.
 - We need to add a template loader to provide the default form
templates without asking the users to add 'django.forms' to their
INSTALLED_APPS.

Backwards-compatibility is not going to be a big issue: the default
templates can implement django's current behaviour.

We've been discussing it with Jannis and Carl and I'm trying to start
a broader discussion. A side-effect of such a change would be to make
the widgets API public and provide hooks for customization. In
floppyforms I've been trying to follow the same conventions as the
class-based views, using template_name and get_context_data as
extension points.

I'm happy to work on the patch and convert the admin widgets but I'd
like to hear people's voices about:

1) If such a change is desired, and how we can make it faster,
2) how the API should differ from floppyforms,
3) make sure no significant use case is forgotten.

This could be part of a broader change related to form rendering (e.g.
fieldsets, looping over fields, etc) but I haven't thought about this
enough to have a concrete proposal. For more information, see that
discussion that happened at Djangocon:

https://github.com/SmileyChris/django-forms/wiki/Django-form-API-ideas

Regards,
Bruno

[0] https://github.com/brutasse/django-floppyforms

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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.