Re: Deprecation policy for IE6

[Alexander Schepanovski]

IE 7 should be probably dropped with IE6, I can't see point in keeping
it

-- 
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 Error Display Page

[David Cramer]

class EasyWin(object):
  def process_exception(self, request, *args, **kwargs):
if not request.is_ajax(): return
impot traceback
return HttpResponse(traceback.format_exc())


On Jun 10, 1:11 pm, Daniel Watkins 
wrote:
> On Thu, Jun 09, 2011 at 08:31:44PM -0700, Valentin Golev wrote:
> > What I'd really like is a stacktrace in a plain text in the html
> > commentary ("") on the very top of the page.
>
> I've openedhttps://code.djangoproject.com/ticket/16227with patch
> attached.
>
> Regards,
>
> Dan

-- 
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 Error Display Page

[Daniel Watkins]

On Thu, Jun 09, 2011 at 08:31:44PM -0700, Valentin Golev wrote:
> What I'd really like is a stacktrace in a plain text in the html
> commentary ("") on the very top of the page.

I've opened https://code.djangoproject.com/ticket/16227 with patch
attached.


Regards,

Dan

-- 
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: RFC: Templatetag API for form rendering - Second Edition

[Roald de Vries]

Hi Gregor,

On the way home from DjangoCon I realized there is a (IMHO) elegant  
solution to this problem that is closer to the nature of django's  
template language.


What you want with form-rendering is having defaults, but being able  
to override them; which is something you can do with django's  
templates. I think something like the following would be conceptually  
nice:


# in some template
{% with my_form as form %}
  {% include 'my_app/my_form.html' %}
{% endwith %}

# in templates/my_app/my_form.html
{% extends 'form_as_table.html' %}
{% block fieldblock %}
  {% ifequal field.name 'unnecessary_field' %}
{# don't use this field #}
  {% else %}
{{ block.super }}
  {% endifequal %}
{% endblock %}

# in templates/form_as_table.html
{% block form %}
  {% block formerrors %}
...{# formerrors rendered #}
  {% endblock %}
  {% block fields %}
{% for field in form.fields %}
  {% block field %}

  {% block label %}...{# label rendered #}{% endblock  
%}

  
{% block fielderrors %}...{# fielderrors rendered #} 
{% endblock %}
{% block widget %}...{# widged rendered #}{% endblock  
%}

  

  {% endblock %}
{% endfor %}
  {% endblock %}
{% endblock %}

Now this is not ideal in a few ways; as far as I can see:
1) the form rendering has to be done in a separate file, because  
inheritance is needed

2) it would be more elegant if every field-block would have its own name

Django's template language could be extended a little bit (?) to  
improve this:
1) block inheritance -- like a template can extend another template, a  
block could be able to extend another block or template:

{% block form %}
  {% extends 'partial.html' %}{# or extendsblock block.super #}
{% endblock form %}
2) dynamic block names -- like a template name in an {% extends %} tag  
can be either a string or a variable, the same could hold for the  
block name in a {% block %} tag (backward compatibility would have to  
be solved somehow; different tag name/extra argument/...).


This would result in something like (for removing a field):

{% with my_form as form %}
  {% block form %}
{% extends 'form_as_table.html' %}
{% dynamically_named_block 'unnecessary_field' %}
  {# overrides the field with nothing #}
{% enddynamically_named_block %}
  {% endblock %}
{% endwith %}

Note that also the unnecessary_field-block can extend its base block.

Choosing exactly which fields to render could be done like this:

{% with my_form as form %}
  {% block form %}
{% extends 'form_as_table.html' %}
{% block fields %}
  {% for field_name in 'field1 field2 field3'|split %}
{% dynamically_named_block field_name %}
  {{ block.super }}{# refers to the  
dynamically_named_block #}

{% enddynamically_named_block %}
  {% endfor %}
{% endblock fields %}
  {% endblock %}
{% endwith %}

Just brainstorming... let me know what you think.

Cheers, Roald


On Jun 3, 2011, at 4:58 PM, Gregor Müllegger wrote:


Hi,

this is the second RFC regarding template form rendering API/syntax.  
The first
one defined how a complete form or a subset of fields will be  
rendered. I'm
now proposing more tags to render more details like only the label  
of a form

field.

Currently we haven't discussed how we will substitute what we  
currently do

with using::

{{ form.non_field_errors }}
{{ form.errors }}
{{ form.field.errors }}
{{ form.field.help_text }}
{{ form.field.label_tag }}


We will implement these with template tags that are aware of the  
currently

used layout:

Substituting {{ \*.errors }}::

{% formerrors   
%}


Some examples:
Display *all* errors of a form::
{% formerrors my_form %} (equals current {{ my_form.errors }})

Non-field errors::
{% formerrors my_form.non_field_errors %} equals  
{{ my_form.non_field_errors }}


Single-field errors::
{% formerrors my_form.firstname %} equals  
{{ my_form.firstname.errors }}


Basically it will render the error list/dict that is available in  
the *errors*

attribute of the passed in object. As an alternative (e.g. the
non_field_errors) you can pass in directly a error list that gets  
rendered::


{% formerrors my_custom_error_list %}
{% formerrors my_form.field.errors %}


Substituting ``{{ form.field.label_tag }}``

This one might be pretty obvious::
{% formlabel my_form.field %}


Substituting {{ form.field.help_text }}

Also pretty obvious::
{% formhelp my_form.field %}

But the naming is IMO not ideal. {% helptext %} as alternative is  
reasonable,
but Carl and I agreed on that we wanted the tag to start with form*  
but

{% formhelptext %} is to long. So we settled on {% formhelp %}
Better suggestions are welcome.


That's it basically. I don't see any 

Re: Django Error Display Page

[Wim Feijen]

For me, it would definitely be a good idea to change the error page a
bit, so at least the actual error message is not in grey but in black,
and bigger. People tend not to see it right now, because it looks
unimportant.

Wim

-- 
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: Allow disabling choices in a

[Jody McIntyre]

Can a core developer please advise on the preferred design here?

The main ideas are:

1. Add a 'disabled_choices' attribute to the widget that takes an
iterable of choices to disable.  I've attached a WIP patch to ticket
16149 following this approach.  Optionally this could be passed to the
widget by forms.ChoiceField similarly to the way choices is handled
now.

A concern was raised in the ticket (16149) that this is too specific,
and we should also be able to pass arbitrary HTML attributes like
class, style, and id.  I don't understand the use case for passing
these things to an , so I don't think this is worthwhile, but
it's something to consider.

2. Extend the "choices" data structure, as suggested by Calvin
Spealman in the discussion.

Thanks,
Jody

-- 
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.

Logging configuration and handle_uncaught_exception

[Matt Bennett]

For the background to this problem please see my Stack Overflow
question here [1].

I recently had to do some head-scratching over Django 1.3's logging
configuration, because with DEBUG=True the 'django.request' logger
isn't called when an uncaught exception occurs during a request.

It wasn't obvious at all to me that 500 errors are only processed by
the logger when not in debug mode. This behaviour made sense when the
only error processing was to send an email to the site admins, but now
we're free to add more handlers to the logger and may want some of
them to be enabled in development as well as in production.

Is there a reason the call to logger.error can't come before we return
the technical_500_response when DEBUG=True? It seems to me that the
debug level should be checked in each individual handler, rather than
determining whether the error is passed to the logger at all.

Regards,
Matt.


[1] 
http://stackoverflow.com/questions/6305132/django-1-3-logging-500-errors-are-not-logged

-- 
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 Error Display Page

[Stephen Burrows]

On Jun 10, 3:34 am, Dougal Matthews  wrote:
> On Friday, 10 June 2011 at 04:31, Valentin Golev wrote:
> > What I'd really like is a stacktrace in a plain text in the html
> > commentary ("") on the very top of the page.
>
> +1
>
> This would actually be very useful when debugging Ajax calls in browsers. I 
> often find myself reading the HTML particularly in chrome where I think the 
> only other option is to save the file and re-open it.
>
> Dougal

That would be useful for Chrome and Safari, and probably pretty easy
to implement. (For Firefox, I like to use the Modify Headers add-on
[1] and spoof the AJAX request - then I can browse the error page in
its full glory. :-) )

--Stephen

[1] https://addons.mozilla.org/en-us/firefox/addon/modify-headers/

-- 
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: Deprecation policy for IE6

[Tom Evans]

On Fri, Jun 10, 2011 at 12:01 AM, Florian Apolloner
 wrote:
> Hi,
>
> On Jun 9, 1:11 pm, Gert Van Gool  wrote:
>> I remember from the HTML5 doctype that some people (with app in enterprises)
>> need the support
>
> Right, but even Google is dropping support for IE < 8 [1]! And if
> Google is trying to get companies to use newer browsers we should
> support that too ;)
>
> Cheers,
> Florian
>
> 1: 
> http://gmailblog.blogspot.com/2011/06/our-plans-to-support-modern-browsers.html

I don't think we can say 'even google' in this scenario. Google
deprecated those browsers for enterprise customers with no client
communication at all (we certainly didn't get any). Google often takes
a very aggressive approach to things like this, which is fine if you
are google - django is not google!

Having said that, sticking at 1.3 for any projects that require IE 6
admin support is an acceptable compromise.

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-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 Error Display Page

[Dougal Matthews]

On Friday, 10 June 2011 at 04:31, Valentin Golev wrote:

> What I'd really like is a stacktrace in a plain text in the html
> commentary ("") on the very top of the page.

+1

This would actually be very useful when debugging Ajax calls in browsers. I 
often find myself reading the HTML particularly in chrome where I think the 
only other option is to save the file and re-open it.

Dougal 

-- 
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.