On Wed, Dec 15, 2010 at 6:41 PM, Julien Phalip <[email protected]> wrote: > On Dec 14, 7:34 pm, Christian Hammond <[email protected]> wrote: >> On Dec 14, 12:02 am, Julien Phalip <[email protected]> wrote: >> >> >> > On Dec 13, 10:16 am, Tai Lee <[email protected]> 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 %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
