Thank you, I'll do my best.
среда, 23 июля 2014 г., 18:06:35 UTC+4 пользователь Aymeric Augustin
написал:
>
> Edit - apparently, IE is following suit.
>
> My answer still stands: since there’s no advantage to implementing such an
> API in Django rather than in a third-party library, it should
+1
What they said.
On Wednesday 23 July 2014 23:47:41 Paul McMillan wrote:
> +1
>
> Thanks for your hard work, Aymeric.
>
> -Paul
>
> On Wed, Jul 23, 2014 at 12:25 PM, charettes wrote:
> > +1
> >
> > Thanks for putting this up together Aymeric
> >
> > Simon
> >
> > Le mercredi 23 juillet 2
+1
Thanks for your hard work, Aymeric.
-Paul
On Wed, Jul 23, 2014 at 12:25 PM, charettes wrote:
> +1
>
> Thanks for putting this up together Aymeric
>
> Simon
>
> Le mercredi 23 juillet 2014 09:30:13 UTC-4, Aymeric Augustin a écrit :
>>
>> Hello,
>>
>> I’ve been working on updating our organiza
+1
Thanks for putting this up together Aymeric
Simon
Le mercredi 23 juillet 2014 09:30:13 UTC-4, Aymeric Augustin a écrit :
>
> Hello,
>
> I’ve been working on updating our organization:
> https://github.com/django/django/pull/2947
>
> This proposal attempts to address several issues with our
Looks good, Aymeric!
+1
On Thursday, July 24, 2014 1:30:13 AM UTC+12, Aymeric Augustin wrote:
>
> Hello,
>
> I’ve been working on updating our organization:
> https://github.com/django/django/pull/2947
>
> This proposal attempts to address several issues with our current
> organization. There
+1
Thanks for the hard work you've put into this.
--
Loic
On Jul 23, 2014, at 8:29 PM, Aymeric Augustin
wrote:
> Hello,
>
> I've been working on updating our organization:
> https://github.com/django/django/pull/2947
>
> This proposal attempts to address several issues with our current
>
+1
Carl
On 07/23/2014 07:29 AM, Aymeric Augustin wrote:
> Hello,
>
> I've been working on updating our organization:
> https://github.com/django/django/pull/2947
>
> This proposal attempts to address several issues with our current
> organization. There's no short version and any simplistic
> i
+1.
It might be better to move the more temporal information (team.txt and
roles.txt) to a protected wiki page (or something similar) so there's one
canonical place to view and update that information (rather than the
documentation which has a branch for each release of Django).
On Wednesday,
Edit - apparently, IE is following suit.
My answer still stands: since there’s no advantage to implementing such an API
in Django rather than in a third-party library, it should live as third-party
code first.
--
Aymeric.
On 23 juil. 2014, at 15:56, Aymeric Augustin
wrote:
> Hello,
>
>
Hello,
Before we can consider some code for inclusion into Django, you must
demonstrate widespread use. Since support was announced in Firefox just two
days ago, it’s too early to have that discussion. We don’t even know what IE
will do. Maybe it'll just kill this initiative like it killed DNT.
Matthew, thank you, great idea.
There are already many standard decorators in django.views.decorators.
Maybe the one that redirects to a particular page or just returns 403 HTTP
response in case safe browsing is requested can be useful as well.
среда, 23 июля 2014 г., 17:20:10 UTC+4 пользовател
Hello,
I’ve been working on updating our organization:
https://github.com/django/django/pull/2947
This proposal attempts to address several issues with our current organization.
There’s no short version and any simplistic interpretation will be wrong. Here
are the main factors at play.
1) In
Possibly, write it up as a decorator?
On Wed, Jul 23, 2014 at 9:05 AM, wrote:
> Florian, thank you for your answer.
> I'm totally fine with Request.META['prefer'], it seems to be a
> straightforward solution. However, checking this dictionary in each view
> that supports this feature and also a
Florian, thank you for your answer.
I'm totally fine with Request.META['prefer'], it seems to be a
straightforward solution. However, checking this dictionary in each view
that supports this feature and also adding "Vary: Prefer" to response
headers seems to be a little odd and inconvinient. I t
Hi,
On Wednesday, July 23, 2014 1:58:26 PM UTC+2, S4mmael wrote:
>
> It would be really nice to have some mechanism intended to work with this
> header in Django. A kind of miidleware or a decorator maybe.
>
What's wrong with "if request.META.get('prefer') == 'safe'"?
Cheers,
Florian
--
You
Hello,
"Prefer:Safe" request header is a new feature of IE and Firefox, it is also
implemented in Chromium via plugin. This feature connects parental controls
enabled on Mac OS and Windows with the sites they visit online via their
browser. Web-browser sends HTTP header "Prefer:Safe" to web-applic
I'm not so sure "novalidate" is a viable solution.
If you have a DecimalField and you enter "xxx" this is what happens ...
a) With "novalidate" added to the form:
The value is being removed from the field and the form is being saved
(tested with Firefox and Safari).
b) Without "novalidate":
The
"novalidate" would solve the problem as far as the admin is concerned.
I wasn't very enthusiastic about switching to the HTML5 input types so early;
now that we have them, I'd rather live with them than remove them, probably to
reintroduce them in a later release.
--
Aymeric.
On 23 juil. 20
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 HT
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, a
20 matches
Mail list logo
