On Dec 15, 10:52 pm, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On Wed, Dec 15, 2010 at 6:41 PM, Julien Phalip <jpha...@gmail.com> wrote: > > On Dec 14, 7:34 pm, Christian Hammond <chip...@gmail.com> wrote: > >> On Dec 14, 12:02 am, Julien Phalip <jpha...@gmail.com> wrote: > > >> > On Dec 13, 10:16 am, Tai Lee <real.hu...@mrmachine.net> wrote: > > >> > -snip- > > >> > > One suggestion from #1105 was to split out this functionality into > >> > > individual decorators, @takes_context, @takes_block. I'm not sure how > >> > > easy this would be technically to implement, but I think it would > >> > > solve the `takes_context_plus` sink problem Malcolm describes as we > >> > > potentially add more special case tag types (simple, inclusion, > >> > > assignment, etc.) > > >> > The djblets (created by the guys at reviewboard.org) contain two nifty > >> > decorators for exactly this purpose: > >> > @basictag:https://github.com/djblets/djblets/blob/master/djblets/util/decorator... > >> > @blocktag:https://github.com/djblets/djblets/blob/master/djblets/util/decorator... > > >> > This now seems to me like the perfect compromise. It would generally > >> > allow for more versatility and to keep simple_tag (and the future > >> > assignment_tag) free of takes_xxx cruft. > > >> > Any chance these two decorators could be considered for inclusion in > >> > Django core? > > >> For what it's worth, these two decorators have seriously cut down on > >> our development and maintenance burdens. Whether they'd be sufficient > >> as-is, I don't know (though you're welcome to have the code), but I'd > >> also love to see equivalent functionality in Django. > > >> If I can help in some way to get these in shape (assuming you'd want > >> to go that direction), just let me know. > > >> Christian > > > I think the djblet tags approach is the most reasonable one. It > > provides the feature originally requested without disrupting any > > existing code or API. The current code works and has been successfully > > tested in production environments for a long time. > > > I'm keen to push this through, but I'm also concerned that the future > > freeze deadline is upon us. I don't want to create too much noise in > > the issue tracker, so could a core dev advise on the way to go from > > here? Considering the djblet approach is judged reasonable, shall we > > create two different tickets (one for each tag)? > > I'm only one voice, but I'm *really* not a fan of decorators changing > function signatures like that. I don't deny it works; it just grates > me the wrong way. > > I've already indicated my preferred approach -- consistency with > inclusion_tag. > > Yours > Russ Magee %-)
Ok, it looks like we've got a consensus which will scratch the original itch. I've created a ticket for it and will work on a patch over the weekend: http://code.djangoproject.com/ticket/14908#preview Thank you all! Regards, Julien -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
