#12008 was repurposed as a documentation improvement because the
current implementation is correct and just needs to be explained
better. As for the other two... I agree that consistency is important,
and that it would make sense (in a way) for ConstantIncludeNode to
either always raise or always s
On 03/06/11 17:36, Aymeric Augustin wrote:
> ConstantIncludeNode improves performance because it calls
> django.template.loader.get_template() only once in __init__() and not
> in each call to render().
>
> get_template() invokes the template loading machinery to create a
> compiled Template obje
FWIW: we are successfully using Ned's fix on top of 1.2.5 today. -peter
--
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
On Fri, Jun 3, 2011 at 3:00 PM, Jody McIntyre wrote:
> On Fri, Jun 3, 2011 at 1:09 PM, Calvin Spealman
> wrote:
>>
>> > 1. Backwards compatibility is already addressed. If the widget is
>> > passed a
>> > regular "choices" field, the existing behavior is preserved.
>>
>> Sadly, not true. Any cod
On Fri, Jun 3, 2011 at 1:09 PM, Calvin Spealman wrote:
> > 1. Backwards compatibility is already addressed. If the widget is passed
> a
> > regular "choices" field, the existing behavior is preserved.
>
> Sadly, not true. Any code inspecting the choices is going to break,
> because there is a lot
On Fri, Jun 3, 2011 at 12:50 PM, Jody McIntyre wrote:
> We need to be able to disable choices in a , which is done by
> setting the disabled attribute on the tag, for example:
> Bananas
>
> Currently we're doing this by subclassing the Select widget:
> http://djangosnippets.org/snippets/2453/
>
We need to be able to disable choices in a , which is done by
setting the disabled attribute on the tag, for example:
Bananas
Currently we're doing this by subclassing the Select widget:
http://djangosnippets.org/snippets/2453/
It would be nice if the built in Select widget supported this. One
On 6/3/2011 12:26 PM, Jannis Leidel wrote:
On 03.06.2011, at 04:15, Ned Batchelder wrote:
On 5/29/2011 5:40 AM, Jannis Leidel wrote:
On 15.04.2011, at 15:25, Ned Batchelder wrote:
Hi Ned,
As you say, Jannis has suggested that a Babel-based solution isn't that much
work. But that work hasn
On 3 juin 2011, at 16:44, Luke Plant wrote:
> From what I've seen so far, your proposal sounds good.
I agree — consistency is good.
> Is there a way
> that we can keep the performance benefits of ConstantIncludeNode? For
> example, if an IncludeNode detects that it resolves to the same template
On 03.06.2011, at 04:15, Ned Batchelder wrote:
> On 5/29/2011 5:40 AM, Jannis Leidel wrote:
>> On 15.04.2011, at 15:25, Ned Batchelder wrote:
>>
>> Hi Ned,
>>
>>> As you say, Jannis has suggested that a Babel-based solution isn't that
>>> much work. But that work hasn't been done yet. I don'
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
On 03/06/11 09:04, Tai Lee wrote:
> Could we get a quick vote from any core committers and other
> interested parties, so that we can move forward to fixing and closing
> these tickets?
>From what I've seen so far, your proposal sounds good. Is there a way
that we can keep the performance benefit
On Jun 3, 9:32 pm, Jonathan Slenders
wrote:
> I really never want to have the {% block %} names of B/C in previous
> example to be available for overriding in templates which inherit from
> A. This would even cause unexpected collisions between block names.
> The author of the include B, is not
On 03/06/11 03:31, waylybaye wrote:
> Hi guys, how about add a hook to get_object_or_404 to render a
> template with the same name of model when object does not exist ?
>
> For example:
> user = get_object_or_404(User, pk=pk)
>
> if the user does not exist, get_object_or_404 will try to render "
> This means that it will not be possible to use block tags inside
> includes. This is not possible now, but there is an open ticket that
> would like to make it possible (only for the special case quoted
> string path includes).
It's certainly possible to use {% include %} inside a template. It's
G'day,
There are several open tickets (some getting quite old now) that all
stem from the inconsistent behaviour of the {% include %} tag. When a
quoted string is used for the path, it is treated as a special case
and the include is executed at compile time. Otherwise, it is executed
as the templa
Yes, I always use a try block to give some error messages or render an error
template.
I can do it with a simple helper method . I just think it may be useful for
others :)
2011/6/3 Justin Holmes
> For every convenience method, there are always ways to make it even more
> convenient.
>
> I thin
17 matches
Mail list logo
