Letting Library.simple_tag access context (code ready)

[Leaf]

Out of necessity, I've made a modification to my Django trunk. It
gives a parameter to the Library.simple_tag() function named
takes_context. This works like the takes_context on
Library.inclusion_tag() - it gives the tag the context. So far, I've
done manual tests on it for:

+ Accepting the context (and sub-rendering a template)
+ Writing to the context
+ Taking arguments that aren't the context
+ Allowing tags created with simple_tag to function as normal if
takes_context is not set

It seems to work perfectly so far, but I'm sure you will want to test
it as well. I've uploaded the code to Django Snippets (see
http://www.djangosnippets.org/snippets/1089/ ) for easy access. If
you're fine with it, I'd like for it to be integrated into the trunk.

Regards,
Leaf

[Julien Phalip]

On Sep 28, 4:20 am, Leaf <LeafStormR...@gmail.com> wrote:
> Out of necessity, I've made a modification to my Django trunk. It
> gives a parameter to the Library.simple_tag() function named
> takes_context.

You might want to take a look at ticket #1105. I addresses the issue
you're raising here, and has been put on the version 1.1 wish-list.

Regards,

Julien

http://code.djangoproject.com/ticket/1105
http://code.djangoproject.com/wiki/Version1.1Features

[Leaf]

On Sep 27, 9:06 pm, Julien Phalip <jpha...@gmail.com> wrote:
> You might want to take a look at ticket #1105. I addresses the issue
> you're raising here, and has been put on the version 1.1 wish-list.

On second thought, I do think that the diff file attached to 1105 does
a better job of this than my patch. At least I have the achievement
value.

I'm still a bit confused about the dev process, though - if the code's
already there, and it won't introduce anything backwards-incompatible,
why don't they merge it into the trunk? It seems to me that it would
make development and improvement go a lot faster if code was applied
to the trunk when it was ready. Is there another issue here I'm not
seeing as far as why this isn't already in the trunk, or why the devs
make decisions in this manner?

Regards,
Leaf

[Malcolm Tredinnick]

On Sat, 2008-09-27 at 18:57 -0700, Leaf wrote:
[...]

> I'm still a bit confused about the dev process, though - if the code's
> already there, and it won't introduce anything backwards-incompatible,
> why don't they merge it into the trunk? It seems to me that it would
> make development and improvement go a lot faster if code was applied
> to the trunk when it was ready. Is there another issue here I'm not
> seeing as far as why this isn't already in the trunk, or why the devs
> make decisions in this manner?

If you look carefully at that ticket, you'll notice that is changed
direction a number of times in it's lifetime. The most recent approach
in the patch is only a few months old and, if you think back, that was
in the lead up to 1.0. You'll note that it's also grown in context, so
we need to consider whether adding something like "takes_nodelist" is
really a good idea for something called *simple* tag decorator.

Realise that it is never the case that any of the core committers just
sit back and say "well, I have some time on my hands that I could use to
commit things to Django, but I think I'll just screw people over by
doing nothing". Instead we are either (a) working on other things in
Django or (b) getting on with the rest of our lives. Something like
#1105 is particularly low priority in a situation like this, since it's
a pure feature addition and totally possible to do without modifying
core at all. We tend to spend a lot more time working on bug fixes and
feature additions that do require core modifications, since they cannot
be done in any other way. Every now and again we look at extra things
and from time to time in the last I've looked at #1105, but it's always
needed a bit of thinking and, as I noted above, it's not stopping
anybody from achieving exactly the same results without core
modifications.

Every single patch takes non-zero amounts of time to consider. There are
the design decision impacts (which #1105 has some to consider), there's
evaluating the code quality, proofing the tests and documentation and
thinking about how it impacts other things and whether it's a feature
worth having. It's never as simple as "code's there and introduces no
backwards-incompatible changes". If that was the only requirement,
Django would be about 2 million lines of code in size fairly quickly.

I hope that clarifies for you why some things take longer than others.

One of the reasons we introduced the list of 1.1 request features is so
that we have a list to check through when we're considering features and
so that they won't be forgotten. That will happen in due course.

Regards,
Malcolm